#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 <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.efe8fe65db9152069c79c6920fc5882c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to