Permissions can be set not only per type of object, but also per specific object instance. By using the has_add_permission(), has_change_permission() and has_delete_permission() methods provided by the ModelAdmin class, it\u2019s possible to customize permissions for different object instances of the same type. User objects have two many-to-many fields: groups and user_permissions. User objects can access their related objects in the same way as any other Django model.<\/p>\n
Default Permissions<\/h3>\n
When django.contrib.auth is listed in your INSTALLED_APPS setting, it will ensure that three default permissions \u2013 add, change and delete \u2013 are created for each Django model defined in one of your installed applications. These permissions will be created for all new models each time you run manage.py migrate.<\/p>\n
Groups<\/h3>\n
django.contrib.auth.models.Group models are a generic way of categorizing users so you can apply permissions, or some other label, to those users. A user can belong to any number of groups. A user in a group automatically has the permissions granted to that group. For example, if the group Site editors has the permission can_edit_home_page, any user in that group will have that permission.<\/p>\n
Beyond permissions, groups are a convenient way to categorize users to give them some label, or extended functionality. For example, you could create a group \u201cSpecial users,\u201d and you could write code that could, say, give them access to a members-only portion of your site, or send them members-only email messages.<\/p>\n
Programmatically Creating Permissions<\/h3>\n
While custom permissions can be defined within a model\u2019s Meta class, you can also create permissions directly. For example, you can create the can_publish permission for a BookReview model in books:<\/p>\n
from books.models import BookReview
\nfrom django.contrib.auth.models import Group, Permission
\nfrom django.contrib.contenttypes.models import ContentType<\/p>\n
content_type = ContentType.objects.get_for_model(BookReview)
\npermission = Permission.objects.create(codename=’can_publish’,
\nname=’Can Publish Reviews’,
\ncontent_type=content_type)<\/p>\n
The permission can then be assigned to a User via its user_permissions attribute or to a Group via its permissions attribute.<\/p>\n
Permission Caching<\/h3>\n
The ModelBackend caches permissions on the User object after the first time they need to be fetched for a permissions check. This is typically fine for the request-response cycle since permissions are not typically checked immediately after they are added (in the admin, for example).<\/p>\n
If you are adding permissions and checking them immediately afterward, in a test or view for example, the easiest solution is to re-fetch the User from the database. For example:<\/p>\n
from django.contrib.auth.models import Permission, User
\nfrom django.shortcuts import get_object_or_404<\/p>\n
def user_gains_perms(request, user_id):
\nuser = get_object_or_404(User, pk=user_id)
\n# any permission check will cache the current set of permissions
\nuser.has_perm(‘books.change_bar’)<\/p>\n
permission = Permission.objects.get(codename=’change_bar’)
\nuser.user_permissions.add(permission)<\/p>\n
# Checking the cached permission set
\nuser.has_perm(‘books.change_bar’) # False<\/p>\n
# Request new instance of User
\nuser = get_object_or_404(User, pk=user_id)<\/p>\n
# Permission cache is repopulated from the database
\nuser.has_perm(‘books.change_bar’) # True<\/p>\n
# …<\/p>\n
Managing Users in the Admin<\/h3>\n
When you have both django.contrib.admin and django.contrib.auth installed, the admin provides a convenient way to view and manage users, groups, and permissions. Users can be created and deleted like any Django model. Groups can be created, and permissions can be assigned to users or groups. A log of user edits to models made within the admin is also stored and displayed.<\/p>\n
Creating Users<\/strong> – You should see a link to \u201cUsers\u201d in the \u201cAuth\u201d section of the main admin index page. If you click this link, you should see the user management screen.<\/p>\n The \u201cAdd user\u201d admin page is different than standard admin pages in that it requires you to choose a username and password before allowing you to edit the rest of the user\u2019s fields.<\/p>\n If you want a user account to be able to create users using the Django admin site, you\u2019ll need to give them permission to add users and change users (i.e., the \u201cAdd user\u201d and \u201cChange user\u201d permissions). If an account has permission to add users but not to change them, that account won\u2019t be able to add users.Why? Because if you have permission to add users, you have the power to create superusers, which can then, in turn, change other users. So Django requires add and change permissions as a slight security measure.<\/p>\n User passwords are not displayed in the admin (nor stored in the database), but the password storage details are displayed. Included in the display of this information is a link to a password change form that allows admins to change user passwords. Once you click the link, you will be taken to the change password form.<\/p>\n Password management is something that should generally not be reinvented unnecessarily, and Django endeavors to provide a secure and flexible set of tools for managing user passwords. This document describes how Django stores passwords, how the storage hashing can be configured, and some utilities to work with hashed passwords.<\/p>\n How Django Stores Passwords<\/strong> – Django provides a flexible password storage system and uses PBKDF2 by default. The password attribute of a User object is a string in this format:<\/p>\n <algorithm>$<iterations>$<salt>$<hash><\/p>\n Those are the components used for storing a User\u2019s password, separated by the dollar-sign character and consist of: the hashing algorithm, the number of algorithm iterations (work factor), the random salt, and the resulting password hash.<\/p>\n The algorithm is one of a number of one-way hashing or password storage algorithms Django can use. Iterations describe the number of times the algorithm is run over the hash. Salt is the random seed used and the hash is the result of the one-way function. By default, Django uses the PBKDF2 algorithm with a SHA256 hash, a password stretching mechanism recommended by NIST. This should be sufficient for most users: it\u2019s quite secure, requiring massive amounts of computing time to break. However, depending on your requirements, you may choose a different algorithm, or even use a custom algorithm to match your specific security situation. Again, most users shouldn\u2019t need to do this \u2013 if you\u2019re not sure, you probably don\u2019t.<\/p>\n If you do, please read on: Django chooses the algorithm to use by consulting the PASSWORD_HASHERS setting. This is a list of hashing algorithm classes that this Django installation supports. The first entry in this list (that is, settings.PASSWORD_HASHERS[0]) will be used to store passwords, and all the other entries are valid hashers that can be used to check existing passwords.<\/p>\n This means that if you want to use a different algorithm, you\u2019ll need to modify PASSWORD_HASHERS to list your preferred algorithm first in the list. The default for PASSWORD_HASHERS is:<\/p>\n PASSWORD_HASHERS = [ This means that Django will use PBKDF2 to store all passwords, but will support checking passwords stored with PBKDF2SHA1, bcrypt, SHA1 etc. The next few sections describe a couple of common ways advanced users may want to modify this setting.<\/p>\n Bcrypt is a popular password storage algorithm that\u2019s specifically designed for long-term password storage. It\u2019s not the default used by Django since it requires the use of third-party libraries, but since many people may want to use it, Django supports bcrypt with minimal effort.<\/p>\n To use Bcrypt as your default storage algorithm, do the following:<\/p>\n PASSWORD_HASHERS = [ (You need to keep the other entries in this list, or else Django won\u2019t be able to upgrade passwords).<\/p>\n That\u2019s it \u2013 now your Django install will use bcrypt as the default storage algorithm.<\/p>\n Password truncation with BCryptPasswordHasher<\/strong> – The designers of bcrypt truncate all passwords at 72 characters which means that bcrypt(password_with_100_chars) == bcrypt(password_with_100_chars[:72]). The original BCryptPasswordHasher does not have any special handling and thus is also subject to this hidden password length limit. Other bcrypt implementations – There are several other implementations that allow bcrypt to be used with Django. Django\u2019s bcrypt support is NOT directly compatible with these. To upgrade, you will need to modify the hashes in your database to be in the form bcrypt$(raw bcrypt output).<\/p>\n Increasing the work factor – The PBKDF2 and bcrypt algorithms use a number of iterations or rounds of hashing. This deliberately slows down attackers, making attacks against hashed passwords harder. However, as computing power increases, the number of iterations needs to be increased. For example, to increase the number of iterations used by the default PBKDF2 algorithm:<\/p>\n from django.contrib.auth.hashers import PBKDF2PasswordHasher<\/p>\n class MyPBKDF2PasswordHasher(PBKDF2PasswordHasher): PASSWORD_HASHERS = [ That\u2019s it \u2013 now your Django install will use more iterations when it stores passwords using PBKDF2.<\/p>\n Password Upgrading<\/strong> – When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that old installs of Django will get automatically more secure as users log in, and it also means that you can switch to new (and better) storage algorithms as they get invented.<\/p>\n However, Django can only upgrade passwords that use algorithms mentioned in PASSWORD_HASHERS, so as you upgrade to new systems you should make sure never to remove entries from this list. If you do, users using unmentioned algorithms won\u2019t be able to upgrade. Passwords will be upgraded when changing the PBKDF2 iteration count.<\/p>\n![\"\"](\"https:\/\/www.vskills.in\/lms\/wp-content\/uploads\/2016\/07\/36.jpg\")
<\/p>\nChanging Passwords<\/h3>\n
Password Management in Django<\/h3>\n
\n‘django.contrib.auth.hashers.PBKDF2PasswordHasher’,
\n‘django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher’,
\n‘django.contrib.auth.hashers.BCryptSHA256PasswordHasher’,
\n‘django.contrib.auth.hashers.BCryptPasswordHasher’,
\n‘django.contrib.auth.hashers.SHA1PasswordHasher’,
\n‘django.contrib.auth.hashers.MD5PasswordHasher’,
\n‘django.contrib.auth.hashers.CryptPasswordHasher’,
\n]\nUsing Bcrypt with Django<\/h3>\n
\n
\n\uf0fc Modify PASSWORD_HASHERS to list BCryptSHA256PasswordHasher first. That is, in your settings file, you\u2019d put:<\/li>\n<\/ul>\n
\n‘django.contrib.auth.hashers.BCryptSHA256PasswordHasher’,
\n‘django.contrib.auth.hashers.BCryptPasswordHasher’,
\n‘django.contrib.auth.hashers.PBKDF2PasswordHasher’,
\n‘django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher’,
\n‘django.contrib.auth.hashers.SHA1PasswordHasher’,
\n‘django.contrib.auth.hashers.MD5PasswordHasher’,
\n‘django.contrib.auth.hashers.CryptPasswordHasher’,
\n]\n
\nBCryptSHA256PasswordHasher fixes this by first hashing the password using sha256. This prevents the password truncation and so should be preferred over the BCryptPasswordHasher. The practical ramification of this truncation is pretty marginal as the average user does not have a password greater than 72 characters in length and even being truncated at 72, the compute powered required to brute force bcrypt in any useful amount of time is still astronomical. Nonetheless, we recommend you use BCryptSHA256PasswordHasher anyway on the principle of \u201cbetter safe than sorry\u201d.<\/p>\n
\nThe Django development team have chosen a reasonable default (and will increase it with each release of Django), but you may wish to tune it up or down, depending on your security needs and available processing power. To do so, you\u2019ll subclass the appropriate algorithm and override the iterations parameters.<\/p>\n\n
\niterations = PBKDF2PasswordHasher.iterations * 100<\/p>\n\n
\n‘myproject.hashers.MyPBKDF2PasswordHasher’,
\n‘django.contrib.auth.hashers.PBKDF2PasswordHasher’,
\n# … #
\n]\n