Well, we - and I imagine many others - are actively using this behavior. So our use-case is simple: a user registers, the user remains inactive until they click on a link in their mailbox. That is the behavior is "defined" by django-registration.
-- Gert Mobile: +32 498725202 Twitter: @gvangool Web: http://gertvangool.be On Fri, Sep 9, 2011 at 07:24, subs...@gmail.com <subs...@gmail.com> wrote: > Could anyone provide a use case where I want a de-activated user to > remain authenticated? Who is this option for? Why is it default? > > When I originally reported this ticket I did so because this is a > plain security risk--non-technical users uncheck 'is active' when they > want to lock someone out of access. They don't realize that the > session remains active and I believe this to be an oversight within > the original design, not a design preference. > > On Sep 8, 2:11 am, Vladimir Kryachko <v.kryac...@gmail.com> wrote: >> I think it has been done on purpose, and should not be changed. >> Because different authentication backends may choose to support >> inactive users or not. And the default (ModelBackend) supports >> inactive users which is expressed in >> ModelBackend.supports_inactive_user = True. So I would suggest you >> write a custom decorator. >> >> >> >> >> >> >> >> On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen <wimfei...@gmail.com> wrote: >> > I'd like to draw attention to an open ticket which needs a design >> > decision. >> >> > Description: >> > "The login_required decorator is not checking User.is_active, as >> > staff_member_required does. If an authenticated user is deactivated >> > (via setting is_active to False), the user is still able to browse >> > login_required-protected views." >> >> > For probably most people, the expected and (most likely) wanted >> > behavior would be not to let inactive users have access to >> > login_required files. >> >> > Wim >> >> > -- >> > 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 >> > athttp://groups.google.com/group/django-developers?hl=en. > > -- > 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. > > -- 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.
