Closed afuetterer closed 4 months ago
Alright, I see that the actual benefit is far from significant. Let's close this.
Hey, sorry I did not answer. I think I tested that back then, when you gave us the tip with the md5 hashes. I think with md5 or sha1 or plain the overhead of just logging in is the dominant part. With the default algorithm its probably not so much the hashing algorithm, but the 1000 rotations or so which make the difference.
Yes, no problem. I thought it might make a difference.
Another approach would to .force_login()
users instead of .login(username, password)
. But md5 might be fast enough already.
One part of the huge "dev setup refactoring of 2023" was switching to a faster password hashing in the testing config: https://github.com/rdmorganiser/rdmo/pull/664/commits/56c6e0ea1c04749dac85e9102be14a0b806c163b
There are so many individual tests in the test suite (at the moment 23824) and most of them need an authenticated user. I propose changing the password hasher again.
There is
UnsaltedMD5PasswordHasher
in thedjango.contrib.auth.hashers
, which is of course very insecure, but in testing that does not matter. It is much faster then the already fastMD5PasswordHasher
. Sadly theUnsaltedMD5PasswordHasher
is deprecated and will be removed in Django 5.1. So it would only be a temporary solution, until we reach Django 5.1.@jochenklar already mentioned django-plaintext-password last time. Which sounds like a joke, but it is the fastest password hasher there is in my opinion. This would mean another dependency in the testing group, which I am fine with.
Long term I want to replace most of the
client.login(username, password)
withclient.force_login(user)
, which does not use the authentication system at all. But that is a bit of work.What do you think? The time difference in a whole test suite run will be significant.