Il 04/06/26 11:41, Francesco Chicchiriccò ha scritto:
On 04/06/26 11:37, Massimiliano Perrone wrote:
Hi all, while reviewing the authentication failure handling, I
noticed that the current behavior around *maxAuthenticationAttempts*
seems counterintuitive.
With `maxAuthenticationAttempts = 3`, the user is currently suspended
only after the fourth failed login attempt. This happens because the
suspension check uses a strict `>` comparison against the configured
threshold.
My expectation would be that `maxAuthenticationAttempts` represents
the maximum number of failed authentication attempts allowed before
suspension, so a value of `3` should suspend the user on the third
failed attempt.
I also did a quick check around and the behaviour is always: when the
configured maximum is reached, the account is disabled.
Do you think it would make sense to change the check from > to >=, so
that the account is suspended when the configured threshold is reached?
For example:
* maxAuthenticationAttempts = 3
* failed login #1 -> failedLogins = 1, user not suspended
* failed login #2 -> failedLogins = 2, user not suspended
* failed login #3 -> failedLogins = 3, user suspended
Hi,
I think that the current behavior is correct.
maxAuthenticationAttempts = 3
means that the maximum number of authentication attempts allowed
before suspend is 3.
Hence, after 3 failures (e.g. the maximum number allowed), nothing
happens.
if the 4th failure arrives, the user is suspended.
Reading the property without knowledge of the implementation, I would
expect it to answer the question: how many authentication errors can a
user make before being suspended? My expectation was 3, but with the
current behavior, the answer is 4.
Regards.
--
Massimiliano Perrone
Tel +39 393 9121310
Tirasa S.r.l.
Viale Vittoria Colonna 97 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
