#26503 closed Bug (fixed)
SessionStore nonexistent key example is outdated
Reported by: | jmcbailey | Owned by: | Berker Peksag |
---|---|---|---|
Component: | contrib.sessions | Version: | 1.8 |
Severity: | Normal | Keywords: | |
Cc: | Carl Meyer, berker.peksag@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The documentation at https://docs.djangoproject.com/en/1.8/topics/http/sessions/#using-sessions-out-of-views has the following example:
from django.contrib.sessions.backends.db import SessionStore s = SessionStore(session_key='no-such-session-here') s.save() s.session_key 'ff882814010ccbc3c870523934fee5a2'
However, when I run this with Django 1.8.12, s.session_key
actually returns None
.
The reason is that when the SessionStore
instance is saved (with must_create=False
, i.e. the default), it results in a call to self.load()
, which looks for an existing Session object with the given session_key. This of course does not yet exist, so the session_key gets set to None
- see https://github.com/django/django/blob/1.8.12/django/contrib/sessions/backends/db.py#L29
I don't know if this change in behaviour was intentional or not, but I didn't see any mention of it in the 1.7 or 1.8 release notes, and of course the fact that the behaviour is different to what's documented suggests it was not intentional. (I haven't checked the file's history, but it definitely did work as documented in Django 1.6.)
In any case it's a pretty minor issue, only affecting one unit test of mine, and was very easy to work around.
Change History (6)
comment:1 by , 9 years ago
Cc: | added |
---|---|
Summary: | SessionStore is not behaving as documented → SessionStore nonexistent key example is outdated |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 8 years ago
Cc: | added |
---|---|
Has patch: | set |
Owner: | changed from | to
Status: | new → assigned |
I agree that the example can be removed. I've opened a PR: https://github.com/django/django/pull/6676
The behavior changed in this security fix: 66d12d1ababa8f062857ee5eb43276493720bf16 and again in 3389c5ea229884a1943873fe7e7ffc2800cefc22 where the snippet now raises
UpdateError
.I'm not sure if the example is demonstrating anything useful now. Maybe it could simply be removed?