| | 1 | = Session framework improvements = |
| | 2 | |
| | 3 | The following tickets call for improvements in session logic: #5549:comment:5, #2548, #3304, #1180, #6791, #6941. |
| | 4 | Some of the tickets are interrelated, some of them pose security risks. |
| | 5 | 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). |
| | 6 | Also, the relationship between `request.user` and sessions should be clearly defined to avoid overwriting the user key in session. |
| | 7 | |
| | 8 | See also the discussion at http://groups.google.com/group/django-developers/browse_thread/thread/fbcfa88c997d1bb3 . |
| | 9 | |
| | 10 | Other projects to draw inspiration from: [http://beaker.groovie.org Beaker]. |
| | 11 | |
| | 12 | A coherent solution should be provided to all these issues by refactoring `django.contrib.session`. |
| | 13 | |
| | 14 | == Proposal == |
| | 15 | |
| | 16 | `django.contrib.session` should be a secure session framework that |
| | 17 | * will not be re-used under any circumstances (#6941), is protected against key collisions (#1180) and session hijacking (#6941), |
| | 18 | * supports concurrency by using locking throughout (as Beaker does, think mod_wsgi with threads and AJAX), |
| | 19 | * supports destroying sessions (no dangling data nor session ID should remain), |
| | 20 | * supports controlling session lifetime (#2548:comment:8 describes the use case), |
| | 21 | * has a well-defined relationship to request.user. 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 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 data if required that will represent a 'user session' -- something in the lines of `extra_attributes` dict. |