Changes between Version 11 and Version 12 of DjangoSpecifications/Contrib/Sessions


Ignore:
Timestamp:
Jun 22, 2008, 10:02:36 AM (16 years ago)
Author:
mrts
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DjangoSpecifications/Contrib/Sessions

    v11 v12  
    33= Session framework improvements =
    44
    5 '''This is outdated and will be updated as time allows'''.
     5The following tickets are related to sessions: comment:ticket:5549:5, #2548, #3304, #1180, #6791, #6941, #6984, #7515.
    66
    7 The following tickets call for improvements in session logic: comment:ticket:5549:5, #2548, #3304, #1180, #6791, #6941, #6984, #7515.
    87Some of the tickets are interrelated, some of them pose security risks.
    9 Additionally, sessions are not thread-safe (see http://groups.google.com/group/django-users/browse_frm/thread/a7d42475b66530bd) and are missing a single method to destroy the session (ad-hoc workaround: iterate through all session keys and delete them one by one).
    10 Also, the relationship between `request.user` and sessions should be clearly defined to avoid overwriting the user key in session.
    118
    129See also the discussion at http://groups.google.com/group/django-developers/browse_thread/thread/fbcfa88c997d1bb3 .
    … …  
    1411Other projects to draw inspiration from: [http://beaker.groovie.org Beaker].
    1512
    16 A coherent solution should be provided to all these issues by refactoring `django.contrib.session`.
    17 
    1813== Proposal ==
    1914
    20 `django.contrib.session` should be a secure session framework that
    21  * will not be re-used under any circumstances (#6941), is protected against key collisions (#1180) and session hijacking (#6941),
    22  * supports concurrency by using locking throughout (as Beaker does, think mod_wsgi with threads and AJAX), see also [DjangoSpecifications/Core/Threading Threading improvements],
    23  * supports destroying sessions (no dangling data nor session ID should remain),
    24  * supports controlling session lifetime (comment:ticket:2548:9 describes the use case),
    25  * has a well-defined relationship to request.user.
    26 
    27 === Session and user relationship ===
    28 
    29 I haven't checked the code, but as far as I know, the user is stored in session. This is of course entirely reasonable, but the relationship should be documented to avoid overwriting the user key in session. The general session should remain to be tied to browser (re: ''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''), there should perhaps be a user-specific data bucket to store additional user-specific attributes if required that will represent a 'user session' -- something in the lines of `extra_attributes` dict in the user class. That would allow destroying the data bucket when user logs out, but retain the browser session -- this is the main problem of #6941, where coupling is needed but missing.
     15The following is required from the session framework:
     16 * no session key collisions on creation (#1180)
     17 * there is a method for clearing session data (#7515)
     18 * session data is not shared between different users (#6941), session is cleared on logout; if a different user was logged during login, his data will be cleared on login as well (but not anonymous session data) -- depends on previous
     19 * supports controlling session lifetime (comment:ticket:2548:9 describes the use case)
Back to Top