-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Fix email and Google providers creating duplicate credentials #1229
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
Conversation
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
| user.getEmail() == null ? user.getPhoneNumber() : user.getEmail()) | ||
| .setAccountType(type) | ||
| .build()); | ||
| // Also add an email credential to ensure password accounts get deleted. |
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.
This confuses me a bit ... feels wrong that the getCredentialsFromFirebaseUser method will always return a password credential with a made-up password.
Seems like something that could surprise us down the road, and it makes the method contract kind of a lie.
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.
Huge thank you on catching that one! Refactor mistake, I've fixed it.
| Uri profilePictureUri = | ||
| user.getPhotoUrl() == null ? null : Uri.parse(user.getPhotoUrl().toString()); | ||
|
|
||
| if (TextUtils.isEmpty(email) && TextUtils.isEmpty(phone) |
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.
Nit: this would be clearer if separated into two if-return-null statements.
if (no phone and no email) {
return null;
}
if (no password and no account type) {
return null
}
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.
No probs.
| import com.firebase.ui.auth.ui.HelperActivityBase; | ||
|
|
||
| @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP) | ||
| public abstract class VoidResourceObserver extends ResourceObserver<Void> { |
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.
Byyeeeeee
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.
🤣👍
|
|
||
| private void deleteUnusedCredentials() { | ||
| if (mResponse.getProviderType().equals(GoogleAuthProvider.PROVIDER_ID)) { | ||
| // Since Google accounts upgrade email ones, we don't want to end up |
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.
Ok so want to make sure what's going on here:
Whenever we sign in as a Google user we look for matching email credentials and delete them since the Google one is "superior"?
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.
Close. You should try this yourself: the "bug" everyone has been complaining about is that when you use the Google provider, it basically overwrites existing providers and pretends that they never existed. AFAIK, this is expected behavior so this removes the no-longer valid credential. Hope that clarifies things! 😄
Signed-off-by: Alex Saveau <[email protected]>
…save # Conflicts: # auth/src/main/java/com/firebase/ui/auth/AuthUI.java
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
| TextUtils.isEmpty(user.getEmail()) ? user.getPhoneNumber() : user.getEmail()) | ||
| .setAccountType(type) | ||
| .build()); | ||
| if (type == null) { |
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.
Let's just add a comment here for future-us explaining why we're doing this hack with the "pass" credential.
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.
Well actually, this isn't a hack anymore. If the account type is null, it's an email credential so we're just deleting it as we should. Or did you mean explaining the fake password? Either way, I'm happy to add a comment once I understand which piece you're talking about. 😊
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 just explaining why the password doesn't matter (since we're just creating a credential for deletion).
Oh and also that null means email for account type, since that's not obvious when reading this method (it is when reading the other method)
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.
Sweet, will do!
Signed-off-by: Alex Saveau <[email protected]>
Ideally this should be merged before #1212
Since the Google provider upgrades email accounts we end up with two credentials which will pointlessly force Smart Lock UI.
In addition, this PR fixes: