如何在Django中基于用户权限配置多角色条件化首页视图

Hey there! I totally get your frustration with repeating code using @permission_required for different user roles—total pain when you just want a single homepage that adapts to permissions without redundancy. Let's walk through a few clean, maintainable ways to solve this, including fixing that "reverse permission" issue you mentioned.

1. Single View with Inline Permission Checks (Most Straightforward) #

Instead of splitting into multiple views with duplicate logic, handle all permission checks inside one index view. This keeps your code centralized and lets you easily check for "lack of permission" using not.

Here's how to implement it:

from django.shortcuts import render
from django.contrib.auth.decorators import login_required  # Optional but recommended to ensure user is logged in
from .models import Job

@login_required
def index(request):
    context = {}
    user = request.user

    # Check permissions and populate context with role-specific content
    if user.has_perm('jobs.can_add'):
        # Content for users with add permissions
        context['jobs'] = Job.objects.all()
        context['role_message'] = "You can add new jobs from the dashboard!"
        context['show_add_button'] = True
    elif user.has_perm('jobs.can_edit'):
        # Content for users with edit permissions
        context['jobs'] = Job.objects.filter(assigned_editor=user)  # Example: Show only editable jobs
        context['role_message'] = "Manage your assigned jobs below."
        context['show_edit_button'] = True
    else:
        # Content for users with no special permissions
        context['jobs'] = Job.objects.filter(is_public=True)
        context['role_message'] = "Browse public job listings."

    return render(request, 'index.html', context)

This approach eliminates redundant view code, and you can directly use if not user.has_perm('jobs.can_edit') to handle reverse permission checks (exactly what you were missing with the decorator).

2. Template-Level Permission Handling (Split Logic Cleanly) #

For even more flexibility, you can keep your view simple (just pass base data) and let the template handle role-specific rendering using Django's built-in perms template variable.

View Code: #

@login_required
def index(request):
    # Pass base data to the template
    context = {
        "all_jobs": Job.objects.all(),
        "user_jobs": Job.objects.filter(assigned_editor=request.user),
        "public_jobs": Job.objects.filter(is_public=True)
    }
    return render(request, 'index.html', context)

Template (index.html): #

{% if perms.jobs.can_add %}
    <h1>Admin Dashboard</h1>
    <p>{{ role_message }}</p>
    <a href="{% url 'job_add' %}" class="btn">Add New Job</a>
    {% for job in all_jobs %}
        <!-- Render full job details -->
    {% endfor %}
{% elif perms.jobs.can_edit %}
    <h1>Editor Dashboard</h1>
    <p>{{ role_message }}</p>
    {% for job in user_jobs %}
        <!-- Render job with edit button -->
    {% endfor %}
{% else %}
    <h1>Welcome to Job Listings</h1>
    {% for job in public_jobs %}
        <!-- Render public-only job details -->
    {% endfor %}
{% endif %}

This splits concerns: the view handles data retrieval, the template handles presentation based on permissions.

3. Custom Decorator for Reverse Permissions (If You Prefer Decorator Style) #

If you still want to use decorators but need to check for "lack of permission", create a custom decorator to handle negated permissions:

from django.contrib.auth.decorators import user_passes_test
from django.core.exceptions import PermissionDenied

def permission_required_negated(perm, login_url=None, raise_exception=False):
    """
    Decorator that checks if the user does NOT have the specified permission.
    """
    def check_perms(user):
        if not user.has_perm(perm):
            return True
        # Handle users who DO have the permission
        if raise_exception:
            raise PermissionDenied
        return False
    return user_passes_test(check_perms, login_url=login_url)

Use it like this:

@permission_required_negated('jobs.can_edit')
def index_for_non_editors(request):
    # Logic for users without edit permissions
    ...

Note: This works best if you only need to split into two distinct views, but for 2+ roles, the first two methods are more efficient to avoid code duplication.

4. Class-Based View (CBV) with Permission Logic #

If you prefer Django's class-based views, use LoginRequiredMixin and override get_context_data to handle role-specific content:

from django.views.generic import TemplateView
from django.contrib.auth.mixins import LoginRequiredMixin
from .models import Job

class IndexView(LoginRequiredMixin, TemplateView):
    template_name = 'index.html'

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        user = self.request.user

        if user.has_perm('jobs.can_add'):
            context['jobs'] = Job.objects.all()
            context['role_message'] = "Admin: Manage all jobs"
        elif user.has_perm('jobs.can_edit'):
            context['jobs'] = Job.objects.filter(assigned_editor=user)
            context['role_message'] = "Editor: Manage your assigned jobs"
        else:
            context['jobs'] = Job.objects.filter(is_public=True)
            context['role_message'] = "User: Browse public jobs"

        return context

Map it in urls.py:

path('', IndexView.as_view(), name='index'),

CBVs shine if you want to reuse permission logic across multiple views later (you can extract the permission check into a custom Mixin).

内容的提问来源于stack exchange，提问作者brunam