Skip to content

Conversation

ditman
Copy link
Member

@ditman ditman commented Mar 15, 2023

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 programmatic signIn 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

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
  • I signed the CLA.
  • The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
  • I listed at least one issue that this PR fixes in the description above.
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
  • I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is test-exempt.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@ditman
Copy link
Member Author

ditman commented Mar 15, 2023

�[31mThe following packages had errors:�[0m
�[31m  google_sign_in/google_sign_in:
    google_sign_in/google_sign_in/example (Android)�[0m
�[31mSee above for full details.�[0m

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!

Copy link

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

@ditman ditman force-pushed the gsi-web-add-button branch 2 times, most recently from e41ad8f to 6e211e5 Compare March 16, 2023 03:57
@ditman
Copy link
Member Author

ditman commented Mar 16, 2023

(Android seems to be happy again)

@ditman ditman force-pushed the gsi-web-add-button branch 4 times, most recently from ed73491 to 3b14f63 Compare March 18, 2023 06:28
@ditman
Copy link
Member Author

ditman commented Mar 21, 2023

Making PR "ready for review" after pushing some extra tests.

@ditman ditman marked this pull request as ready for review March 21, 2023 01:45
@ditman ditman requested a review from stuartmorgan-g as a code owner March 21, 2023 01:45
@SeriousMonk
Copy link

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.
Are we going to have this merged before the 31st? I am more than happy to help if any help is needed to speed up this process.

Copy link
Collaborator

@stuartmorgan-g stuartmorgan-g left a 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;
Copy link
Collaborator

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.

Copy link
Member Author

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);
Copy link
Collaborator

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?

Copy link
Member Author

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

@ditman
Copy link
Member Author

ditman commented Mar 28, 2023

Someone other than me will need to review the actual web parts.

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.

@ditman ditman force-pushed the gsi-web-add-button branch from d3ebcac to 9a4242a Compare March 28, 2023 23:10
@ditman ditman force-pushed the gsi-web-add-button branch from e251733 to e97d5e4 Compare March 29, 2023 17:50
@ditman
Copy link
Member Author

ditman commented Mar 30, 2023

Rather than rebasing this branch, I'll start creating the independent PRs off of the latest master.

@ditman
Copy link
Member Author

ditman commented Apr 6, 2023

This has been published as google_sign_in: ^6.1.0:

@xiaolongwuhpu

This comment was marked as off-topic.

@stuartmorgan-g
Copy link
Collaborator

Please use the issue tracker to report issues; the PR is for reviewing the change before landing it (which has already happened).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[google_sign_in_web] Display Sign In With Google button
6 participants