Risk Complete Failure

This post is a bit of an aide-mémoire for myself. If you ever need to see which key signed an APK (for example to compare to a client ID in the API console when implementing Google+ Sign-In) you can actually extract the cert from the APK, and test it. First you need to unzip the APK:     unzip ~/my-app.apk You're going to see a bunch of files extracted, including a CERT.RSA, which is usually in META-INF. If you use an alias for your key, it'll be THAT-ALIAS.RSA.     inflating: META-INF/MANIFEST.MF     inflating: META-INF/CERT.SF     inflating: META-INF/CERT.RSA You can then output the signatures for the certificate with the keytool app:     keytool -printcert -file META-INF/CERT.RSA This will print out the various fingerprints, and let you know the details of the certificates owner - handy for checking whether it was accidentally signed with a debug key (which will look something like this):     Owner: CN=Android Debug, O=Android, C=US     Issuer: CN=Android

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

As part of the release of Google+ Sign-In, some people have noticed that signing in via the Sign In button  doesn't redirect them to Google, then back to the site, as would have happened if they'd been using the basic OAuth 2.0 flows . One of the backbones of Javascript security is the same-origin policy, which limits running code from being able to see things from sources other than its own. For example, HappyImageWebsite.com can't go and read what's happening on another window showing SecureBank.com. Sometimes though it is helpful to be able to communicate between windows, or between a window and an iframe, that are from different origins. This is tricky, and has been the source of many interesting workarounds over the years. The HTML 5 web message specification  standardised a solution to this problem, in the form of the window.postMessage() method. As you might guess, this lets you send a message from one window to another in a pretty straightforward way, eve