[Django] #28021: Add active_login_required decorator

9 views
Skip to first unread message

Django

unread,
Apr 5, 2017, 3:08:11 AM4/5/17
to django-...@googlegroups.com
#28021: Add active_login_required decorator
----------------------------------------+------------------------
Reporter: Wim Feijen | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
----------------------------------------+------------------------
Hi,

Documentation recommends setting a user's is_active flag to False in stead
of deleting a user:

https://docs.djangoproject.com/en/1.10/ref/contrib/auth/#django.contrib.auth.models.User.is_active
"Boolean. Designates whether this user account should be considered
active. We recommend that you set this flag to False instead of deleting
accounts; that way, if your applications have any foreign keys to users,
the foreign keys won’t break."

However, the recommended login_required decorator does not check whether
is_active is True or False, meaning inactive users may still access that
view.

To maintain backwards compatibility, it was decided not to change the
behaviour of login_required, see:
https://code.djangoproject.com/ticket/13125
"is_active is a hook for custom auth sources and custom auth logic; the
built-in stuff doesn't check it. Yes it's a bit counter-intuitive, but
changing it is going to break a number of expectations in users' code, so
it's going to need to stay as is."

As a solution, I'd like to add an active_login_required decorator, which
does check for is_active = True. That way we maintain backwards
compatibility and in addition we can have a decorator that behaves
intuively.

--
Ticket URL: <https://code.djangoproject.com/ticket/28021>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Apr 5, 2017, 8:42:39 AM4/5/17
to django-...@googlegroups.com
#28021: Add active_login_required decorator
------------------------------+--------------------------------------

Reporter: Wim Feijen | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: 1.10
Severity: Normal | Resolution:

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Changes (by Tim Graham):

* easy: 1 => 0


Old description:

> Hi,
>
> Documentation recommends setting a user's is_active flag to False in
> stead of deleting a user:
>
> https://docs.djangoproject.com/en/1.10/ref/contrib/auth/#django.contrib.auth.models.User.is_active
> "Boolean. Designates whether this user account should be considered
> active. We recommend that you set this flag to False instead of deleting
> accounts; that way, if your applications have any foreign keys to users,
> the foreign keys won’t break."
>
> However, the recommended login_required decorator does not check whether
> is_active is True or False, meaning inactive users may still access that
> view.
>
> To maintain backwards compatibility, it was decided not to change the
> behaviour of login_required, see:
> https://code.djangoproject.com/ticket/13125
> "is_active is a hook for custom auth sources and custom auth logic; the
> built-in stuff doesn't check it. Yes it's a bit counter-intuitive, but
> changing it is going to break a number of expectations in users' code, so
> it's going to need to stay as is."
>
> As a solution, I'd like to add an active_login_required decorator, which
> does check for is_active = True. That way we maintain backwards
> compatibility and in addition we can have a decorator that behaves
> intuively.

New description:

Hi,

Documentation recommends setting a user's is_active flag to False in stead
of deleting a user:

https://docs.djangoproject.com/en/1.10/ref/contrib/auth/#django.contrib.auth.models.User.is_active
"Boolean. Designates whether this user account should be considered
active. We recommend that you set this flag to False instead of deleting
accounts; that way, if your applications have any foreign keys to users,
the foreign keys won’t break."

However, the recommended login_required decorator does not check whether
is_active is True or False, meaning inactive users may still access that
view.

To maintain backwards compatibility, it was decided not to change the
behaviour of login_required, see:
https://code.djangoproject.com/ticket/13125
"is_active is a hook for custom auth sources and custom auth logic; the
built-in stuff doesn't check it. Yes it's a bit counter-intuitive, but
changing it is going to break a number of expectations in users' code, so
it's going to need to stay as is."

As a solution, I'd like to add an active_login_required decorator, which
does check for is_active = True. That way we maintain backwards
compatibility and in addition we can have a decorator that behaves

intuitively.

--

Comment:

I'm not sure if this has much value considering that `ModelBackend` and
`RemoteUserBackend` reject inactive users (as of Django 1.10, see #25232).
Would this decorator change behavior in any way?

--
Ticket URL: <https://code.djangoproject.com/ticket/28021#comment:1>

Django

unread,
Apr 11, 2017, 1:02:27 PM4/11/17
to django-...@googlegroups.com
#28021: Add active_login_required decorator
------------------------------+--------------------------------------
Reporter: Wim Feijen | Owner: nobody
Type: New feature | Status: closed
Component: contrib.auth | Version: 1.10
Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Changes (by Tim Graham):

* status: new => closed
* resolution: => wontfix


--
Ticket URL: <https://code.djangoproject.com/ticket/28021#comment:2>

Reply all
Reply to author
Forward
0 new messages