On Apr 3, 4:36 am, mrts <[EMAIL PROTECTED]> wrote:
> Quoting #6941:
> [4:17pm] jacobkm: Also, there's the question of whether the session is
> tied to the browser or to the user -- we're a bit muddled there
> currently.
Let me reiterate a position that I posted on #6941. After reviewing, I
actually *don't* think we're all that muddled. A session is
{{{request.session}}} and is represented by the browser's session.
Whereas a user is {{{request.user}}} and is completely separate.
That being said, there are many use cases that would require a change
{{{request.user}}} to somehow signal the creation of a new session. I
am not sure how we should represent this this other than either making
it the forced default or having people wrap the login views.
> What I personally need is a secure session framework that
> * has a well-defined relationship to request.user, preferably being
> cleanly separated from it,
> * will not be re-used under any circumstances (#6941) and is
> protected against key collisions (#1180),
> * supports concurrency (uses locking throughout as Beaker does, think
> mod_wsgi with threads),
> * can be cleared/destoyed,
> * supports controlling session lifetime (http://
> code.djangoproject.com/ticket/2548#comment:8 describes the use case).
After reading through these, I think most of these can be satisfied
with the proper session backend. Why not write a "secure" session
backend? (You would presumably also need to require signed cookies for
the session.) I would be interested to see what it would look like.
Cheers,
Mike Axiak
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
