Permissions & Decorators

Permissions in Django control what an authenticated user is allowed to do, and decorators like @login_required and @permission_required are wrappers you place above a view to enforce those rules — redirecting or blocking anyone who isn't allowed before the view ever runs.

Learn Permissions & Decorators in our free Django course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Django course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

In this lesson you'll learn how to lock views down so only logged-in users reach them, how Django's built-in model permissions and groups work, and how to protect both function-based and class-based views cleanly.

The most common rule on a website is simply: you must be logged in to see this page . Django ships a decorator for exactly that. A decorator is a function that wraps another function to add behaviour before or after it runs, and you apply one by placing it on the line above a view with the @ symbol.

When you decorate a view with @login_required , Django checks request.user.is_authenticated first. If the user is signed in, the view runs normally. If not, Django redirects them to the login page defined by LOGIN_URL in your settings, attaching a next parameter so they come back afterward.

To really understand the decorator, it helps to see one written from scratch in plain Python. The example below builds a tiny login_required wrapper around a fake request, exactly like Django does under the hood.

Being logged in is rarely enough — an editor should change posts while a regular reader should not. Django solves this with permissions . For every model you create, Django automatically generates four permissions: add , change , delete , and view .

Each permission has a string identifier in the form app_label.codename . For a Post model in a blog app, the change permission is blog.change_post . You can check whether a user holds it in code with user.has_perm('blog.change_post') , or enforce it on a view with the @permission_required decorator.

Assigning the same permissions to many users one at a time is tedious, so Django gives you groups . A group is a named bundle of permissions; add a user to the "Editors" group and they inherit every permission that group holds.

The runnable example models has_perm() with a simple user object, then shows how a permission check decides what an action returns.

Decorators wrap plain functions, so they fit function-based views perfectly. Class-based views use inheritance instead, so Django provides mixins that add the same protection. A mixin is a small class you list as a parent to inject behaviour.

Use LoginRequiredMixin to require authentication, and PermissionRequiredMixin with a permission_required attribute to require a specific permission. The crucial rule: list the mixin before the base view class, so its check runs first.

For rules that don't map to a stored permission — say "only staff active before 2020" or "email ends in @company.com" — use the @user_passes_test decorator. You give it a function that receives the user and returns True to allow access or False to redirect to login.

Fill in the blank so the function correctly checks whether the user is allowed to delete a post using the right method name.

❌ Adding parentheses to @login_required when you have no arguments... or forgetting them when you do

Bare @login_required works with no arguments, but to pass options you must call it: @login_required(login_url="/signin/") .

✅ Fix: use @login_required alone, or @login_required(login_url=...) with parentheses when overriding the redirect.

❌ PermissionDenied even though the user clearly has access

The permission string is wrong — it must be 'app_label.codename' , not just the codename. Writing 'change_post' instead of 'blog.change_post' never matches.

✅ Fix: always include the app label, e.g. @permission_required("blog.change_post") .

The mixin was listed after the base view class, so the base view handled the request first and the check never ran.

✅ Fix: put the mixin before the view base — class PostList(LoginRequiredMixin, ListView) , never the reverse.

Build a small access gate that combines a login check and a permission check, returning the right message for guests, logged-in readers, and editors.

Lesson 18 complete — your views are locked down!

You now know how @login_required gates a view, how Django's add/change/delete/view permissions and groups work, how to enforce them with @permission_required and user.has_perm(), and how to protect class-based views with LoginRequiredMixin, PermissionRequiredMixin, and @user_passes_test.

🚀 Up next: Django REST Framework Intro — start building APIs on top of the foundation you've learned.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary