I wanted to explain a small addition that has recently appeared in the Google Javascript API that a couple of people have asked me about. You may have notice that the argument to the sign-in callback (which I’ll refer to as authResult) from the sign-in flow now contains an extra field: status. This simple object tells you a lot about how the user is accessing your page, and allows you to do some smoother and more reliable checks than before.
See if the user is signed in to your app
Rather than testing for the presence of the error or access_token properties, you can now test authResult.status.signed_in. This will be true for a user who has signed in to your app, false for a user that has not (or if we don’t know, because they’re not signed in to Google).
See if the user is signed in to Google
You could always use checkSessionState to see if the user had an active Google session, but now you don’t have to make a separate call - that information is directly available whenever an immediate mode sign-in attempt is displayed (e.g. any time the button is in the DOM). Check the authResult.status.google_logged_in variable - true indicates an active Google session, false indicates that the user is logged out. Of course, if its false you’ll only see this when signed_in is also false.
See how the user signed in
Several people built interesting methods to detect whether the user actively clicked the button, or were seamlessly signed in after an immediate check. Now there is no need! The status object includes a method variable: authResult.status.method. This will be set to null if the user hasn’t signed in, “AUTO” if they were seamlessly signed in, and “PROMPT” if they saw the consent dialog or signed in after a gapi.auth.signOut.
Give it a go yourself, there is a small demo here that shows the status data after each callback.
The relevant bit of code is the callback, where it is just flipping the button state and displaying the status object:
One last warning - be a little careful when you serialise the authResult object. Because it can hold a reference to the consent screen window, there are cases where serialisation can trigger cross-origin violation in the console. If you need to send any information in the result to another party, do it explicitly. E.g. instead of sending authResult, just send authResult.id_token or whichever parts of the object you need.