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

Do not infer username from email #146

Merged
merged 5 commits into from
May 9, 2019
Merged

Do not infer username from email #146

merged 5 commits into from
May 9, 2019

Conversation

wonderhoss
Copy link
Contributor

@wonderhoss wonderhoss commented May 7, 2019

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 for john.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 and john.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:

  • My change requires a change to the documentation or CHANGELOG.
  • I have updated the documentation/CHANGELOG accordingly.
  • I have created a feature (non-master) branch for my PR.

@wonderhoss wonderhoss requested review from loshz and a team May 7, 2019 09:43
Copy link
Member

@JoelSpeed JoelSpeed left a 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.

oauthproxy_test.go Show resolved Hide resolved
providers/google.go Outdated Show resolved Hide resolved
@wonderhoss wonderhoss force-pushed the no-infer-username branch from 1ac090a to 56da838 Compare May 7, 2019 10:57
@wonderhoss wonderhoss requested review from JoelSpeed and loshz May 8, 2019 08:20
@loshz
Copy link
Contributor

loshz commented May 8, 2019

I've re-ran the CI jobs and they've successfully passed, so I'm happy with this if @JoelSpeed is.

Copy link
Member

@JoelSpeed JoelSpeed left a 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

providers/google.go Show resolved Hide resolved
oauthproxy_test.go Show resolved Hide resolved
jtnord
jtnord previously approved these changes May 8, 2019
Copy link

@jtnord jtnord left a 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,
Copy link

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.

Copy link
Member

@JoelSpeed JoelSpeed left a comment

Choose a reason for hiding this comment

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

Thanks @gargath, LGTM

@wonderhoss
Copy link
Contributor Author

Should we also think about a migration guide or just add migration instructions in the Breaking Changes header?

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.

@wonderhoss wonderhoss merged commit 908ac24 into master May 9, 2019
@wonderhoss wonderhoss deleted the no-infer-username branch May 9, 2019 09:30
@JoelSpeed JoelSpeed mentioned this pull request Jun 15, 2019
3 tasks
Jing-ze pushed a commit to Jing-ze/oauth2-proxy that referenced this pull request Nov 19, 2024
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.

4 participants