On Thu, Jan 15, 2015 at 12:05 AM, Horacio G. de Oro <[email protected]> wrote:
> If you see the new hash in the database, I think that, maybe the admin, is > saving the user instance with the new hash. And doing that, ie: save()'ing > the user returned by authenticate() solved the issue for me too (but I > don't want to save the user every time he/she logins, just in case the > hasher parameters changed). > For sake of completeness, this is not specific to the admin. It's done by django.contrib.auth. The default ModelBackend for authentication will update the hashed password during any successful login, if either of these conditions is met: 1. The hashed in the password retrieved from the database used a hash algorithm other than the algorithm of the currently-preferred password hasher, or 2. The hasher indicates that the stored hashed password needs to be updated. In the case of the PBKDF2 hasher, you ran into (2) -- that hasher checks whether the number of iterations used on the hashed password is different than the current specified number of iterations, and forces an update of the stored hashed password on a mismatch. The update itself is done by the User instance, calling self.save() and specifying that only the 'password' field will be updated. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg_7qcv9sjafUe8SF7sMUGqRL-7ZD%3Djnymku0oMf9GOE-g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
