Here's an idea that might work better than a decorator:
Create a setting called ALLOW_DEACTIVATED_LOGINS. Then modify auth.login()
to enforce this as well as changing ModelBackend.get_user() to logout users
whose accounts are disabled. Make the setting True by default in 1.4 and
announce it'll b
Probably yeah, on the other hand the docs tell you that is_active doesn't
neccessarily have to be checked by backends, so if a backend allows to login
inactive users it makes no sense to check that flag in login_required… I
guess what I am proposing is that the login_required flag checks via the
Hi Florian,
Then again, the default behaviour now is as you describe. That's why I
would call it a security leak.
Unfortunately, it is not only my system, it is the system of any
unaware Django programmer.
Wim
On Sep 11, 10:24 pm, Florian Apolloner wrote:
> On Sunday, September 11, 2011 8:52:0
On Sunday, September 11, 2011 8:52:03 PM UTC+2, Wim Feijen wrote:
>
> 3. Because the user is still logged in, (maybe for two weeks, or for
> whatever expiration time the developer has set)
>
Imo in that case the developer should write a middleware that logs the user
out on the next request. I
Paul,
On further thinking, I do believe that the current behaviour of
login_required should be considered a bug.
Wim
On 10 sep, 02:03, Paul McMillan wrote:
> No. Django makes an incredibly strong promise about backwards
> compatibility to its users. Security releases are the ONLY reason we
> mo
The case is as follows:
1. An active user is logged in and has a valid session.
2. The user is inactivated by a system admin, who wants to disable the
user.
3. Because the user is still logged in, (maybe for two weeks, or for
whatever expiration time the developer has set), he passes the
login_req
Stupid question, but why do you let inactive users login at all? I mean is
this really a problem of the decorator and not of the login system you use?!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visi
I added an active_login_required decorator. See:
https://code.djangoproject.com/ticket/16797
Is it a good name? It is a good patch? Or is it stupid?
Thanks, Wim
On 10 sep, 02:27, Wim Feijen wrote:
> Thanks Paul,
>
> I like the idea of the additional decorator! Let's do that.
>
> Wim
>
> On 10
Thanks Paul,
I like the idea of the additional decorator! Let's do that.
Wim
On 10 sep, 02:03, Paul McMillan wrote:
> > I'd like to make a case to re-open ticket 13125.
>
> Thanks for taking this to the mailing list rather than arguing in trac.
>
> > I understand that changing the current behav
> I'd like to make a case to re-open ticket 13125.
Thanks for taking this to the mailing list rather than arguing in trac.
> I understand that changing the current behaviour is backwards-
> incompatible and therefor very unwanted. But, I'd say the current
> implementation is forward-incompatible:
> There are numerous counter arguments to the idea: Unintended
> consequences. There is a possibility for race conditions, which would
> then be security issues. Action at distance. I don't know if this is
> possible to implement for all session backends.
It's impossible to implement for cookie-ba
One approach would be to invalidate the sessions of the user when
is_active is changed from True to False. This way the current
registration method would work, and there would not be surprising "can
use site as long as session is open" situations, because there would
not be any open sessions.
Ther
Jakob, thanks for looking into 13125 and taking action on it.
I'd like to make a case to re-open ticket 13125.
I understand that changing the current behaviour is backwards-
incompatible and therefor very unwanted. But, I'd say the current
implementation is forward-incompatible: meaning that curr
13 matches
Mail list logo
