django.contrib.sessions problems - Django developers

Message from discussion django.contrib.sessions problems

Malcolm Tredinnick

More options Apr 5, 11:17 pm

From: Malcolm Tredinnick <malc...@pointy-stick.com>

Date: Sun, 06 Apr 2008 13:17:31 +1000

Local: Sat, Apr 5 2008 11:17 pm

Subject: Re: django.contrib.sessions problems

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On Sat, 2008-04-05 at 11:31 -0700, mrts wrote:

[...]

> Once Python 2.3/4 support will be dropped, we can start using
> higher-grade hash algorithms from 2.5 hashlib throughout. But
> this is offtopic for current discussion and will not happen in
> the foreseeable future.

It will be a while beyond that point, too, since you can't just
magically rehash everything with the new algorithms. So you have to be
able to read auth data generated with older algorithms.

> The relationship between user and session
> -----------------------------------------

> Associating some session data to logged-in users is a common use
> case. That data needs to be deleted once the user logs out.

> Currently sessions and users are separated (I haven't checked how
> the user is saved in the session, I assume the user is actually
> stored in the session under a specific key). This is very good
> and should remain so, but doesn't cater for the use-case.

> I propose we add a "data bucket" to the user object that can be
> used for that purpose.

Which would mean a user could only be logged in once each time. :-(

Session objects is the right place to store all session-related data.
It's a many-to-one relation to each user. If you want something that's
one-to-one with a user, that isn't session data and is easy to implement
via your own model, but I'm not sure it's common enough to have a common
API required in Django itself.

You'll need to elaborate more here on use-cases, I think. It might just
be that you haven't explained what you're wanting to do here.

> >>> u = authenticate(username=username, password=password)
> >>> type(u.data)
> <type 'dict'>
> >>> u.data['foo'] = 'bar'
> >>> u.save() # pickles the data dictionary and saves it in a text
> # field
> >>> u.data['foo']
> 'bar'
> >>> logout(request)
> >>> u.data
> {}

> It should be documented that all session data tied to a user
> should be saved in that bucket. Sessions may be used for other
> purposes or without django.contrib.auth, so they should
> definitely remain separate from the user generally.

> That would fix #6941.

> I'm ready to implement this.

> Clearing a session
> ------------------

> Sessions should have a destroy() method that clears the keys and
> removes the corresponding session object from the backend store.

I don't see the need for an extra method here. Why isn't this just
something logout() would do?

It's easy to destroy a session. Just call delete() on the object (that's
your destroy() method). The root issue is managing the lifetime and I'm
pretty sure that a sessions lifetime ends either when it has expired
(daily-cleanup nukes those things, or whatever equivalent you're using)
or when the user logs out -- thus explicitly ending their session. We
don't do the latter at the moment, but that would seem to be the
straightforward fix here.

Regards,
Malcolm

--
The early bird may get the worm, but the second mouse gets the cheese.
http://www.pointy-stick.com/blog/

Reply to author Forward