Upgrading Firebase.com & Using Google Sign In on Android

Very quick post on a problem I've seen a few people hit where they are upgrading a Firebase.com project which uses Google Sign In on Android.

Just Tell Me What To Do Already

1. Upgrade your Firebase.com project


2. Connect your Android app, but do not enter a SHA1


3. Go to the old Google Developers/Google Cloud project you were using and copy each client ID used for an Android app (e.g. the debug and release versions at least). 


4. In the Auth > Sign In Method > Google panel, enter the client IDs you copied before. 


This ensures your existing app keeps working, and sets you up for transitioning to the new SDK. 

Why Am I Doing This?

There are a couple of things to know: 
  1. The specific combination of Android package name and SHA1 is unique across Google. It can only exist in a single Google project, and is associated with a single client ID. 
  2. An upgraded Firebase project is a Google project underneath. 
This means if you go through the upgrade flow, attempt to connect your Android app and enter a SHA1 used by an existing project, you will get an error. The tempting thing to do is to delete the client ID in the old project, and add the SHA1 in the new project

The problem with this is that if you have already have an app published using Google Sign In and Firebase 2.x, the sign ins suddenly will be coming from a different Google project, and so will start failing with an "Invalid authentication token" error. 

If you've done that - no problem, just remove the SHA1 from the new Firebase console (you can't remove the last one, but just edit it to something different), re-add them on your old Google project, and whitelist the client IDs as above.

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

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

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