Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@SUPERCILEX
Copy link
Collaborator

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:

  • Email creds not always being deleted
  • The void resource stuff
  • Kickstarter email sign-in not displaying a loading dialog

@SUPERCILEX SUPERCILEX requested a review from samtstern as a code owner March 29, 2018 23:16
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.
Copy link
Contributor

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.

Copy link
Collaborator Author

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)
Copy link
Contributor

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
}

Copy link
Collaborator Author

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> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Byyeeeeee

Copy link
Collaborator Author

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
Copy link
Contributor

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"?

Copy link
Collaborator Author

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]>
@samtstern samtstern added this to the 3.3.1 milestone Apr 2, 2018
…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) {
Copy link
Contributor

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.

Copy link
Collaborator Author

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. 😊

Copy link
Contributor

@samtstern samtstern Apr 12, 2018

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)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sweet, will do!

@samtstern samtstern merged commit 88c52da into firebase:version-3.3.1-dev Apr 12, 2018
@SUPERCILEX SUPERCILEX deleted the creds-save branch April 12, 2018 19:18
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.

2 participants