Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check that the Bearer header is properly formatted #491

Merged
merged 3 commits into from May 26, 2018
Merged

Check that the Bearer header is properly formatted #491

merged 3 commits into from May 26, 2018

Conversation

MattBlack85
Copy link
Contributor

While testing some things we noticed that passing a header with a typo like Beaver makes the app behaving like it was Bearer. I don't know if this is a desired behaviour or not but it seems odd to me. I made the check a little bit more rigid and added test cases for that.
Feel free to close and kill this if this is an intended behaviour

@@ -59,9 +61,17 @@ class TokenTest(TestCase):
bearer_headers = {
'Authorization': 'Bearer vF9dft4qmT'
}
fake_bearer_headers = {
'Authorization': 'Beaver vF9dft4qmT'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add some further odd tokens? Such as

BearerNoSpace
Bearer Multi Space
BeaverNoSpace
Beaver Multi Space

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do

@skion skion mentioned this pull request Dec 17, 2017
@MattBlack85
Copy link
Contributor Author

@skion I finally added those tests, it seems tho that travis is disabled for the repo now?

@MattBlack85 MattBlack85 changed the title Check that the Bearer header is properly format Check that the Bearer header is properly formatted Feb 6, 2018
@skion
Copy link
Member

skion commented Feb 6, 2018

That's potentially due to the moving of the repo, stay tuned on #511.

I think you'll need to apply the same patch to these two lines still, now that #488 has been merged.

@MattBlack85
Copy link
Contributor Author

@skion thanks, I'll implement the check also for JWT

@MattBlack85
Copy link
Contributor Author

MattBlack85 commented Feb 6, 2018

@skion I think the case Bearer Multi Space or Bearer DoubleSpace are valid header and shouldn't fail the validation cause the header type is valid. Instead what will happen is that the token will fail the validation cause it will be '' or a truncated token. What do you think of these cases?

@MattBlack85
Copy link
Contributor Author

sorry for the noise, the .split() will give more than 2 elements and it won't pass the validation anyway, my bad

@skion
Copy link
Member

skion commented Feb 6, 2018

FWIW: The Bearer token header is described like this:

b64token    = 1*( ALPHA / DIGIT /
                  "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token

So multiple spaces after the Bearer keyword should not be a problem.

@MattBlack85
Copy link
Contributor Author

@skion updated my PR, everything should be ok now, let me know in case

return self.request_validator.validate_jwt_bearer_token(
token, request.scopes, request)

def estimate_type(self, request):
token = request.headers.get('Authorization', '')[7:]
if token.startswith('ey') and token.count('.') in (2, 4):
token_type, token, *_ = request.headers.get('Authorization', '').split(' ')
Copy link
Member

@skion skion Feb 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That syntax won't fly on Python 2.7 unfortunately...

And should we use .split() instead of .split(' ') to allow for multispaces then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this can now raise a ValueError, which I'm not sure is desired (though haven't checked in detail).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dang you're right, too focused on python3. For the multispace I don't know, doesn't 1*SP stays for 1 space?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know the feeling :)

Re 1*SP is one or more spaces... unnatural indeed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aaaaa gotcha, fixing also that then! :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed both @skion

@JonathanHuot
Copy link
Member

Somehow Travis-CI didn't add a link to the build, maybe because it has been canceled before starting (5months ago, by who, why?..)

So I have restarted the build which is passing, and adding a link : https://travis-ci.org/oauthlib/oauthlib/builds/290372743

@MattBlack85
Copy link
Contributor Author

thanks @JonathanHuot 👍

@skion skion added this to the 3.0.0 milestone Mar 18, 2018
@skion skion modified the milestones: 3.0.0, 2.1.0 Mar 20, 2018
@JonathanHuot
Copy link
Member

Would you want to add a new unit test which test headers with multiple spaces between Bearer and <token> ?

As @skion pointed out, it's validated by the RFC.

Once done, the PR LGTM, ready for the merge! :-)

@MattBlack85
Copy link
Contributor Author

MattBlack85 commented Mar 29, 2018

@JonathanHuot
Copy link
Member

I let him reply, however I understood that we need to accept several spaces 1*SP after Bearer.

The line you mention is testing several spaces 1*SP after Beaver (a wrong request, then), which is also good to have.

@skion
Copy link
Member

skion commented Mar 29, 2018

Yes, I think you're missing that positive test case, maybe make this into a list like the fake headers and add a test with multiple spaces between Bearer and the token there?

@MattBlack85
Copy link
Contributor Author

@skion looking again at the PR it seems I already made that check here https://github.com/oauthlib/oauthlib/pull/491/files#diff-6096f6f429036633b8a4a4156878b1c4R72 with related test https://github.com/oauthlib/oauthlib/pull/491/files#diff-6096f6f429036633b8a4a4156878b1c4R110

@JonathanHuot
Copy link
Member

LGTM :-)

@skion skion merged commit 27702f4 into oauthlib:master May 26, 2018
bungoume added a commit to bungoume/oauthlib that referenced this pull request May 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants