The Android app sign-in failure was a server bug, and it is fixed: the sign-in succeeded and tokens were issued, but the server only accepted browser cookie sessions, so the app's session check was rejected and it discarded its tokens. CallPages now accepts the app's signed access token as a session too.
Owners signing in to the CallPages Android app hit a wall: Google accepted them, the app received its sign-in tokens — and then immediately reported that sign-in didn't complete. Every time, on every flow, no matter whose account it was.
A sign-in that succeeded, then failed
This one earned a forensics file. When app sign-in kept failing identically — for the owner testing it, on a phone where the same Google account worked everywhere else — we stopped guessing and reconstructed a single real attempt from the server's records, second by second.
The surprise: the sign-in had worked. Google accepted the account, the server created the one-time sign-in record and marked it used, and issued the app its token pair — all within two seconds. The app then did the sensible thing: it asked the server "who am I?" to confirm the session, presenting its signed access token. The server's session check, written for the browser world, only knew how to read session cookies. It answered 401. The app treated that as a failed sign-in, wiped the tokens it had just been given, and showed the only message it could: "Sign-in didn't complete."
That is why the failure was identical every time and for every account — and why it predated the app version everyone (us included) initially suspected. The door was fine; the lock only recognized one of the two keys we ourselves had issued.
The fix, and the tripwire
The server now accepts both keys: the browser cookie session, unchanged and checked first, and the app's signed access token, verified as an access token specifically. App sign-in responses also set the session cookie pair, so the dashboard the app opens after sign-in starts out properly signed in instead of inheriting the same problem one screen later.
And so that no future version of this can hide: the server now takes automatic failure reports from the app — a small, privacy-filtered report (no tokens, no personal details) that lands in our error log the moment a sign-in step fails. This post is about the server fix, which is live. The companion app update that sends those reports from the phone ships as its own Android release, on the app's own schedule — we will announce it on the Android releases page when the download surface serves it.
How it works
- We reconstructed one real failed sign-in second by second from the server's own records: the sign-in itself had succeeded, and a fresh token pair had been issued
- The failure was the very next step: the app confirmed its session by presenting its signed token, but the server only accepted browser cookie sessions — it answered 401, and the app, quite reasonably, discarded its fresh tokens
- The server now accepts the app's signed access token as a session as well (the cookie path is unchanged and still checked first), and app sign-ins also set the session cookies the in-app dashboard needs
- The server also now accepts automatic failure reports from the app, so if sign-in ever breaks again we will see it the moment it happens — nobody will have to describe it from memory
See it live: Mi Junta
Mi Junta — CallPage · Mi Junta — website
