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.