You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
see https://community.privacyidea.org/t/firebase-access-suddenly-broken-partially/2018/6 : user had two push tokens registered in PI, with only one assigned to hosts by the PI administrator. When the user removed the "extra" token from the according PI App, the user could no longer use the other (assigned) token for 2FA (Firebase reported 404 for the removed token ID, which then made PI server bail out on the request). The situation with the extra token didn't cause harm for months, until the user removed the extra token from the personal device / app.
Describe the solution you'd like
If Firebase reports 404 when trying to trigger a push token, and PI has more than one push token issued by the user, retry the request with the next push token or, if already triggered (we could see that the "correct" push token was indeed triggered by PI), simply ignore the 404 and return "ok".
Describe alternatives you've considered
Only current chance to resolve the issue was to remove the extra token from PI. Since simple user action (removing a particular extra push token from the app) will break operations non-obviously, PI might at least warn the user when registering an extra push token - and notify the admin of such a situation or offer a "consistency check" for the PI system, that the admin can trigger on occasions where dubious errors occur.
Additional context
The user logged in to a system, for which per PI rules the user had a push token assigned to that host. Actually that push token was triggered by PI server (and the user acknowledged the request), but PI server very early bailed out with 400 code (the the PAM module on the client system) when PI tried to trigger the extra push token (as it no longer was in any App, because the user deleted it).
I've been told by PI team years ago that multiple push tokens for a user might not be a good idea and we've never got it to work. But obviously, simple user action can break operations and without additional debugging code in PI server I would have never found out that an extra push token was part of the picture.
The text was updated successfully, but these errors were encountered:
Yes, this seems to be the issue here, too. I only learned late into the problem that the user had a second push token registered to the user id, and had it added to PI App on a separate phone. And the problem may well have come up once the device with the extra token was full-reset, or the app de-installed from that device (I don't have full details).
The extra push token was not added to any host in PI, it just "existed" in the list of tokens the user had issued, alongside the "main" push token that had been added to hosts.
Is your feature request related to a problem? Please describe.
see https://community.privacyidea.org/t/firebase-access-suddenly-broken-partially/2018/6 : user had two push tokens registered in PI, with only one assigned to hosts by the PI administrator. When the user removed the "extra" token from the according PI App, the user could no longer use the other (assigned) token for 2FA (Firebase reported 404 for the removed token ID, which then made PI server bail out on the request). The situation with the extra token didn't cause harm for months, until the user removed the extra token from the personal device / app.
Describe the solution you'd like
If Firebase reports 404 when trying to trigger a push token, and PI has more than one push token issued by the user, retry the request with the next push token or, if already triggered (we could see that the "correct" push token was indeed triggered by PI), simply ignore the 404 and return "ok".
Describe alternatives you've considered
Only current chance to resolve the issue was to remove the extra token from PI. Since simple user action (removing a particular extra push token from the app) will break operations non-obviously, PI might at least warn the user when registering an extra push token - and notify the admin of such a situation or offer a "consistency check" for the PI system, that the admin can trigger on occasions where dubious errors occur.
Additional context
The user logged in to a system, for which per PI rules the user had a push token assigned to that host. Actually that push token was triggered by PI server (and the user acknowledged the request), but PI server very early bailed out with 400 code (the the PAM module on the client system) when PI tried to trigger the extra push token (as it no longer was in any App, because the user deleted it).
I've been told by PI team years ago that multiple push tokens for a user might not be a good idea and we've never got it to work. But obviously, simple user action can break operations and without additional debugging code in PI server I would have never found out that an extra push token was part of the picture.
The text was updated successfully, but these errors were encountered: