Change is_authenticated() that depended on is_active

[Grigoriy Kramarenko]

I propose to change the following:

@python_2_unicode_compatible
class AbstractBaseUser(models.Model):
    ...

    is_active = True

    ...

    def is_authenticated(self):
        """
        Always return True if user is active. This is a way to tell if the user has been
        authenticated in templates. Also this used in `login_required` decorator.
        """
        return self.is_active

[Tim Graham]

Why?

[Grigoriy Kramarenko]

This has always been so in earlier versions. If the user is working with the site, then he has session_key. In that moment, when switched off it administrator (is_active=False), user will continue to have access to views under the decorator login_required until continues the action session_key.
I'm not sure that this behavior will not resume in new versions or in a custom User model or in different from default session backends.

If I'm wrong, let's close the ticket.

[Tim Graham]

The login_required() decorator is documented as ​not checking the is_active flag. If you can provide more information about how the behavior changed in recent versions of Django, please reopen with those details.

[Grigoriy Kramarenko]

In the documentation I have seen only vague: "If the user is logged in, execute the view normally. The view code is free to assume the user is logged in."

The documentation should be written clearly, that: "Note, if the administrator has turned off the user by using "is_active", the user will have access to all the views that are under the control of the decorator until the action of the session key."
Now it is not mentioned in the documentation.

I'll show an example (stable 1.8.3):

$ mkdir test
$ django-admin startproject project test
$ cd test/project/
$ ../manage.py migrate 
Operations to perform:
  Synchronize unmigrated apps: staticfiles, messages
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying sessions.0001_initial... OK

$ ../manage.py createsuperuser
Username (leave blank to use 'djbaldey'): admin
Email address: admin@example.org
Password: 
Password (again): 
Superuser created successfully.

$ nano views.py

Listing views.py:

from django.contrib.auth.decorators import login_required
from django.http import HttpResponse

@login_required
def test_access(request):
    return HttpResponse('access')

$ nano urls.py

Listing urls.py:

from django.conf.urls import include, url
from django.contrib import admin
from .views import test_access

urlpatterns = [
    url(r'^admin/', include(admin.site.urls)),
    url(r'^test/', test_access),
]

$ ../manage.py runserver

Open browser on ​http://localhost:8000/admin/ and sign.
And open ​http://localhost:8000/test/ in new tab after.
Disable user in the admin panel. You will be thrown out from page.
But, on page /test/ you will continue to have access to.

While in the documentation is not written this sudden behavior, we can assume this is a bug.

[Tim Graham]

The admin uses the ​staff_member_required decorator which does require is_active=True. I don't think changing the behavior of either decorator is an option, but I'll be happy to review a documentation patch if you could provide one.

[Shai Berger]

The linked documentation has a note that says is_active is not checked, at the bottom of the decorator's description. This has been the case for quite some time.