User Sign-In Status In Javascript

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.

Popular posts from this blog

Client-Server Authentication with ID tokens

Image
These days there are few purely client-side applications - even traditionally unconnected software like casual games make use of servers and services to provide a better, richer experience - and importantly one that can follow the user across devices. We are in a world where we need to authenticate a user of many clients to a set of back-end services. There are a few ways of doing that when using a identity provider, like Google, but in this post I want to talk about a specific method that makes use of ID tokens. This approach has been well covered by Tim Bray for Android, but with the release a couple of months ago of the iOS 1.4.0 SDK for Google+, it is now available across Android, iOS and the Web. This makes it a particularly powerful way of signing in a user, and asserting the identity of that user securely to your application servers. Why ID TokensThis whole architecture relies on a point of view which I suspect is still not particularly common amongst developers implementing au…
Read more

TLS and ZeroMQ

It's pretty straightforward to use synchronous encryption over ZeroMQ - just a case of encrypting and decrypting at each end with some previously shared key. Asynchronous encryption is a bit more interesting, as it allows signing for message integrity and authenticity, as well as data hiding. There have been some good examples of crypto over Pub/Sub (notably Salt), but not a lot of examples of direct messaging.

The de-facto library for this sort of work is OpenSSL, but this has a couple of problems. The first is that usually openssl manages the TCP connection itself, which could be an option for some ZeroMQ cases, but doesn't fit if the user wanted to use a different transport, or an unusual topology. TLS or SSL also require a handshake at the start of the communication, which means we may have to send messages back and forth without there being any application data.

For the first part, OpenSSL includes support for usage as a filter thanks to it's BIO IO abstraction layer.…
Read more

Common problems with Google+ Sign-In on Android

Image
It has been fantastic to see so many people trying out Google+ Sign-In, and through the bootcamps and other events I've had a chance to talk to some people who are actually implementing it in their apps. The Android integration is pretty straightforward, thanks to Google Play Services, but there are still some issues I've seem come up a couple of times.

tl;dr: make sure your app is set up in the API console, and make sure you can handle multiple onStart events coming in during sign-in.

1. Consent screen appears more than once. 

The basic life cycle of the PlusClient looks a bit like this:


When we call the onStart, we immediately call mPlusClient.connect(). Google Play Services checks whether the user is already signed in to the application, and, if so the onConnected method is instantly called and the user seamlessly signed in.

If the connect() call fails, then onConnectionFailed() is called with a ConnectionResult object, which represents the error. The error is probably RESOLU…
Read more