Re: [Django] #28021: Add active_login_required decorator

2017-04-11 Thread Django 
#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: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.dc5fa97b60d92d0ec1fa588b12984e5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28021: Add active_login_required decorator

2017-04-05 Thread Django 
#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: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
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.

[Django] #28021: Add active_login_required decorator

2017-04-05 Thread Django 
#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: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.a7c26c524e38eb47d005ff1a9c13d087%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.