Risk Complete Failure

Very short post on a small feature that I know will be a popular one with some people! A regular feature request has been the ability to determine whether the profile picture with a Google+ profile is the default blue head or not. You can do that right now with the people.get API calls - and you can try it yourself from that page using the explorer. The change is that under the "image" key you'll see an "isDefault" value. For my user you can see it's false: "image": { "url": "https://lh6.googleusercontent.com/.../photo.jpg?sz=50", "isDefault": false },But for this blue head user, it's true:"image": { "url": "https://lh3.googleusercontent.com/.../photo.jpg?sz=50", "isDefault": true },Hopefully this should make it easier to determine whether to use the profile picture from Google+ when people sign in to your apps.Client libraries might take some time to be regenerat…

The release today of version 1.7 of the Google+ iOS SDK added the ability to authorise both a client and server for access to Google APIs. This has been a feature for Android and Web based sign-ins for a while, and now is available across all three platforms. This should simplify server side code for people who have been building cross platform apps - for example if you need to retrieve profile information on the client, but retrieve circles on a server for a friend finding feature.The implementation for iOS is fairly straightforward. When setting up authentication, simply specify the client ID of your server on on the GPPSignIn object. This should be a client ID from the developer console which is used by your server-side code, and should be part of the same console project as your iOS client ID. For those that have done it, this is the same parameter used when retrieving an ID token:You can see that the first part of the client ID (the project number) is the same, but the other par…

Thanks for reading the blog! This post is pretty old, and the APIs it references have been improved upon significantly. If you're interested in authentication check out the new Google Sign In, and if you're looking to access profile data see the People API. Version 4.2 of Google Play Services introduced a new replacement for PlusClient, GoogleApiClient. While PlusClient is still present, it will be removed in a future version so its a good idea to upgrade when possible. The new class has been designed based on feedback from developers across various Google Play services APIs, and provides a much more consistent, powerful base. PlusClient was reasonably straightforward for developers implementing just Google+ Sign-In. Unfortunately, anyone looking to combine multiple services together quickly realised that managing a series of callbacks for all the different connections was way too painful. GoogleApiClient solves that by providing one central client to connect or disconnect. It …

With all the changes to Google+ Sign-In at the end of last year, it was easy to miss some of the extended options that have been added. In particular, this update added "profile" as a valid Google+ Sign-In scope, and its not immediately obvious what the implications of choosing between the different sign-in scopes are.To help give a bit of context to the problem, there are really only three states of users that need to be considered when choosing a scope:Google+ user: This is a Google or Google Apps user who has a Google+ profile. Non-Google+ user: This is a Google or Google Apps user that has not upgraded to Google+.Google+ disabled Apps user: This is a user of a Google Apps account where the administrator has disabled Google+. We can take a look at the two main sign-in scopes with that in mind.profileThe most basic sign-in scope is profile. This can be used for all three classes of users. A token will be returned through the normal OAuth 2.0 process, and you will be able t…

In my previous post I mentioned that there are two issues which have been made more visible by incremental auth. The first of these is fairly straightforward, but the second is a little more subtle. Incremental auth is a great feature for simplifying the consent screen that users see when they first sign in to an app, but it can also introduce a bit more complexity in some cases. An example of this is when requesting access to YouTube. Because YouTube profiles support delegated access to Google+ pages, their data can be associated with these pages as well as general Google accounts. Whenever you request access to a YouTube scope (even in combination with other scopes), the user will have the opportunity to choose one of their pages if they have any. Currently this only occurs on the web, and will result in the user seeing a screen like this: So far, so good - everything works as expected. Where it can get tricky is that if you ask for a YouTube scope incrementally, you need to account…

The recent launch of incremental auth has highlighted a couple of problems in the way some sites have implemented Google+ Sign-In or Google OAuth 2.0. The most obvious of these is that there are a fair number of places that use approval_prompt=force much more often than they should, which leads to a much worse user experience than there needs to be.What’s the problemSeveral sites set approval_prompt to force either in the Javascript Google+ Sign-In button (where it is generally approvalprompt), or in a parameter in the auth URL as part of a redirect based flow. This parameter means that users have to see the consent screen even if they had previously granted access to the application for the requested scopes.While this was never a great user experience, the recent release of incremental auth has made it even more visible. Because the user has granted access before, they are not shown most scopes. However, because force is specified, they have to be shown a consent dialog. The only rea…

Today was a busy day of launching stuff in Google+ land, and it is pretty easy to miss out on one or two features - particularly as the rest of Google wasn’t exactly keeping quiet on that front either. I wanted to briefly review what has happened, and why its interesting.Incremental AuthOne problem if you’re integrating multiple Google services is that you have to ask for a laundry list of scopes. This new release means that if a user has already granted you some scopes, when you ask for more they will only see the consent screen for the additional one(s). You can check this out on 8tracks right now on the web when you connect your YouTube profile after sign-in, but it’ll work cross-platform. To use it on Android or iOS just reauthorise with the additional scope. On Android you’ll need to add the scope and reconnect the PlusClient:On iOS, add the scope and call authenticate again.In both cases, its best to track which scopes you have, so you know whether you’re going to prompt the use…

At an event last week Ade, Lee and I hosted a discussion about cross-device sign-on, where we covered not only what it was, but why its interesting and how it works. One conclusion we came to was that minimising the number of times your users have to see the sign-in button and make an active choice to sign-in can really help smooth the experience of using an application. However, there are a couple of pitfalls that can mean you don’t feel the benefits from the feature. What do we mean by cross device sign-in?Once a third party is involved, authentication is no longer just about exchanging some credentials for a cookie or identifier of some kind. Unfortunately, a lot of the time we do exactly that: treat the sign-in as simply being a replacement for sending a username and password across to the server which can return a cookie. Once the user has a cookie, they are app-identified, and hence can use the site as normal.The problem is that this approach basically treats auth as a one time …

During the development of the new Chromium powered Android WebView, Internet celebrity Matt Gaunt showed me some rather interesting demonstrations. This included integrating with Google Play services, in the form of letting the user natively sign-in from the WebView. Now all the changes are publicly available I had to try such a thing myself, and found it surprisingly straightforward!The first step is to actually create the HTML that we’ll be using. While it would be possible to use the Google+ Javascript SDK to make API calls and so on, I couldn’t actually think of a good reason to do so. What feels like a more general use case is presenting data retrieved through the API calls in the native SDK, which is how we’ll structure it. This is what my test page looks like, which is saved as part of my Android project in assets/index.html.Two things are of note here. First, we define a callback to be triggered after a sign-in. Second, we make two calls to MainActivity" one to indicate t…

On Monday the Google+ Javascript SDK team announced the release of a number of enhancements to the sign-in SDK on the web. These are all things that have either been directly requested by developers, or were created in response to something that developers have asked for, but I wanted to go into a bit more depth on one of the more subtle, but also very useful, changes. The feature is the combination of the page level configuration and the dynamic sign in callback. This simplify managing configuration for a page, makes managing sign-in state easier, and generally provide a much better feel for the user. Page Level ConfigThe biggest change is moving configuration information from either HTML data- attributes or Javascript options to meta data on the page itself. This means that you won’t run into a problem of having one button configured with scopes A and B, but another with just A (which can lead to confusing situations), or miss out some app activity types. The configuration is suppl…

Brian Balfour recently wrote an interesting post about the measures startups use at different stages of growth. In the early days of building a startup its really important to have a regular stream of users trying our the application or service, and for a decent number of users to come back and continue using it.Having decent retention makes it a lot easier to experiment. A group of real users to give feedback and spread word about your product is a worthwhile goal. Getting users to try an application is a pretty difficult thing, but the worst result is to have those users bounce having only scratched the surface of the product. If you get a user to the point of signing-in to your application, then its worth rolling out the red carpet to give them the best chance of having a good experience, and to give them opportunities to come back. One of the best things about using social sign-in like Google+ Sign-In is the access to services which you can use to enhance that out of the box exper…

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 appRather 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 GoogleYou 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 whenev…

I've written before about common technical problems with Google+ Sign-In implementations, but there is whole other class of errors that I've seen in applications. These generally aren't technical mistakes per se, but more about best practice. One the aims of the guidance on developers.google.com/+ is to promote a standard experience - users trust new applications because they behave in a way they expect. A good implementation does this, and makes all three parties involved happy: the app developer, the identity provider, and the user. Bad consent screensCommon problems with consent are asking for more access or more scopes than are needed, and not adding a logo and clean name. For example, take this consent screenHere the app name is generic, and not tied to where the user was signing in. The app is requesting full access to both my Drive account and my YouTube data, and there is duplication - it asks for basic information, and basic profile. Each of these can be resolved.…

Once you get beyond the basics of adding Google+ Sign-In, and start looking at what is available across the Google platform there are some real gems to be found. One of these is a fantastic feature of Google Drive called appdata, which allows an application to store data in a user’s Drive account without worrying about the user fiddling with it. These is handy if you’re building something like a Javascript web app and need some storage, but don’t want to setup a server. Unlike localStorage or other browser based options it doesn’t rely on the user being on the same device, so it’s easy to allow users to access their data from wherever they are.Most of the time this sort of feature seems a natural fit for mobile applications - as Drive is about manipulating files - but it’s just a straightforward to build it in to a web application. There’s a little form in the iframe below - you can sign in and save your data, and then if you sign in to another device you should have the same data ava…

Recently I've answered a couple of questions from people that had a section of their site loaded dynamically with Javascript, and wanted to put a +1/Sign-In/Follow/etc button there. Google+ Sign-In along with all the Google widgets, can be marked up in HTML and rendered automatically when the plusone.js loader is included in the page. However, there are ways of controlling when that happens with explicit parsing, or triggering it directly with the render functions. Lets say we have a page that contains a +1 button, a follow button and a post embed, though the same thing works with sign in, badges, and anything else. The most straightforward way to write that page is by using the markup based widgets, which all follow a similar form and look something like this.Pretty much all the other widgets work the same way: a known class name which is scanned for when the async tag loads, and a series of parameters on the element specified as data- attributes to configure the behaviour of the…

NOTE: This blog post is pretty old! Take a look at a much better way of getting an authorization token or check out the official Google Sign In documentation for a more up to date (and easier!) choice.Google+ Sign-In is a really easy way to authenticate and identify a user and build interesting experiences on Android. Some apps needs more than just an authenticated Android client though - they also need to make Google API calls from their server, perhaps even when the client is offline. Enabling both to access the APIs at the same time is slightly tricky, but in this post I'm going to try and break down what is required, and how you can do this in a robust and reliable fashion. Note that life is much easier if you just need either the client or the server to have API access, or just need to identify the user to a server. This approach is solely for the case where you make Google API calls on the Android client, and also Google API calls from the server.Our model is that we have an…