How to make Django admin site accessed by non-staff user?

11
votes

I would like to implement a 2nd admin site which provides a subset of feature of the primary admin site. That's possible and described in the Django docs

However, I would like to limit access on the primary admin site. Some users can access the 2ndary site but not the primary site.

In order to implement that feature, I would like these users not to be in the staff (is_staff=False) and rewrite the AdminSite.has_permission

class SecondaryAdminSite(AdminSite):
    
    def has_permission(self, request):
        if request.user.is_anonymous:
            try:
                username = request.POST['username']
                password = request.POST['password']
            except KeyError:
                return False
            try:
                user = User.objects.get(username = username)
                if user.check_password(password):
                    return user.has_perm('app.change_onlythistable')
                else:
                    return False
            except User.DoesNotExist:
                return False
        else:
            return request.user.has_perm('app.change_onlythistable')

Unfortunately, this approach doesn't work. The user can login but can't see anything in the secondary admin site.

What's wrong with this approach? Any idea how to implement this feature?

Thanks in advance

3
pythondjangodjango-admindjango-authentication
Why don't you just partition your users into superusers, managers, customers etc - permission system works perfectly. - Tomasz Zieliński
@Tomasz: I am doing that too. The 2ndary admin site has a different purpose so address different type of users. I would like to avoid that they connect to the usual admin. - luc
I assume you're verifying that the correct has_permission is being called? Does nothing whatsoever show up on the page (i.e. it is completely blank), or is it simply hiding the admin functions? - Jordan Reiter
it says that I have no rights on this app. If I restore the is_staff on the logged user, they I can see the models. - luc
is_staff is required by the admin. If you have some reason why these users can't have that set to true, I think your best option is to write your own admin views. With access controls like the has_permission decorator you can enforce your own authorization scheme. - Paul Bissex

3 Answers

4
votes

I think that your approach should now be possible: http://code.djangoproject.com/ticket/14434 (closed 5 weeks ago)

However, the explicit "is_staff" check is still done in two places (apart from the staff_member_required decorator):

  • django.contrib.admin.forms.AdminAuthenticationForm.clean()

    On top of "has_permission()" you'd need to provide your non-staff AdminSite with a "login_form" that doesn't do the is_staff check, so could just subclass and adjust clean() accordingly.

  • templates/admin/base.html

    would need to be slightly customized. The div with id "user-tools" is only shown for active staff members. I'm assuming that's done because the login form also uses this template, and someone could be logged in as an active non-staff member but still should'nt see those links.

3
votes

Here's what worked for me with Django >= 3.2.

  • Create a subclass of AdminSite
  • Override the has_permission() method to remove the is_staff check.
  • Override the login_form to use AuthenticationForm.
    • AdminSite uses AdminAuthenticationForm, which extends AuthenticationForm and adds a check for is_staff.

Code

# PROJECT/APP/admin.py

from django.contrib.admin import AdminSite
from django.contrib.admin.forms import AuthenticationForm


class MyAdminSite(AdminSite):
    """
    App-specific admin site implementation
    """

    login_form = AuthenticationForm

    site_header = 'Todomon'

    def has_permission(self, request):
        """
        Checks if the current user has access.
        """
        return request.user.is_active


site = MyAdminSite(name='myadmin')
-1
votes

What's wrong with this approach? Any idea how to implement this feature?

What's wrong with this approach is that permissions and groups can already provide you with what you need. There is no need to subclass AdminSite if all you need is to divide users.

This is probably why this feature is so poorly documented, IMHO