-
Notifications
You must be signed in to change notification settings - Fork 359
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
Support alternative token location #271
Changes from 8 commits
b4d58b2
1472e65
f2432d1
ce024c9
91cf8bf
6cc7e65
55c8eff
815e2bc
5b0bd05
e710db1
594194e
27669e3
937fd44
e68a10d
4f51c8c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -25,9 +25,28 @@ import ( | |||||
"strings" | ||||||
) | ||||||
|
||||||
func BearerTokenFromRequest(r *http.Request) string { | ||||||
auth := r.Header.Get("Authorization") | ||||||
split := strings.SplitN(auth, " ", 2) | ||||||
const ( | ||||||
defaultAuthorizationHeader = "Authorization" | ||||||
) | ||||||
|
||||||
type BearerTokenLocation struct { | ||||||
Header *string `json:"header"` | ||||||
QueryParameter *string `json:"query_parameter"` | ||||||
} | ||||||
|
||||||
func BearerTokenFromRequest(r *http.Request, tokenLocation *BearerTokenLocation) string { | ||||||
var token string | ||||||
if tokenLocation != nil { | ||||||
if tokenLocation.Header != nil { | ||||||
token = r.Header.Get(*tokenLocation.Header) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wouldn't it make more sense to return the value here directly?
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can't return the value directly there, as in your suggestion, because we need to return only the token without the "bearer" part. However, I thought about moving lines 49-53 to a separate function. Then the line of your suggestion would look like:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The However, an explicit query parameter such as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok. Then of course we can do it like you suggested :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That would be two authenticators with two separate custom headers IMO There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @aeneasr We do not give the possibility to override the scheme and IMO it should remain as it is but with the option to use different header There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @aeneasr the last word is yours 😄 Do you want the "bearer" in custom header value to be optional, required or not valid? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's very confusing to have the "bearer" in the custom header and the query parameter. If you look at the documentation it also does not become very clear. This is something I believe will make things very awkward when people are trying to use these features as I've never ever in my life have seen something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, done 😄 |
||||||
} else if tokenLocation.QueryParameter != nil { | ||||||
token = r.FormValue(*tokenLocation.QueryParameter) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. same here:
Suggested change
|
||||||
} | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it possible that both if / else if do not get executed? Then There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is not possible, as JSON schema for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we make this explicit in the code by simply doing a if/else? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can, but if somehow QueryParameter would be a nil, than the program will crash on dereferencing a nil pointer. With "else if" the function will simply return an empty string, like if there was no token in the configured header/query parameter (what may be a proper behavior if there was "alternative token location" set, but not configured - even though with the current schema it is not possible). I see an alternative solution here: returning an error saying that rule is misconfigured. But I would have to add error handling in the places where this function is called. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, how about simply falling back to the authorization header in the case where both are nil? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, done |
||||||
} else { | ||||||
token = r.Header.Get(defaultAuthorizationHeader) | ||||||
} | ||||||
|
||||||
split := strings.SplitN(token, " ", 2) | ||||||
if len(split) != 2 || !strings.EqualFold(split[0], "bearer") { | ||||||
return "" | ||||||
} | ||||||
|
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.
Would it make sense to test this independently?
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.
Yeah. That might be a good idea :)
I added tests.