-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Do not infer username from email #146
Conversation
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.
Just one comment about maybe explaining why we are using the email address in the basic auth test, WDYT?
We also need to think about what we want to do about the breaking change and how we manage the release process for that.
1ac090a
to
56da838
Compare
I've re-ran the CI jobs and they've successfully passed, so I'm happy with this if @JoelSpeed is. |
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.
Couple of bits inline, as discussed OOB yesterday, I'd also like a note added to the Changelog including description of why this is a breaking change. I guess we should add a Breaking Changes header to the Changelog section for the next release? Should we also think about a migration guide or just add migration instructions in the Breaking Changes header?
I believe the change now fixes the issue described
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.
LGTM
@@ -148,7 +150,8 @@ func (p *GoogleProvider) Redeem(redirectURL, code string) (s *SessionState, err | |||
IDToken: jsonResponse.IDToken, | |||
ExpiresOn: time.Now().Add(time.Duration(jsonResponse.ExpiresIn) * time.Second).Truncate(time.Second), | |||
RefreshToken: jsonResponse.RefreshToken, | |||
Email: email, | |||
Email: c.Email, | |||
User: c.Subject, |
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.
generally for google the subject is meaningless garbage, and people expect to use their google email (which is verified), however given that both will go in the http headers that should be fine.
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.
Thanks @gargath, LGTM
I think for this change a description is enough, but we can always add one later on in case anyone feels more information is required. |
Description
If the auth provider does not return a
username
as part of the auth response, the proxy would infer a username by using the local part of the user's email (e.g.john.doe
forjohn.doe@example.com
).This change uses the entire email address instead to remove potential ambiguity between different users with the same email local part.
Note: This is a breaking change.
Motivation and Context
With the previous behaviour, the username stored in the session for users
john.doe@example.com
andjohn.doe@server.invalid
would be identical even though both users are likely to be different individuals.How Has This Been Tested?
Test suites have been changed to reflect the new expected behaviour.
Checklist: