Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize push token handling in case of multiple tokens #2738

Closed
jmozd opened this issue May 22, 2021 · 3 comments
Closed

Optimize push token handling in case of multiple tokens #2738

jmozd opened this issue May 22, 2021 · 3 comments

Comments

@jmozd
Copy link
Contributor

jmozd commented May 22, 2021

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.

@cornelinux
Copy link
Member

Could be related to #1668

@jmozd
Copy link
Contributor Author

jmozd commented May 22, 2021

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.

@jmozd
Copy link
Contributor Author

jmozd commented May 22, 2021

should we take this to issue #1668 and close this enhancement request as "duplicate"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants