On May 4, 11:05 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Tue, May 4, 2010 at 3:11 PM, George Sakkis <george.sak...@gmail.com> wrote:
> > Is this a bug or a feature ?
>
> Take a look at the source (django/contrib/sessions/backends/db.py;
> line 16 - the load() function). If the session key doesn't exist in
> the database, a new session key will be generated. This prevents users
> from being able to "choose" arbitrary session keys, so that's the
> correct thing to do.
Ok, the rationale makes sense (as a default, overridable choice at
least) but the API could be less surprising, e.g. raise an exception
when a non auto-generated key is passed. Also it turns out that it
doesn't really prevent setting a key explicitly, it just makes it more
cumbersome:
session_key = 'secret!!1!'
s = SessionStore(session_key)
s['foo'] = 'bar'
s.session_key = session_key # I *really* mean session_key dammit
s.save()
This creates two entries, one with a random key and one with
session_key but only the latter's session_data are updated.
The following avoids creating the random key in the first place:
s = SessionStore()
if not s.exists(session_key):
s['foo'] = 'bar'
s.session_key = session_key
s.save()
I'm not sure if these are unintended implementation side effects but
they seem incongruent.
George
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
