-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Add support for Firebase backed silent sign-in #1212
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
Add support for Firebase backed silent sign-in #1212
Conversation
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
|
@SUPERCILEX this is really cool, but since it's cross-device in nature it's definitely something we'd want iOS and Web support for. I know that iOS does not have SmartLock, but we could port as much of the idea as possible. So just FYI this one could be on hold for a bit, as we have to drum up some excitement from the maintainers of those platforms. |
|
Haha, SGTM! |
…-sign-in # Conflicts: # app/src/main/java/com/firebase/uidemo/auth/AuthUiActivity.java
Signed-off-by: Alex Saveau <[email protected]>
|
Lol, I seem to have broken all of my PRs. Sorry for the spammy updates! |
Signed-off-by: Alex Saveau <[email protected]>
|
@samtstern Alright, created firebase/FirebaseUI-iOS#426 and firebase/firebaseui-web#358. |
|
I still need to add README docs |
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
|
@samtstern Alright, I think this PR is ready for review. |
|
@samtstern Anything holding this one back? |
|
@SUPERCILEX nothing philosophical holding this back, I was just focusing on |
|
Gotya, SGTM! 👍 |
|
@samtstern ready to roll? |
| } | ||
|
|
||
| final Context appContext = context.getApplicationContext(); | ||
| final IdpConfig google = |
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 is kind of a funny way to get here:
- Run through desired configs, filter out everything besides
googleandemail - Then use
getConfigFromIdpsto getgoogleandemailout of the filtered list
Why not just use getConfigfromIdps on desiredConfigs and throw the IllegalArgumentException if google and email both end up 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.
Lol, yeah, that's a much better way to do it.
| .getParcelable(ExtraConstants.GOOGLE_SIGN_IN_OPTIONS); | ||
| } | ||
|
|
||
| final GoogleSignInOptions finalGoogleOptions = googleOptions; |
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.
Why do we need a separate variable to finalize?
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.
Now we don't!
| * @return a task which indicates whether or not the user was successfully signed in. | ||
| */ | ||
| @NonNull | ||
| public Task<AuthResult> silentSignIn(@NonNull Context context, |
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.
I am somewhat uncomfortable with all this code and chained async operations happening in one huge method block in AuthUI. Should we consider making this happen inside a ViewModel in KickoffActivity or something so that it's rotation-immune? Obviously then we couldn't directly return a Task but I think onActivityResult would be appropriate (and more consistent with our general mechanism anyway)
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, I don't like the number of chained tasks we have either, but I strongly disagree about the onActivityResult and ViewModel stuff. The point of this method is that it doesn't have any UI and should be done in the background (so it's up to the dev to deal with async callbacks as usual). As for rotation problems, they're up to the dev just like with any other Task. Also, I tried calling the method multiple times myself and it doesn't seem to matter besides being signed-in several times with the same credentials on the Firebase side (so the method is deterministic in that you'll just get the same result multiple times).
Do you see where I'm coming from? I literally call this method in my Application#onCreate() and I think other people will want to do something similar.
Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
Proposal for #1039. @samtstern What do you think? Is this something that should go in FirebaseUI Auth? Personally, I think this is huge since it means a zero-effort way for developers to provide seamless sign-in after their users upgrade devices or reinstall their apps.
PS: to try it, just sign in with Google or email, clear app data, and then press the silent sign-in button.