Yeah, this debate is borderline silly now. OP, in a nut shell;
1) It is completely acceptable to revoke all other sessions after a password change 2) There are many ways to revoke sessions, pick one that is right for your use case. 3) Whether session revoking is enforced or optional is a choice for you. Hope this helps! Cal On Wed, Oct 3, 2012 at 9:40 AM, Tom Evans <tevans...@googlemail.com> wrote: > On Tue, Oct 2, 2012 at 7:50 PM, Cal Leeming [Simplicity Media Ltd] > <cal.leem...@simplicitymedialtd.co.uk> wrote: > > On Tue, Oct 2, 2012 at 5:23 PM, Tom Evans <tevans...@googlemail.com> > wrote: > >> I did not say that it was not a desired feature, I said that > >> *personally* I would not have that expectation; this may be due to me > >> fully understanding how such systems work and, as I indicated, a lay > >> person may think differently. > > > > > > That sure is a loaded comment, let's keep the dick size wars out of this > > yeah? :) > > > > It's not a loaded comment at all, this isn't a "dick size war". > > >> > >> Other large commercial systems, for > >> instance google apps, do not behave in this manner, so I'm not sure > >> where the expectation comes from - can anyone name a public facing > >> system that invalidates all other sessions on password change? > > > > > > Let's see.. Facebook? > > > > --snip-- > > "Log out of other devices? To make sure your account's secure, we can log > > you out of any other computers and phones. You can log back in with your > new > > password." > > --snip > > > > The only difference is that Facebook make it an optional feature that > pops > > up immediately after you change the password. > > So not what your proposed solution allows, but instead session tracking... > > > > > The expectation comes from a simple logic. If I change my password, I > want > > to think that my account is secure from anyone else that previously had > it. > > > >> > >> As a corollary, remember that django's authentication contrib package, > >> django.contrib.auth, is designed to be a *base* that all AAA schemes > >> can be built around. There are many schemes where a user may have many > >> passwords for a single account, should changing one of them invalidate > >> all their other sessions? > > > > > > That's a different question entirely, and comes down to a business logic > > choice, not a technical "one-fits-all". > > This is point 1. > > > > >> > >> > >> As I said in my original reply, these sorts of BI rules can trivially > >> be added on top of d.c.auth. I gave one such mechanism, Cal another. > >> Cal's solution is more about ensuring that only sessions that have the > >> current valid password hash are allowed, whilst mine is more about > >> tracking and invalidating specific sessions on a whim. > > > > > > The solution I specified was the most simple approach possible, and > could be > > integrated without too much fuss. > > See point 1. Your solution is the most simplistic approach to solve > this explicit use case, but implementing it in base would mean ruling > out many AAA schemes. Thanks for making my argument for me. > > > Tom > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
