23 | | * 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 attributes if required that will represent a 'user session' -- something in the lines of `extra_attributes` dict in the user class. |
| 23 | * has a well-defined relationship to request.user. |
| 24 | |
| 25 | === Session and user relationship === |
| 26 | |
| 27 | 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. |