On Wed, May 5, 2010 at 10:24 AM, George Sakkis <george.sak...@gmail.com> wrote: > 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 >
If you allow users to present new session ids without replacing them, then you open up an attack vector for a session fixation attack. The default behaviour is default for a reason. Cheers Tom -- 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.
