Access Control Lists
How permissions work
On top of that we use the access.models.GroupUser
and Group
to define
what access groups a user is a part of, and each group has rules
defining
which permissions they grant their members, separated by ,
.
Permissions that you can use as filters can be either explicit or general.
For example Admin:EditAddons
means only someone with that permission will
validate.
If you simply require that a user has some permission in the Admin group
you can use Admin:%
. The %
means “any.”
Similarly a user might be in a group that has explicit or general permissions.
They may have Admin:EditAddons
which means they can see things with that
same permission, or things that require Admin:%
.
If a user has a wildcard, they will have more permissions. For example,
Admin:*
means they have permission to see anything that begins with
Admin:
.
The notion of a superuser has a permission of *:*
and therefore they can
see everything.
Django Admin
Django admin relies on 2 things to gate access:
- To access the admin itself, UserProfile.is_staff
needs to be True
. Our custom implementation allows access to users with a @mozilla.com
email.
- To access individual modules/apps, UserProfile.has_perm(perm, obj)
and UserProfile.has_module_perms(app_label)
need to return True
. Our custom implementation uses the Group
of the current user as above, with a mapping constant called DJANGO_PERMISSIONS_MAPPING
which translates Django-style permissions into our own.