[Django] #31970: Logging in from one browser logs me out from other browsers
Django
--------------------------------------------+------------------------
Reporter: אורי | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--------------------------------------------+------------------------
- I upgraded Django from 3.0.6 to 3.1.1 with `DEFAULT_HASHING_ALGORITHM =
'sha1'`.
- I was logged in from several browsers.
- The first time I login from a new browser with Django 3.1.1, all my
other sessions expire, and I'm automatically logged out from all the other
browsers.
- This happens only once, at the first time I login with Django 3.1.1.
- I think it's a bug, since users may use several browsers and they don't
need to be logged out when they login from a new browser.
--
Ticket URL: <https://code.djangoproject.com/ticket/31970>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by אורי):
* cc: אורי (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:1>
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => worksforme
Comment:
Hi Uri.
I can't reproduce this.
> ...all my other sessions expire, and I'm automatically logged out from
all the other browsers.
The question is how does that happen?
Other sessions (other rows in the `django_session` table, assuming you're
using the DB backend) are untouched when you login.
If you can show that other records in the session store are updated
(somehow) when logging in that would be a bug.
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:2>
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
Replying to [comment:2 Carlton Gibson]:
> Other sessions (other rows in the `django_session` table, assuming
you're using the DB backend) are untouched when you login.
>
> If you can show that other records in the session store are updated
(somehow) when logging in that would be a bug.
>
Maybe it's the same row? I login with the same user ID with all my
browsers. If the original row is updated, does this force a logout to all
other sessions? Their cookies would remain the same.
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:3>
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
Hi Uri. Separate logins have separate sessions. (On a test project, empty
your sessions table. Log in twice from separate browsers. Count rows in
table.)
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:4>
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
Replying to [comment:4 Carlton Gibson]:
> Hi Uri. Separate logins have separate sessions. (On a test project,
empty your sessions table. Log in twice from separate browsers. Count rows
in table.)
Thank you, I understand. I will look into this issue with my programmer to
see why it happens.
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:5>
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
OK, follow-up if you get an answer, but I wouldn't spend too long: I
suspect it's just an artifact.
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:6>
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
From https://docs.djangoproject.com/en/3.1/releases/3.1/:
> The default iteration count for the PBKDF2 password hasher is increased
from 180,000 to 216,000.
So I guess, if a user's password was hashed with 180,000 iterations with
Django <= 3.0, and then they log in with Django 3.1, then the password
will be hashed with 216,000 iterations, and all the other sessions become
invalid (although they are not changed in the sessions table). So all
other browsers will be logged out. This will happen any time the number of
iterations will change.
https://github.com/django/django/commit/b5db65c4fbcf05cb03d039166abf115930dc7577
Did you check that if you login with Django 3.0 with 2 browsers, and then
upgrade to 3.1 and then logout and login again, you are still logged in
with the other browser?
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:7>
Django
change in PBKDF2PasswordHasher.iterations)
----------------------------------+--------------------------------------
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:8>
Django
change in PBKDF2PasswordHasher.iterations)
----------------------------------+--------------------------------------
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* resolution: worksforme => wontfix
Comment:
OK, yes I see it.
We update the hasher iterations every release. I can't see that this is
something we can or will change.
I don't think requiring sessions to be refreshed once every nine months is
a big ask.
I see you've posted to the mailing list (which is correct if you don't
agree here) so we'll see how that goes.
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:9>
Django
change in PBKDF2PasswordHasher.iterations)
----------------------------------+--------------------------------------
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
Just for sanity I testing the same upgrading from 2.2 to 3.0. Same result.
Bottom line is that if you change the password hash, the old session hash
will no longer validate, the same as described in the
[https://docs.djangoproject.com/en/3.1/topics/auth/default/#session-
invalidation-on-password-change Session invalidation on password change]
docs.
(I can't see that there's any possibility of a change there...)
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:10>
Django
change in PBKDF2PasswordHasher.iterations)
----------------------------------+--------------------------------------
Type: Bug | Status: closed
Component: contrib.sessions | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
Thank you, Carlton. I understand. I replied to the mailing list, but just
in case I'm linking our patch here:
https://github.com/speedy-net/speedy-
net/blob/master/speedy/core/patches/session_patches.py
I also think it would be better to change the number of iterations not
every 8 months, but every 2 years (with a new LTS release).
--
Ticket URL: <https://code.djangoproject.com/ticket/31970#comment:11>