-
-
Notifications
You must be signed in to change notification settings - Fork 239
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
Use the order of values in JWT_TOKEN_LOCATION to set order of precedence #256
Conversation
Hello @stephendwolff! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found: There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻 Comment last updated at 2019-07-03 15:13:56 UTC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor thing, otherwise looks great!
|
||
# add the functions in the order specified in JWT_TOKEN_LOCATION | ||
for location in locations: | ||
if location == 'cookies' and config.jwt_in_cookies: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can get rid of the config.jwt_in_cookies
(et al) from these if statements, as they are doing the same check that we are doing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point!
I think the way you have it where if there is a valid token higher up in the token location list supersedes an invalid token later in token location list makes the most sense 👍 |
Looks great! Thanks for contributing! I'll get a new version released momentarily. |
I've added the update to run the token validation in the order set in JWT_TOKEN_LOCATION, and this allows a valid token earlier in the list to authenticate the user, and invalid to be ignored if later.
This suits my use case - but perhaps another option could be to require no invalid tokens?
I wrote a couple of tests, and fixed one of the error messages in the existing multiple token location test.
Also, I added a note to the configuration options documentation for JWT_TOKEN_LOCATION