interesting. i'm using the django-provided login form from 1.1, waiting for 1.2 to be released before using it.
here's an example of my point: you run an internal tool for staff to discuss the topics of the day. a few staff are let go or otherwise deemed ineligible, and their access is revoked. so, you deactivate their accounts in the lovely django admin, but then find that they are still using the site. now, deactivating them doesn't log them out, and that's to be expected since contrib.sessions is wisely decoupled from contrib.auth. but, you thought you'd protected your views with "login_required", but it turns out "login_required" only makes sure that the user is currently logged in, riding on the assumption that their status would not change in the duration of their session. to me, it seems like an oversight. definitely interested in others' opinions. On Mar 16, 5:25 pm, Gabriel Hurley <gab...@gmail.com> wrote: > I linked to the 1.1 docs there, but the 1.2 docs add: > > "However, the AuthenticationForm used by the login() view does perform > this check, as do the permission-checking methods such as has_perm() > and the authentication in the Django admin." > > So in this instance, if using the built-in django login view is your > only method of logging in to your site you would be safe. I'll admit > the whole business of not checking is_active seems a little odd to me, > but I also haven't looked to see what discussion there was around the > original decision. I'd hope it would make more sense if I did look > back in the archives. > > I'm no expert on this one. Just thought I'd point out the fact that > the docs do discuss the subject of that bug ticket. > > - Gabriel > > On Mar 16, 3:12 pm, mattd <mattdennew...@gmail.com> wrote: > > > > > if it's a design decision, it's a silly one imo. why should i have to > > work around django's ever-so-convenient "login_required" decorator to > > prevent a deactivated user from viewing a page they're no longer > > allowed to view? a deactivated user *shouldn't even be allowed to be > > be logged in*, but there's no way (that i know of) the purge the > > session data for a given user on deactivation, and i can't just email > > them to politely ask them to log out. > > > On Mar 16, 4:48 pm, Gabriel Hurley <gab...@gmail.com> wrote: > > > > The docs have this to say about is_active: > > > > "This doesn’t control whether or not the user can log in. Nothing in > > > the authentication path checks the is_active flag, so if you want to > > > reject a login based on is_active being False, it is up to you to > > > check that in your own login view. However, permission checking using > > > the methods like has_perm() does check this flag and will always > > > return False for inactive users." > > > >http://docs.djangoproject.com/en/1.1/topics/auth/#django.contrib.auth... > > > > So, if we're to believe the docs, this isn't a bug but a design > > > decision. > > > > All the best, > > > > - Gabriel > > > > On Mar 16, 1:53 pm, Sean Brant <brant.s...@gmail.com> wrote: > > > > > A co-worker of mine noticed this bug > > > > todayhttp://code.djangoproject.com/ticket/13125. > > > > Should it be marked for 1.2 or punt it until after the release > > > > candidate? It looks to be a bug so it could probably go in at anytime. > > > > Let me know your thoughts. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
