On Sun, 2008-04-06 at 08:21 -0700, mrts wrote: [...] > My personal use case: > --------------------- > > User sessions are used apart from django.auth.models.User. The > application logic doesn't fit well with Django auth (auth > features are not needed and create a minor security risk if an > admin user inadvertently or maliciously enables staff status for an > external > user -- that plainly should not be possible). There is a separate > custom user model for external users (no passwords as user data > is loaded from SSL client certificate). Django auth is used > nevertheless for admin (for internal users). The framework has > it's own login and logout views. During login, minimal data about > the user is loaded from SSL client certificate and stored in > session. During logout, session data needs to be completely > destoyed. > > It is paramount that there is a guarantee of no collisions in > session keys, someone else cannot hijack the session and all data > is destroyed after logout. > > CSRF middleware is used for protection during form submission > (btw, I have some problems with it, but this is a different > issue). > > The use case I had in mind when proposing the "bucket": > -------------------------------------------------------
[...] > 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/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
