Summary of Django permission usage

summary

Django comes with a user authentication system, which can handle user, group, permission and session based on user cookie. This document is based on the introduction of Django official website documents and other materials. The main content introduces the basic working principle of Django’s user authentication system, and also gives a brief introduction to how to customize user authentication for your project.

How permission works in Django

First of all, we need to define the permission object, which needs to be bound to the corresponding model.
Then, the defined permission can be given to the user or group object to realize the binding of permission and user.
Finally, in view and template, you can verify the permissions of user or group through the API.

Definition of authority

Permission can be defined in a variety of ways:

Defined in model

We can define permission in meta of model.
An example of the official website is as follows:

Separate definition

Or it can be defined in a location independent of the model.
An example of the official website is as follows:

Do not bind specific model definitions

In the above two examples, permission can only be defined when we already have a model. If we want to define permission without a model, what should we do?Although this demand is a little strange
Reference to Google GroupA page that doesn’t exist：

url_content_type = ContentType.objects.create(
    name='url permission', app_label='crashstats', model='unused')

can_view_url = Permission.objects.create(
    name='can view url', content_type=url_content_type,
    codename='can_view_url')

user = User.objects.get(username='example_user', is_superuser=False)
user.user_permissions.add(can_view_url)

This is also supported by binding to a nonexistent model. In practice, it is found that it is feasible to assign an empty string to model when defining contenttype, but none is not.

A more general solution

This will get the permission object we defined. Moreover, Django will assign each permission a globally unique code, rule: < app_ label>.<permission_ codename>。 Through this code, you can specify the corresponding permission

Authorization

Permission can be granted through user or group.
User through user_ The permissions property sets the permission, and the group sets the permission through the permissions property.

An example of the official website is as follows:

Verification of authority

Verify permissions in view

Checking with decorator

An example of the official website is as follows:

Note: in addition to specifying a single permission with string, permissions also supports list and tuple for multiple permissions.

Check with mixin

An example of the official website is as follows:

Verifying permissions in template

If it is set in Django’s settings django.contrib.auth .context_ processors.auth , and if requestcontext is enabled, Django will pass two variables in the template by default:

• {{ user }}

• {{ perms }}

Among them{{ perms }}Variables can be used in the template to provide different templates through different permissions.

In fact, Django provides two API functions for the use of permission in the template. One is User.has_ module_ Perms; the other is User.has_ perm。
When you use the{{ perms.foo }}Call the User.has_ module_ Perms method, if the user has foo permission, this value will be true.
When you use the{{ perms.foo.can_vote }}Call the User.has_ Perm method, if the user has foo.can_ If vote permission is used, the value will be true.

Example of permission in template:

Reference documents

Official website authentication system document
Content type document on official website
User defined verification document on official website