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
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 timeouts and making more use of
>> permissions. H
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 account and still nee
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 a
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
> login_required, as it i
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 de
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 until after the release
>> candidate? It looks t
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 login_required check --
> as
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 few staff are let go or othe
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 anytime.
> Let me know you
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
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 vi
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'
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, permiss
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 sub
15 matches
Mail list logo