Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Cannot create an OAuth token when using HTTP-basic #2278
I am trying to create an oauth token for the API. It doesn't seem possible when my wallabag instance is protected by HTTP-basic.
It works if I disable HTTP-basic, or if I unset the corresponding variables in
Steps to reproduce/test case
I'm trying to create an oauth token via the API, testing with
The URL and the HTTP login/password and client_id/client_secret/username/password are all OK -- I just removed them to post this issue.
I get the following response:
If I add the following line of code at the very top of
=> The exact same curl command works and I get the oauth token:
It also works fine if I temporarily disable HTTP-basic on the server-side and do not send it in the request. But if I send the HTTP-basic identification infos in the request, event if it's disabled on the server-side, the application seems to use them and fail creating the token.
I'm guessing there might be some mixup somewhere between HTTP-basic info and login/password passed as GET parameter?
I also reproduced this behavior on the demo instance. Without specifying HTTP-basic login/password, I can create an oauth token :
But if I add
I hope this helps :-)
As far as I understand, your wallabag instance is protected using a
As far as I understand, the oAuth2 bundle we are using use the HTTP Basic information as client_id / secret.
Basically, if you want to use HTTP Basic, you should do:
It seems to be just an other way to send client_id & secret.
Thanks for your help :-)
Actually, my wallabag instance is protected by a
The http-basic login/password is here as a first layer, in front of wallabag's own login/password -- it's a bit overkill considering the criticity of this kind of application, but, basically, the idea is to get 2 layers of security:
Main goal: if there is a hole in either PHP or wallabag (or my install / config), it should not be exploitable without first breaking the http-basic login/password at the webserver level.
To setup this, I first installed wallabag, with its own login/password. And, then, put a
Oh... That's probably what's causing my problem.
But if it's expected behavior, I'm OK to close this issue and I'll try to find another way -- I should be able to prevent nginx from passing the http-basic login/password to wallabag, with a bit of luck.