-
Notifications
You must be signed in to change notification settings - Fork 3.5k
[google_sign_in] Adds "Button" Sign In for Web. #3461
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
It's very nice that the CI is catching that I'm breaking the Android compilation. I'll probably need to hide the renderButton call behind a conditional import! |
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.
First look login works! Great job so far! 👍
The JavaScript API itself seems very restrictive in it's design options. If possible maybe you can hint me a way to open an issue for them to see if we can get some of the restrictions out of the way.
For now the introduction of the new button comes with heavy design breakers, which I guess our app is not the only "login tower" that will suffer from these restrictions.
packages/google_sign_in/google_sign_in_web/lib/src/button_configuration.dart
Show resolved
Hide resolved
packages/google_sign_in/google_sign_in_web/example/lib/button_tester.dart
Outdated
Show resolved
Hide resolved
e41ad8f
to
6e211e5
Compare
(Android seems to be happy again) |
ed73491
to
3b14f63
Compare
Making PR "ready for review" after pushing some extra tests. |
With the deadline for migration to GIS coming up in 5 days, this pull request is fundamental to keep a working google sign in flow. |
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 left some questions/comments. Mostly I just want to make sure we understand how these changes will work on mobile.
Someone other than me will need to review the actual web parts.
/// These will normally come from asynchronous flows, like the Google Sign-In | ||
/// Button Widget from the Web implementation, and will be funneled directly | ||
/// to the `onCurrentUserChanged` Stream of the plugin. | ||
Stream<GoogleSignInUserData?>? get userDataEvents => 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.
What are the implications of not implementing this? E.g., are we going to have issues on mobile until we do?
We probably need more comments on this method for implementors.
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.
The Core plugin optionally grabs this stream (if not null), and connects it to a similar stream it owns.
The problem that this is solving is that plugins cannot inject (de)authentication events from their implementations, currently those events can only come from programmatically interacting with (some) methods of the core plugin.
Mobile should not be affected by not having these, but IMO the API of the plugin would be much better if signIn/signInSilently/signOut and friends returned a Future, and the results of those calls were funneled through this stream (or something similar), to make authentication (and maybe authorization) events fully asynchronous. (but this is "future of the google sign-in plugin" terrain)
/// Checks if the given `accessToken` authorized to access all `scopes`. | ||
Future<bool> canAccessScopes(String? accessToken, List<String> scopes) async { | ||
await _ensureInitialized(); | ||
return GoogleSignInPlatform.instance.canAccessScopes(accessToken, scopes); |
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.
Do the mobile SDKs give us the ability to implement this method everywhere?
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 think so, here's the Android version:
And on iOS:
As you suggested above, the token may be a web-only artifact, so I'm going to make it a completely optional, named parameter so it can be ignored by other implementations if you ever need to implement this other than "isSignedIn".
I'll find somebody to review the web bits as well. Thanks for the rest of the review, I'll correct everything by EOD today. |
Also, add comments to the example app, so its flow is easier to follow.
d3ebcac
to
9a4242a
Compare
e251733
to
e97d5e4
Compare
Rather than rebasing this branch, I'll start creating the independent PRs off of the latest master. |
This has been published as |
This comment was marked as off-topic.
This comment was marked as off-topic.
Please use the issue tracker to report issues; the PR is for reviewing the change before landing it (which has already happened). |
This PR modifies the Google Sign In plugin so Web application authors can render a "Google Sign In Button" (like this one).
This is needed to obtain a guaranteed
idToken
from the user that is signing in, since the previous method,signInSilently
might be aborted by the user, and the programmaticsignIn
wouldn't be able to provide that token.This PR also updates the example apps so they work with the new web API (a combo of renderButton + canAccessScopes + requestScopes), and the mobile API (signIn + requestScopes).
(This is just a RFC PR, since each package needs to be landed separately)
Issues
Testing
Pre-launch Checklist
dart format
.)[shared_preferences]
pubspec.yaml
with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.CHANGELOG.md
to add a description of the change, following repository CHANGELOG style.///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.