如何在原生Django中实现视图级（Per View）认证方案？

Great question! It’s totally valid to wonder why Django doesn’t have built-in view-level authentication schemes like DRF does—let’s dive into how to roll your own solution, and touch on why this isn’t out-of-the-box.

Method 1: Custom Decorators for Function-Based Views #

Django’s built-in decorators like @login_required or @permission_required cover common cases, but for custom view-specific rules, a reusable decorator is your best bet. Here’s how to build one:

from django.http import HttpResponseForbidden

def view_auth_required(auth_check):
    """
    A decorator that takes an authentication check function,
    which should return True if the user is allowed access.
    """
    def decorator(view_func):
        def wrapped_view(request, *args, **kwargs):
            if not auth_check(request.user):
                return HttpResponseForbidden("You don't have permission to access this view.")
            return view_func(request, *args, **kwargs)
        return wrapped_view
    return decorator

# Example 1: Restrict to staff users
@view_auth_required(lambda user: user.is_staff)
def staff_dashboard(request):
    return HttpResponse("Welcome to the staff dashboard!")

# Example 2: Restrict to users in a specific group
def is_content_editor(user):
    return user.groups.filter(name="Content Editors").exists()

@view_auth_required(is_content_editor)
def editor_panel(request):
    return HttpResponse("Hello, content editor!")

This lets you define exactly what authentication logic each view needs, without relying on DRF’s abstractions.

Method 2: Custom Mixins for Class-Based Views #

If you prefer class-based views (CBVs), a mixin lets you reuse authentication logic across multiple views. Here’s a flexible implementation:

from django.views.generic import View
from django.http import HttpResponseForbidden

class ViewAuthMixin:
    """
    Mixin to add view-level authentication to CBVs.
    Set the `auth_condition` attribute to your check function.
    """
    auth_condition = None

    def dispatch(self, request, *args, **kwargs):
        # Ensure the auth condition is set and passes
        if not self.auth_condition or not self.auth_condition(request.user):
            return HttpResponseForbidden("Access denied: You don't meet the authentication requirements.")
        return super().dispatch(request, *args, **kwargs)

# Example usage
class AdminAnalyticsView(ViewAuthMixin, View):
    auth_condition = lambda user: user.is_superuser

    def get(self, request):
        return HttpResponse("Superuser-only analytics data")

class PremiumUserView(ViewAuthMixin, View):
    def auth_condition(self, user):
        # More complex logic: check if user has an active premium subscription
        return hasattr(user, 'subscription') and user.subscription.is_active

    def get(self, request):
        return HttpResponse("Premium content here!")

Why Doesn’t Vanilla Django Have This Built-In? #

Django’s core philosophy is to provide robust, opinionated tools for common web app needs, while leaving more specialized or flexible extensions to third-party packages or custom code. DRF prioritizes view-level authentication because APIs often have granular access control needs (e.g., public vs. private endpoints, different token schemes for different views).

Vanilla Django leans on its permission system and basic decorators for most cases—if you need something more tailored, building your own decorator or mixin is straightforward, as we showed above.

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