Well, as far as I see it, we have a number of options. These are some I could come up with, but maybe someone else has a better idea:
1) Save the user_id with the session. This is probably not convenient, because it might conflict with other applications that use the session package. Of course we could give the user_id a default of null, but that seems a bit sloppy to me. Upside is that we could invalidate sessions on password change. 2) Build a relation table that links the sessions to the users. (Or use a CSV in the user object.) This could be done completely in the auth package. Downside is that we have to create a new table. Upside is again, that we could invalidate sessions on password change. 3) Save the password hash (or part of it) in the session and compare it against our data. If the hash is not the same, the user needs to be logged out. This wouldn't change the database, but the downside is that this causes overhead on every request. 4) Save the last_password_change_date on the user object and save the session_creation_time inside the session. Compare these and we know if we should log the user out. This is just a different approach to 3. My favourite is option 2 for now. It seems the most resource friendly, even though we need to save more data. I don't know what Django's policy on adding tables is though. Besides that, I have to admit that I am fairly new to Django. I have build some small sites with it, but have only skimmed through some parts of the source code so far. I am not completely familiar with the inner workings of the framework. Arnoud -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
