Permissions & Authorization

Never confuse Authentication (AuthN) with Authorization (AuthZ). Authentication is handing your ID to a security guard to prove you exist. Authorization is swiping your keycard on a door to see if you have clearance to enter. A user can be perfectly authenticated (logged in) but completely unauthorized (lacking permissions) to view a specific page.

Assigning individual permissions directly to users is terrible practice. If you have 50 editors, and you add a new 'Publish' permission, you would have to manually update 50 different user accounts. Instead, you create an 'Editors' Group, assign the permission to the Group once, and all 50 users instantly inherit the new privilege.

The default permission blog.change_post is global—it means 'This user can edit ANY post'. But in most apps (like Twitter), users can only edit their *own* data. Django does not support this out of the box. You must manually check if post.author != request.user: in your View, and explicitly raise a PermissionDenied error to block them.

Authentication vs Authorization. There is a massive difference between Authentication and Authorization. Authentication simply verifies your identity ('I am Alice'). Authorization verifies your privileges ('Is Alice allowed to delete this database record?'). Django's robust permission system provides fine-grained control over exactly what each individual user is allowed to do within your application, protecting your data from unauthorized modifications.

Default Model Permissions. Every time you run makemigrations and create a new database Model (e.g., Post), Django's system automatically generates three default permissions for it in the background: add_post, change_post, and delete_post. These permissions are named using the pattern app_name.action_modelname. You can assign these specific permissions to specific users via the Django Admin panel or through Python code.

If you have an app named store and a model named Product, what is the exact string name of the permission Django automatically generates to allow a user to edit products?

• →'store.change_product'
• →'store.edit_product'

The permission_required Decorator. Just like @login_required blocks anonymous visitors, the @permission_required decorator completely blocks logged-in users who do not possess the required security clearance. If Alice is logged in but doesn't have the delete_post permission, this decorator intercepts her request and safely returns an HTTP 403 Forbidden error, preventing her from accessing the view logic entirely.

PermissionRequiredMixin (CBVs). For Class-Based Views, you utilize the PermissionRequiredMixin. Just like the Login mixin, it MUST be declared first in the inheritance hierarchy. You then define the permission_required class attribute. This highly efficient architecture ensures that your views remain clean and completely decoupled from complex authorization checks.

User Groups. Manually assigning 15 different permissions to 100 different users is a management nightmare. Django solves this with 'Groups'. You create a Group (e.g., 'Editors'), assign the 15 permissions directly to the Group, and then simply add users to the Group. If Alice is added to 'Editors', she instantly inherits all 15 permissions. If you remove a permission from the Group, it instantly updates for all members.

If you assign the 'delete_product' permission to the 'Managers' Group, do you also need to manually assign it to the individual users inside that group?

• →Yes, you must assign it to both the group and the users.
• →No, users automatically inherit all permissions granted to their group.

Object-Level Permissions. Default permissions apply globally. If Bob has change_post, he can edit ANY post in the entire database. But what if Bob should only be allowed to edit HIS OWN posts? Django does not handle Object-Level Permissions natively. To achieve this, you simply verify ownership directly in the View logic: check if the post.author matches request.user. If it doesn't, return a 403 Forbidden.

Authorization Mastered. Brilliant! You have mastered the Authorization layer. You understand the fundamental difference between AuthN and AuthZ, how to apply default model permissions, how to protect routes using the @permission_required decorator, and how to scale permission management using Groups. You've also learned how to manually enforce object-level ownership. Next, we leave HTML behind and enter the world of APIs.