Except request.user is loaded by using a user id stuffed in session, so they are
definitely tied together right now :)
--
Collin Grady
The reward of a thing well done is to have done it.
-- Emerson
No, please post here. I know you want there to be a formal spec
process, but there isn't. Right now the way we decide things is by
posting them here, and you need to do the same.
Jacob
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/
[...]
> So, there are two types of session data, one type is related to
> Django auth user and should be destroyed from the session when
> the user logs out. The other type does not require login and
> should remain in the session after logout.
No there are not two types of session data here. The shopping cart is
*not* session data. It transcends a single session. It is permanent data
that would be stored in the shopping cart model, which contains a
foreign key to the user. This is a case of needing to model the data
correctly, rather than trying to shoehorn it into the session model.
> > I don't see the need for an extra method here. Why isn't this just
> > something logout() would do?
>
> This is something that logout() *might* do. But considering the
> case above, I'm rather +0 for adding a destroy_session parameter
> to logout() (and login() for that matter) that defaults to False,
> or a wrapper, secure_logout()/secure_login().
>
> According to my personal use case, as auth is not used, an
> explicit session destruction mechanism is needed, thus
> destroy() is required. logout() should use destroy(), not
> vice-versa.
Your use case doesn't require extra handling at all. You have some
sessions that must be removed at logout. So your logout method calls the
delete method on the session object. It's now destroyed. Game over for
that session and no extra method is required.
Realise that I am in agreement with you that logout (and possibly login,
I haven't worked through the implications there) should be changed to
clear the session by default. There's no strong reason not to do that,
since the session is over when logout is called (I'll raise that
separately at an appropriate moment, since most people won't be
persisting this far into this thread and there are a few active threads
going on at the moment). We don't need logout_A and logout_B, we just
need to do the right thing here.
[...]
> Delete is not documented in
> http://www.djangoproject.com/documentation/sessions/#using-sessions-in-views
Lack of documentation in one place doesn't justify adding a whole extra
method that does the same thing as a single line of code. We're in this
fortunate position of being able to add to the documentation to fix
things like this.
> It requires the session key as parameter, so it is cumbersome to
> use.
Oh, come on! Leave the hyperbole at home. Instead of
my_session.delete()
you have to write
my_session.delete(my_session._session_key)
Hardly an onerous requirement and quite possibly something we could
change to default to self._session_key. I'll find out from Jacob why he
went with this approach in the first place. It might be an oversight, or
there might be some subtlety involved. In either case,this is both
currently usable and possibly able to made easier, in both cases without
adding a whole new method.
I'll address the implementation changes you're proposing in another post
when I have some more time later today.
Best wishes,
Malcolm
--
I don't have a solution, but I admire your problem.
http://www.pointy-stick.com/blog/
Realise that I am in agreement with you that logout (and possibly login,
I haven't worked through the implications there) should be changed to
clear the session by default. There's no strong reason not to do that,
since the session is over when logout is called.
No, I don't see any need for this at all. Once you've logged out, the
session is over. Stuff you want to keep beyond that is not session data.
Malcolm
--
If Barbie is so popular, why do you have to buy her friends?
http://www.pointy-stick.com/blog/
It fixes a lot of weirdness I was experiencing. It is still not thread
safe though I am not sure that is an issue since in my (limited)
testing there was a one-to-one mapping between thread and session.
BTW When debugging the issue I arrived at the following logout method
to clean stuff up:
def logout(request):
session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME, None)
request.session.delete(session_key)
request.session = None
response = HttpResponseRedirect("/clients/")
response.delete_cookie(settings.SESSION_COOKIE_NAME)
return response
Simon
Of course, for this to work one would need a carefully crafted model
(again as mentioned previously). The data (shopping cart) would need
to be attached to the session for anonymous users, but attached to the
user for logged in users. Part of logging a user in would be to make
that transition of the data from session to user. Then deleting
session data on logout becomes a non-issue.
--
----
Waylan Limberg
way...@gmail.com