#25075: Change is_authenticated() that depended on is_active
------------------------------+--------------------------------------
     Reporter:  djbaldey      |                    Owner:  nobody
         Type:  Bug           |                   Status:  new
    Component:  contrib.auth  |                  Version:  1.8
     Severity:  Normal        |               Resolution:
     Keywords:                |             Triage Stage:  Unreviewed
    Has patch:  0             |      Needs documentation:  1
  Needs tests:  0             |  Patch needs improvement:  0
Easy pickings:  1             |                    UI/UX:  0
------------------------------+--------------------------------------
Changes (by djbaldey):

 * 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>
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 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/066.344e88f77cc5b1b337aa2395ff6db4e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to