Re: logialogin_required does not check User.is_active

Could the burden of this work be successfully (and sensibly) shifted to the backend itself by calling something like... deactivate()? In this event, the default backend's logic could be 'set is_active = False and expire cookie' and custom backends could do (or not do) whatever they want. Forgive

Re: logialogin_required does not check User.is_active

On Thu, Apr 15, 2010 at 11:20 PM, subs...@gmail.com wrote: > Thanks for breaking it down. > > On Mar 17, 7:45 am, Russell Keith-Magee > wrote: > >>  1) Don't touch the code. It's an annoying edge case, but it can be >> caught by shortening session

Re: logialogin_required does not check User.is_active

On Thu, Apr 15, 2010 at 9:50 AM, Harro wrote: > I think the problem isn't the login_required, but it simply does what > it says it does: Check if the user is logged in. > > For me a user with is_active set to false shouldn't be allowed to > login, they either just created an

Re: logialogin_required does not check User.is_active

I think the problem isn't the login_required, but it simply does what it says it does: Check if the user is logged in. For me a user with is_active set to false shouldn't be allowed to login, they either just created an account and still need to verify it or they indicated that they wanted their

Re: logialogin_required does not check User.is_active

Thanks for breaking it down. On Mar 17, 7:45 am, Russell Keith-Magee wrote: >  1) Don't touch the code. It's an annoying edge case, but it can be > caught by shortening session timeouts and making more use of > permissions. However, we should document the edge case with

Re: logialogin_required does not check User.is_active

i need to think more about russell's points before responding in full, but i did want to briefly mention the following: 1. simply shortening the length of sessions doesn't prevent a user with revoked access from seeing new and potentially sensitive data created after the user's deactivation. if

Re: logialogin_required does not check User.is_active

On Wed, Mar 17, 2010 at 3:46 PM, Russell Keith-Magee wrote: > On Wed, Mar 17, 2010 at 4:53 AM, Sean Brant wrote: >> A co-worker of mine noticed this bug today >> http://code.djangoproject.com/ticket/13125. >> Should it be marked for 1.2 or punt it

Re: logialogin_required does not check User.is_active

On Wed, Mar 17, 2010 at 8:54 AM, Russell Keith-Magee wrote: > > In the interim, there are two other ways you could limit your exposure > to this problem (other than the obvious "write your own > login_required" check): > >  * Use a permissions check in addition to the

Re: logialogin_required does not check User.is_active

On Wed, Mar 17, 2010 at 6:30 AM, mattd wrote: > 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

Re: logialogin_required does not check User.is_active

On Wed, Mar 17, 2010 at 4:53 AM, Sean Brant wrote: > A co-worker of mine noticed this bug today > http://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

Re: logialogin_required does not check User.is_active

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.

Re: logialogin_required does not check User.is_active

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

Re: logialogin_required does not check User.is_active

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

Re: logialogin_required does not check User.is_active

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,

logialogin_required does not check User.is_active

A co-worker of mine noticed this bug today http://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