{{{
@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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25075>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Why?
--
Ticket URL: <https://code.djangoproject.com/ticket/25075#comment:1>
Comment (by djbaldey):
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), it 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25075#comment:2>
* status: new => closed
* resolution: => invalid
Comment:
The `login_required()` decorator is documented as
[https://docs.djangoproject.com/en/stable/topics/auth/default/#the-login-
required-decorator 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25075#comment:3>
* status: closed => new
* resolution: invalid =>
* type: Uncategorized => Bug
* needs_docs: 0 => 1
Comment:
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: ad...@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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25075#comment:4>
Comment (by timgraham):
The admin uses the
[https://docs.djangoproject.com/en/dev/ref/contrib/admin/#the-staff-
member-required-decorator` 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25075#comment:5>
* status: new => closed
* resolution: => invalid
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25075#comment:6>