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
On a failed login, the Portier broker deletes the session preventing further attempts to log in with that session. It would be helpful to be able to configure the broker to instead only delete the session on a successful login; as well as the after a deadline has expired as it already does.
From our experience, the current behaviour hurts the UX as we see regularly people failing to log in for legitimate and expected reasons but (we assume) very few attempts to brute for the code; which for most is moot and prevented by any CSRF protection (ie. a cookie) in the resource provider.
different browsing context; resource provider is open in one browser (or incognito window) but when opening the link in the email it pops open another browser (or non-incognito)
This problem is potentially exasperated by the rate limiter as our users get at least confused and then re-attempt fresh logins which also fail as they are still incorrectly doing something or other.
The text was updated successfully, but these errors were encountered:
It may be worth also exploring (maybe behind an option if it feels icky) if a given email address is trying to log into the same client_id and there currently is an outstanding session for that, to just resend the same code to the user; if say there is at least a few minutes left on the clock or maybe if it was within N minutes of the original one having being sent.
On a failed login, the Portier broker deletes the session preventing further attempts to log in with that session. It would be helpful to be able to configure the broker to instead only delete the session on a successful login; as well as the after a deadline has expired as it already does.
From our experience, the current behaviour hurts the UX as we see regularly people failing to log in for legitimate and expected reasons but (we assume) very few attempts to brute for the code; which for most is moot and prevented by any CSRF protection (ie. a cookie) in the resource provider.
This is described in #670 (comment) and followed up by #670 (comment)
Common reasons for a failed login:
This problem is potentially exasperated by the rate limiter as our users get at least confused and then re-attempt fresh logins which also fail as they are still incorrectly doing something or other.
The text was updated successfully, but these errors were encountered: