Do not define the magic value twice, instead reuse the value from the
auth code also in the related tests.
Signed-off-by: Henning Schild <henning@hennsch.de>
bcrypt < 5 always truncated overlong passwords for us, since version 5
we need to do that on our own or hope our password library does it for
us.
In order to support both passlib and libpass with bcrypt >= 5 we simply
truncate if needed so it does not matter which of the two libraries is
used.
Closes: #1896
Signed-off-by: Henning Schild <henning@hennsch.de>
This time the other way around just to be extra sure. Radicale currently
does not ever call bcrypt.hashpw, let alone with an overlong password.
Related-to: #1896
Signed-off-by: Henning Schild <henning@hennsch.de>
The maximum password length of bcrypt is 72 chars, any longer password
will create the same hash. Some password/hashing lib combinations
truncate for us, for others we might catch exceptions. So test all that
to make sure we can handle all combinations.
Related-to: #1896
Signed-off-by: Henning Schild <henning@hennsch.de>
In the failed login cache cleanup loop, the tuple unpacking was using
`login` as the local variable name, silently overwriting the current
user's login with the one retrieved from the expired cache entry.
This caused subsequent backend authentication (e.g. IMAP) to be
attempted with the wrong username, resulting in spurious auth failures
for legitimate users whenever an expired failed-cache entry happened
to be present at the same time.
Rename the loop variable to `login_expired` to avoid shadowing the
outer `login` variable, and fix the associated debug log to reference
`login_expired` instead of the previously incorrect `login_cache`.
Fixes: intermittent authentication failures when _cache_failed contains
expired entries from previous failed login attempts by other users.
Signed-off-by: webmaster <webmaster@jbsky.fr>
