Login page is redisplayed without any message if AdminSite.has_permission() returns False

[Michel Sabchuk]

I found a bug when using the has_permission method of the AdminSite class to filter which users can access the admin page:

class SuperuserAdminSite(admin.AdminSite):
    def has_permission(self, request):
        return super(SuperuserAdminSite, self).has_permission(request) and request.user.is_superuser
admin_site = SuperuserAdminSite()

When I try to log on a user that is not a superuser, it already get the login but stay on the login page (with the header but no application loaded), I think this is a bug :) The user should get a error message as if it passed a wrong password or such, isn´t it?

[Marc Fargas]

I assume this has to do with newforms-admin branch?
The ticket is 5 months old, could you please check if it's still valid?

[Karen Tracey <kmtracey@…>]

I think I see the problem. If you try to create a SuperuserAdminSite that only superusers are allowed to login to, as shown by the supplied code, then when you navigate to that site and present login information for a staff (but not superuser) user and press the "Log In" button, the login page is redisplayed without any error messages, plus the user-tools links div overlays the login form (I'll attach an image).

Problem is the base AdminSite during login assumes that any user that is_staff can access the admin site. I've created a patch that fixes this. Logic is a little more convoluted than I'd like because the has_permission method takes a request object and the user logging in is only associated with the request object after login() is called, so in the case where the user is a staff member but doesn't pass the site's has_permission test you have to call login to get the user attached to the request, then has_permission to check for permissions, then logout to detach the insufficiently qualified user from the request and replace them with the AnonymousUser again.

Accepting based on the assumption that this is something one should be able to do in newforms-admin? Feel free to correct me if I'm wrong on that though. Tagging nfa-someday since I don't see it as super high-priority.

[Karen Tracey <kmtracey@…>]

Fixed patch -- like I said this logic is more convoluted than I like

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[David Gouldin]

Just verified that this does still happen on current trunk, though the patch is of course very outdated at this point.

[David Gouldin]

It looks like the 2 problem spots now are:

​https://github.com/django/django/blob/master/django/contrib/admin/views/decorators.py#L14

and

​https://github.com/django/django/blob/master/django/contrib/admin/forms.py#L41

Both of these should be modified to use AdminSite.has_permission. *How* that's to be done, I don't yet have any idea. ;-)

[Tim Graham]

Found a patch, looks like it needs tests:

​https://github.com/django/django/pull/925

[tanner]

I cannot reproduce this bug with master. can be closed IMO

[Claude Paroz]

The visual quirk about user tools is gone. But there is still a small difference in that the authentication simply refuse the login and redisplay the login form without any explanation (like it would have given if user is not staff or password is wrong).

Tentative resolution:

django/contrib/admin/forms.py

@@ -17 +17 @@
     required_css_class = 'required'
 
     def confirm_login_allowed(self, user):
-        if not user.is_active or not user.is_staff:
+        if not self.request.admin_site.has_permission(self.request):
             raise forms.ValidationError(
                 self.error_messages['invalid_login'],
                 code='invalid_login',

django/contrib/admin/sites.py

@@ -392 +392 @@
             'authentication_form': self.login_form or AdminAuthenticationForm,
             'template_name': self.login_template or 'admin/login.html',
         }
+        request.admin_site = self
         return login(request, **defaults)
 
     @never_cache

[Iacopo Spalletti]

@claudep proposed solution almost works, but request in confirm_login_allowed still does not carry the actual user, but the pre-login one (which is likely AnonymousUser).
A solution would be setting the user on request before passing to AdminSite.has_permission (eventually resetting it to the original after that).
Does it sound good?

django/contrib/admin/forms.py

@@ -17 +17 @@
     required_css_class = 'required'
 
     def confirm_login_allowed(self, user):
-        if not user.is_active or not user.is_staff:
+        self.request.user = user
+        if not self.request.admin_site.has_permission(self.request):
             raise forms.ValidationError(
                 self.error_messages['invalid_login'],
                 code='invalid_login',

rebasing @czpython PR it's also an option (and way cleaner as it will display a proper message)

[Tim Graham]

This may be addressed by #25163 which added this message to the login page if AdminSite.has_permission() returns False:

You are authenticated as <username>, but are not authorized to access this page. Would you like to login to a different account?

I haven't checked if the previously proposed patches might be a further improvement.