Securing Views with LoginRequiredMixin and @login_required

1. The Problem: Publicly Accessible Views

Let's imagine you have a view that displays a user's profile. As we saw in the last lesson, we can use {% if user.is_authenticated %} in a template to show or hide a link to that page. But what happens if a logged-out user knows the URL (e.g., /profile/) and types it directly into their browser? Right now, they would either see an error or a broken page, but they wouldn't be stopped from accessing the URL itself.

This is a security vulnerability. We need a way to intercept the request at the view level and redirect any unauthenticated user to the login page.

2. Protecting Function-Based Views with @login_required

The simplest way to protect a function-based view is with a decorator. A decorator is a special Python feature that "wraps" a function, adding new functionality before the original function runs. Django's @login_required decorator does exactly this: it checks if the user is logged in. If they are, it runs the view as normal. If not, it redirects them.

Corey Schafer's tutorial provides an excellent hands-on demonstration of creating a profile page and then securing it.

Summary of Steps

As you saw in the video, protecting a function-based view involves two simple steps:

1. Apply the decorator to your view in views.py:

   from django.contrib.auth.decorators import login_required
   from django.shortcuts import render
   
   @login_required
   def profile_view(request):
       # ... your view logic here
       return render(request, 'users/profile.html')
   

2. Define the login URL in your project's settings.py. This tells the decorator where to send users who aren't logged in.

   # your_project/settings.py
   
   # ... other settings
   
   LOGIN_URL = 'login' # The name of your login URL pattern
   

3. Protecting Class-Based Views with LoginRequiredMixin

Decorators are for functions. But for our project, we've been using Class-Based Views (CBVs) like ListView and CreateView. To protect these, we use a similar concept called a mixin.

A mixin is a special kind of class that provides a set of methods and attributes that can be "mixed in" to another class. The LoginRequiredMixin provides the exact same login-checking functionality as the @login_required decorator, but in a way that works with classes.

This article gives a concise and clear explanation.

Let's apply this to the TaskListView that you will build for your task manager. Without protection, anyone could see the list of tasks. Here is how you would secure it:

# your_app/views.py

from django.contrib.auth.mixins import LoginRequiredMixin
from django.views.generic import ListView
from .models import Task # Assuming you have a Task model

class TaskListView(LoginRequiredMixin, ListView):
    model = Task
    template_name = 'your_app/task_list.html'
    context_object_name = 'tasks'
    login_url = '/login/' # Optional: overrides the LOGIN_URL from settings.py

Notice the inheritance: class TaskListView(LoginRequiredMixin, ListView):. By adding LoginRequiredMixin to the list of parent classes (and ensuring it's first), you've successfully protected this view. Any non-authenticated user trying to access the task list will be redirected to the URL specified in LOGIN_URL (or the view's login_url attribute, if provided).

The dev.to article "Get Done ✅" shows this in action within a full to-do list project, which is very similar to your goal. You can see LoginRequiredMixin used consistently across TodoListView, TaskCreate, TaskUpdate, and TaskDelete views.

Conclusion

Great work! You now have the essential tools to secure your application and ensure that private pages remain private. This is a non-negotiable skill for any web developer.

Key Takeaways:

• Authorization vs. Authentication: In the last lesson, you implemented authentication (who is the user?). Today, you implemented authorization (what is this user allowed to do?).
• Function-Based Views: Protect them by applying the @login_required decorator above the function definition.
• Class-Based Views: Protect them by adding LoginRequiredMixin to the list of parent classes, making sure it comes before the generic view class (like ListView, CreateView, etc.).
• Configuration is Key: Both methods rely on LOGIN_URL being correctly set in your settings.py file to redirect unauthorized users.

Preview of the Next Lesson:
Our views are now secure, but there's still a problem. If two different users log in, they will both see the same list of all tasks. We've ensured only logged-in users can see the page, but we haven't made the data itself user-specific.

In the next lesson, "Associate application data (e.g., tasks) with the currently logged-in user," we will solve this. You will learn how to link data to a specific user and filter your queries so that users can only see and manage their own information.