Context Navigation

Changes between Initial Version and Version 1 of Ticket #28285

Timestamp:

Jun 8, 2017, 12:46:41 PM (8 years ago)

Author:

Tim Graham

Comment:

Here's my understanding of the scenario:

User X logs in and creates session A
Number of hash iterations changes in Django due to a software upgrade
Session A is still valid at this point
For whatever reason (using a different browser perhaps), user X logs in and creates session B, triggering a password hash upgrade and an invalidation of session A

I don't think there's a way to keep session A valid is this scenario. Am I misunderstanding something?

-              initial
+              v1
 The code below, from contrib.auth.base_user.py, says "hash upgrade is not a password change"
+The code below, from `contrib.auth.base_user.py`, says "hash upgrade is not a password change"
 {{{
 …
 but the code in contrib.auth.__init__.py/get_user()
+but the code in `contrib.auth.get_user()` verifies the session by comparing a salted hmac of the password hash to the same thing stored in the session.
+verifies the session by comparing a salted hmac of the password hash to the same thing stored in the session.
+If we update the password hash the salted hmac will change. Therefore, the session will no longer be considered valid and will be flushed. We can keep the session alive by updating the HASH_SESSION_KEY in request.session e.g. via the update_session_auth_hash() function. But this is not called by the setter function when the hasher is updated.
+If we update the password hash the salted hmac will change. Therefore, the session will no longer be considered valid and will be flushed. We can keep the session alive by updating the `HASH_SESSION_KEY` in `request.session` e.g. via the `update_session_auth_hash()` function. But this is not called by the setter function when the hasher is updated.
 So the first time the user logs (with the correct password) following an upgrade, their (valid) session will be flushed and they will be logged out again.