Reputation: 7235
I'd like to use a permissions based system to restrict certain actions within my Django application. These actions need not be related to a particular model (e.g. access to sections in the application, searching...), so I can't use the stock permissions framework directly, because the Permission
model requires a reference to an installed content type.
I could write my own permission model but then I'd have to rewrite all the goodies included with the Django permissions, such as:
permission_required
decorator.User.has_perm
and related user methods.perms
template variable.I've checked some apps like django-authority and django-guardian, but they seem to provide permissions even more coupled to the model system, by allowing per-object permissions.
Is there a way to reuse this framework without having defined any model (besides User
and Group
) for the project?
Upvotes: 117
Views: 40089
Reputation: 2806
For those of you, who are still searching:
You can create an auxiliary model with no database table. That model can bring to your project any permission you need. There is no need to deal with ContentType or create Permission objects explicitly.
from django.db import models
class RightsSupport(models.Model):
class Meta:
managed = False # No database table creation or deletion \
# operations will be performed for this model.
default_permissions = () # disable "add", "change", "delete"
# and "view" default permissions
permissions = (
('customer_rights', 'Global customer rights'),
('vendor_rights', 'Global vendor rights'),
('any_rights', 'Global any rights'),
)
Right after manage.py makemigrations
and manage.py migrate
you can use these permissions like any other.
# Decorator
@permission_required('app.customer_rights')
def my_search_view(request):
…
# Inside a view
def my_search_view(request):
request.user.has_perm('app.customer_rights')
# In a template
# The currently logged-in user’s permissions are stored in the template variable {{ perms }}
{% if perms.app.customer_rights %}
<p>You can do any customer stuff</p>
{% endif %}
EDIT: in case you are using a DB router, make sure to return True
from allow_migrate
for this model.
Upvotes: 243
Reputation: 356
Fix for Chewie's answer in Django 1.8, which as been requested in a few comments.
It says in the release notes:
The name field of django.contrib.contenttypes.models.ContentType has been removed by a migration and replaced by a property. That means it’s not possible to query or filter a ContentType by this field any longer.
So it's the 'name' in reference in ContentType that the uses not in GlobalPermissions.
When I fix it I get the following:
from django.db import models
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType
class GlobalPermissionManager(models.Manager):
def get_queryset(self):
return super(GlobalPermissionManager, self).\
get_queryset().filter(content_type__model='global_permission')
class GlobalPermission(Permission):
"""A global permission, not attached to a model"""
objects = GlobalPermissionManager()
class Meta:
proxy = True
verbose_name = "global_permission"
def save(self, *args, **kwargs):
ct, created = ContentType.objects.get_or_create(
model=self._meta.verbose_name, app_label=self._meta.app_label,
)
self.content_type = ct
super(GlobalPermission, self).save(*args)
The GlobalPermissionManager class is unchanged but included for completeness.
If using Django admin to create/edit these permissions, think of removing the content_type field to avoid confusion:
class GlobalPermissionAdmin(admin.ModelAdmin):
list_display = ("name", "codename")
exclude = ("content_type",)
admin.site.register(GlobalPermission, GlobalPermissionAdmin)
Upvotes: 11
Reputation: 7235
Following Gonzalo's advice, I used a proxy model and a custom manager to handle my "modelless" permissions with a dummy content type.
from django.db import models
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType
class GlobalPermissionManager(models.Manager):
def get_queryset(self):
return super(GlobalPermissionManager, self).\
get_query_set().filter(content_type__name='global_permission')
class GlobalPermission(Permission):
"""A global permission, not attached to a model"""
objects = GlobalPermissionManager()
class Meta:
proxy = True
def save(self, *args, **kwargs):
ct, created = ContentType.objects.get_or_create(
name="global_permission", app_label=self._meta.app_label
)
self.content_type = ct
super(GlobalPermission, self).save(*args, **kwargs)
Upvotes: 56
Reputation: 1
I think that User
model substitution do the trick (see Django documentation: https://docs.djangoproject.com/en/4.1/topics/auth/customizing/#substituting-a-custom-user-model)
Next on that model we can add Meta
class with permissions and at the end we need to add our User
model in settings.py
.
Here is my example of user.py
file:
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
class Meta:
default_permissions = [] # disable "add", "change", "delete"
# and "view" default permissions
permissions = [
('customer_rights', 'Global customer rights'),
('vendor_rights', 'Global vendor rights'),
('any_rights', 'Global any rights'),
]
and in settings.py
:
AUTH_USER_MODEL = 'myapp.User'
Upvotes: 0
Reputation: 8367
All answers are bad for me except this:
content_type = ContentType.objects.get_for_model(Permission)
Permission.objects.create(
content_type=content_type,
name='...', codename='...',
)
which handles model-less permissions without adding new models, but by adding new values.
Upvotes: 0
Reputation: 2580
For my part, for any larger project, I find it useful to have a generic app that isn't really part of my project's data model per se - I typically call it "projectlibs". It's a simple django app where I put things like fixtures for imports, templatetags that can be reused for multiple apps, etc. Some of it is template stuff I find myself re-using often, so the added benefit of having that type of stuff in an app is that it's reusable for other projects.
So inside that projectlibs/models.py
, you could:
You could create that "meta app", in essence, and assign the content_type
to some dummy class:
class UserRightsSupport(models.Model):
class Meta:
default_permissions = () # disable defaults add, delete, view, change perms
permissions = (
("perm_name", "Verbose description"),
)
Upvotes: 2
Reputation: 7330
You can use the proxy model
for this with a dummy content type.
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType
class CustomPermission(Permission):
class Meta:
proxy = True
def save(self, *args, **kwargs):
ct, created = ContentType.objects.get_or_create(
model=self._meta.verbose_name, app_label=self._meta.app_label,
)
self.content_type = ct
super(CustomPermission, self).save(*args)
Now you can create the permission with just name
and codename
of the permission from the CustomPermission
model.
CustomPermission.objects.create(name='Can do something', codename='can_do_something')
And you can query and display only the custom permissions in your templates like this.
CustomPermission.objects.filter(content_type__model='custom permission')
Upvotes: 2
Reputation: 27806
This is alternative solution. First ask yourself: Why not create a Dummy-Model which really exists in DB but never ever gets used, except for holding permissions? That's not nice, but I think it is valid and straight forward solution.
from django.db import models
class Permissions(models.Model):
can_search_blue_flower = 'my_app.can_search_blue_flower'
class Meta:
permissions = [
('can_search_blue_flower', 'Allowed to search for the blue flower'),
]
Above solution has the benefit, that you can use the variable Permissions.can_search_blue_flower
in your source code instead of using the literal string "my_app.can_search_blue_flower". This means less typos and more autocomplete in IDE.
Upvotes: 5
Reputation: 4269
Django's Permission
model requires a ContentType
instance.
I think one way around it is creating a dummy ContentType
that isn't related to any model (the app_label
and model
fields can be set to any string value).
If you want it all clean and nice, you can create a Permission
proxy model that handles all the ugly details of the dummy ContentType
and creates "modelless" permission instances. You can also add a custom manager that filters out all Permission
instances related to real models.
Upvotes: 63