Out of the blue, I’ve been unable to 2FA-validate logins via Push token - the client system (where the user tries access) receives an HTTP error when contacting the PI server, although the PI app actually receives the request to authenticate.
In PI’s log, I found the following error, twice per authentication request:
[2021-05-21 11:34:27,663][14536][139832521623296][WARNING][privacyidea.lib.smsprovider.FirebaseProvider:169] Failed to send message to firebase service: {
“error”: {
“code”: 404,
“message”: “Requested entity was not found.”,
“status”: “NOT_FOUND”,
“details”: [
{
“@type”: “type.googleapis.com/google.firebase.fcm.v1.FcmError”,
“errorCode”: “UNREGISTERED”
}
]
}
}
This happens also with the latest code, as updated today (v3.5.2), and of course after restarting PI.
Searching the net, I found references to expiring Firebase credentials, “for good measure” I created a new key in Firebase and provided the according new JSON file (with the updated private key) to PI, restarted httpd but still have the errors and same behavior.
Any insight into what PI / Firebase is missing, that may have changed in the last few days?
Hi, this can indicate that the firebase token of the smartphone that should receive the push has changed. If that happens, the App will try to update the firebase token with the PI server. You can also do this manually from Settings → Sync. Hope this helps.
I issued “settings → sync” in the PI app and received a window “synching tokens” “all tokens were synced.”
Unfortunately, this didn’t change anything wrt to the described problem: Once the user initiates the 2FA push, I see the Firebase error in the PI logs, the action on the client system immediately aborts because of the HTTP error (400), but the PI app does receive the request and the user can confirm the login in the app. Since the client system already aborted the 2FA (because of the original HTTP request failing with 400), the client system never receives the confirmation.
“Fun fact”: When the user tests the token via the PI web interface (selecting the token, entering the PIN and then clicking on “test token”), no error is logged (and the push message reaches the token, as is the case during actual login attempts).
When debugging the Firebase request, I noticed that the push token ID looked wrong… and found that the user had more than one Push Token registered. Once he reduced this to only a single push token, things again started to work out for him.
I recall having discussed this in 2019 and that I was told “setting up more than a single push token for a user currently is a problem.” This holds true even if the second token isn’t even referenced in the list of tokens assigned to a machine - the user having more than one registered seems sufficient. Maybe PI should warn the user when registering a second (active) push token?
And the user pointed out that the second token existed for ages - so no “recent change”, maybe some ordering issue in some database reply or alike,
One follow-up, though, for the PI developers: If I understood correctly, the user had removed the extra token from his device. So there was a token registered in PI, but no PI App that had that token configured. I feel that PI’s code could be improved here, reacting to the Firebase 404 response by checking if another (push) token is known for the user and if so, to try that one before bailing out.
Did the user have two push tokens ernrolled in privacyIDEA and he deleted one of them on the phone? And did the user expect the remaining token to receive the challenge?