Migrate authentication to Google Identity Services

[tunetheweb]

Fixes #20

Looks like Google Identity Services works a bit differently to the gapi we used before in how you get the token, and also in that you can't check if the token is still active and register a call back when the log out happens. It does allow a handy way to re-authenticate however afterwards.

Other than that, it seems to work. Tested in Chrome, Firefox and Safari.

[philipwalton]

Thanks for taking a stab at this. I haven't had a chance to fully look at the new GIS docs, but I did take the time to run your code changes and have some initial comments.

It looks like these changes trigger Chrome's default popup blocker, which I'd like to avoid. I think this happens because the auth flow is triggered as soon as the script loads instead of waiting for user interaction.

Ideally it'd be possible to update to the new library while still retaining the current behavior. In the current app, the logic goes:

1. Run the initial auth flow to see if the user is currently logged in: a. If they are, show the app b. If they're not, show the sign-in button

It's not clear to me whether the new Google Identity Services library has equivalent functionality (seems like maybe it doesn't?). The example @paulirish linked to works pretty well in my testing, but it does require the user to specifically click something to authorize every single time, which is a bit annoying since it adds friction over the current behavior. I'm not sure if this is an intentional limitation of the new library, or if there's a way around it.

As a next step, I think it'd be worth answering the question as to whether it's even possible to replicate the existing behavior with the new library, and once we have an answer to that then I think we can talk about implementation details.

WDYT?

[tunetheweb]

OK so I went a slightly different route here after that feedback.

What it does now is:

1. Check for access_token in session storage.
2. If access_token exists then assume logged in.
   • Show Report Screen
   • Change button to "Sign Out"
   • Attempt to get accounts.
   • If that succeeds then all good to go, so initialise app.
   • If this fails then assume log-in has expired and remove access_token, hide report screen, and change "Sign out" button to "Sign in", and go to step 3.
3. If access_token does not exist then assume not logged in.
   • User must click "Sign in" to (this avoids pop up blocker as now user initiated).

So the flows are:

• First time user smust authenticate, and we get an access_token and saver to session storage.
• When short-lived access_token expires, and user requests another report, it's automatically refreshed.
• When the sign in expires expires, and the user requests another report, they should just reauthenticate with pop-up (not blocked as user initiated by clicking on the submit report request button).
• If user reloads page, we attempt to reuse access_token from session storage, if that fails, we show unlogged in state as can't automatically show pop up as not user-initated so would be blocked. User must sign in again.

Differences from production:

• No sign-in with Google button. We could replicate the Sign In button as below.
• Always seems to show a pop up, where as currently it auto signs in if already signed in on Chrome. Can't seem to see a way around that.

Can you give it another whirl when you get a chance @philipwalton ?

[tunetheweb]

No sign-in with Google button. We could replicate the Sign In button as below.

Added this back in.