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.
