<p>Authentication or identification by itself is not usually sufficient to gain access to information or code. For that, the entity requesting access must have authorization.</p>
<p>Together with <ahref="authentication">authentication</a> and <ahref="throttling">throttling</a>, permissions determine wheter a request should be granted or denied access.</p>
<p>Permission checks are always run at the very start of the view, before any other code is allowed to proceed. Permission checks will typically use the authentication information in the <code>request.user</code> and <code>request.auth</code> properties to determine if the incoming request should be permitted.</p>
<h2id="how-permissions-are-determined">How permissions are determined</h2>
<p>REST framework permissions also support object-level permissioning. Object level permissions are used to determine if a user should be allowed to act on a particular object, which will typically be a model instance.</p>
<p>Object level permissions are run by REST framework's generic views when <code>.get_object()</code> is called. As with view level permissions, an <code>exceptions.PermissionDenied</code> exception will be raised if the user is not allowed to act on the given object.</p>
<h2id="setting-the-permission-policy">Setting the permission policy</h2>
<p>The default permission policy may be set globally, using the <code>DEFAULT_PERMISSIONS</code> setting. For example.</p>
<p>The <code>IsAuthenticated</code> permission class will deny permission to any unauthenticated user, and allow permission otherwise.</p>
<p>This permission is suitable if you want your API to only be accessible to registered users.</p>
<h2id="isadminuser">IsAdminUser</h2>
<p>The <code>IsAdminUser</code> permission class will deny permission to any user, unless <code>user.is_staff</code>is <code>True</code> in which case permission will be allowed.</p>
<p>This permission is suitable is you want your API to only be accessible to a subset of trusted administrators.</p>
<p>The <code>IsAuthenticatedOrReadOnly</code> will allow authenticated users to perform any request. Requests for unauthorised users will only be permitted if the request method is one of the "safe" methods; <code>GET</code>, <code>HEAD</code> or <code>OPTIONS</code>.</p>
<p>This permission is suitable if you want to your API to allow read permissions to anonymous users, and only allow write permissions to authenticated users.</p>
<p>This permission class ties into Django's standard <code>django.contrib.auth</code><ahref="https://docs.djangoproject.com/en/1.0/topics/auth/#permissions">model permissions</a>. When applied to a view that has a <code>.model</code> property, authorization will only be granted if the user has the relevant model permissions assigned.</p>
<ul>
<li><code>POST</code> requests require the user to have the <code>add</code> permission on the model.</li>
<li><code>PUT</code> and <code>PATCH</code> requests require the user to have the <code>change</code> permission on the model.</li>
<li><code>DELETE</code> requests require the user to have the <code>delete</code> permission on the model.</li>
</ul>
<p>The default behaviour can also be overridden to support custom model permissions. For example, you might want to include a <code>view</code> model permission for <code>GET</code> requests.</p>
<p>To use custom model permissions, override <code>DjangoModelPermissions</code> and set the <code>.perms_map</code> property. Refer to the source code for details.</p>
<p>The <code>DjangoModelPermissions</code> class also supports object-level permissions. Third-party authorization backends such as <ahref="https://github.com/lukaszb/django-guardian">django-guardian</a> that provide object-level permissions should work just fine with <code>DjangoModelPermissions</code> without any custom configuration required.</p>
<p>To implement a custom permission, override <code>BasePermission</code> and implement the <code>.has_permission(self, request, obj=None)</code> method.</p>
