Mixin

在FBV中，如果希望为视图的访问加上限制的话可以直接使用装饰器，但在CBV中就不能直接使用装饰器了。

比如说django auth提供的默认的login_required装饰器和permission_required装饰器，在CBV中则为LoginRequiredMixin以及PermissionRequiredMixin。

这两个Mixin都继承于AccessMixin（导致了它们引起的异常跳转指向同一个url），下面看一下它们的源码分析。

class LoginRequiredMixin(AccessMixin):
    """
    CBV mixin which verifies that the current user is authenticated.
    """
    def dispatch(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            # 该方法继承于AccessMixin
            return self.handle_no_permission()
        return super(LoginRequiredMixin, self).dispatch(request, *args, **kwargs)

class PermissionRequiredMixin(AccessMixin):
    """
    CBV mixin which verifies that the current user has all specified
    permissions.
    """
    permission_required = None

    def get_permission_required(self):
        """
        Override this method to override the permission_required attribute.
        Must return an iterable.
        """
        if self.permission_required is None:
            raise ImproperlyConfigured(
                '{0} is missing the permission_required attribute. Define {0}.permission_required, or override '
                '{0}.get_permission_required().'.format(self.__class__.__name__)
            )
        if isinstance(self.permission_required, six.string_types):
            perms = (self.permission_required, )
        else:
            perms = self.permission_required
        return perms

    def has_permission(self):
        """
        Override this method to customize the way permissions are checked.
        """
        perms = self.get_permission_required()
        return self.request.user.has_perms(perms)

    def dispatch(self, request, *args, **kwargs):
        if not self.has_permission():
            # 该方法继承于AccessMixin
            return self.handle_no_permission()
        return super(PermissionRequiredMixin, self).dispatch(request, *args, **kwargs)

各位同学可以看到，这两个Mixin都实现了dispatch方法，并且在执行完以后调用的是按照MRO数组中的下一个类的dispatch方法。（MRO是Python多重继承时采用的方法，不了解的同学可以先参考这篇文章：你真的理解Python中MRO算法吗？）

举个简单的例子，假设笔者自定义了一个CBV：

class MyView(LoginRequiredMixin, PermissionRequiredMixin, View)

那么，dispatch按照依次调用的顺序则是，LoginRequiredMixin，PermissionRequiredMixn，AccessMixin（没有disptach方法），View。因此，基类View一定要放在多重继承的最后面，因为它的dispatch方法调用就是代表业务逻辑的handler了。

当LoginRequiredMixin或者PermissionRequiredMixin调用继承自AccessMixin的handle_no_permission方法时，如果raise_exception被设置为True，会抛出一个PermissionDenied的异常，否则跳转到login_url。

class AccessMixin(object):
    """
    Abstract CBV mixin that gives access mixins the same customizable
    functionality.
    """
    login_url = None
    permission_denied_message = ''
    raise_exception = False
    redirect_field_name = REDIRECT_FIELD_NAME

    def get_login_url(self):
        """
        Override this method to override the login_url attribute.
        """
        login_url = self.login_url or settings.LOGIN_URL
        if not login_url:
            raise ImproperlyConfigured(
                '{0} is missing the login_url attribute. Define {0}.login_url, settings.LOGIN_URL, or override '
                '{0}.get_login_url().'.format(self.__class__.__name__)
            )
        return force_text(login_url)

    def get_permission_denied_message(self):
        """
        Override this method to override the permission_denied_message attribute.
        """
        return self.permission_denied_message

    def get_redirect_field_name(self):
        """
        Override this method to override the redirect_field_name attribute.
        """
        return self.redirect_field_name

    def handle_no_permission(self):
        if self.raise_exception:
            raise PermissionDenied(self.get_permission_denied_message())
        return redirect_to_login(self.request.get_full_path(), self.get_login_url(), self.get_redirect_field_name())

这一个异常首先被执行view函数的代码捕捉到，也就是本文中的第一个代码段，然后调用self.process_exception_by_middleware。

    def process_exception_by_middleware(self, exception, request):
        """
        Pass the exception to the exception middleware. If no middleware
        return a response for this exception, raise it.
        """
        for middleware_method in self._exception_middleware:
            response = middleware_method(request, exception)
            if response:
                return response
        raise

由于没有定义任何关于异常的钩子，所以程序直接执行到最后一行raise一个异常，那么这一个异常又是被谁捕捉到呢？

还记得笔者再上一篇博客中(Django处理http请求流程剖析)提及的convert_exception_to_response装饰了self._get_legacy_response这一件事情么，这一个异常就是被convert函数捕捉到了。

def convert_exception_to_response(get_response):
    """
    Wrap the given get_response callable in exception-to-response conversion.

    All exceptions will be converted. All known 4xx exceptions (Http404,
    PermissionDenied, MultiPartParserError, SuspiciousOperation) will be
    converted to the appropriate response, and all other exceptions will be
    converted to 500 responses.

    This decorator is automatically applied to all middleware to ensure that
    no middleware leaks an exception and that the next middleware in the stack
    can rely on getting a response instead of an exception.
    """
    @wraps(get_response, assigned=available_attrs(get_response))
    def inner(request):
        try:
            response = get_response(request)
        except Exception as exc:
            response = response_for_exception(request, exc)
        return response
    return inner

def response_for_exception(request, exc):
    if isinstance(exc, Http404):
        if settings.DEBUG:
            response = debug.technical_404_response(request, exc)
        else:
            response = get_exception_response(request, get_resolver(get_urlconf()), 404, exc)

    elif isinstance(exc, PermissionDenied):
        logger.warning(
            'Forbidden (Permission denied): %s', request.path,
            extra={'status_code': 403, 'request': request},
        )
        response = get_exception_response(request, get_resolver(get_urlconf()), 403, exc)

    elif isinstance(exc, MultiPartParserError):
        logger.warning(
            'Bad request (Unable to parse request body): %s', request.path,
            extra={'status_code': 400, 'request': request},
        )
        response = get_exception_response(request, get_resolver(get_urlconf()), 400, exc)

    elif isinstance(exc, SuspiciousOperation):
        # The request logger receives events for any problematic request
        # The security logger receives events for all SuspiciousOperations
        security_logger = logging.getLogger('django.security.%s' % exc.__class__.__name__)
        security_logger.error(
            force_text(exc),
            extra={'status_code': 400, 'request': request},
        )
        if settings.DEBUG:
            response = debug.technical_500_response(request, *sys.exc_info(), status_code=400)
        else:
            response = get_exception_response(request, get_resolver(get_urlconf()), 400, exc)

    elif isinstance(exc, SystemExit):
        # Allow sys.exit() to actually exit. See tickets #1023 and #4701
        raise

    else:
        signals.got_request_exception.send(sender=None, request=request)
        response = handle_uncaught_exception(request, get_resolver(get_urlconf()), sys.exc_info())

    return response

比如PermissionDenied异常对应的状态码就是403，如果在urls中定义了对应状态码的view函数，则调用该函数。

比如：

# urls.py
handler403 = 'path/to/handler_view'

最后一种情况是，如果希望LoginRequiredMixin和PermissionRequiredMixin跳转到不同的login_url该怎么办？可以考虑在继承的时候先使用LoginRequiredMixin，然后在具体的http方法上加上method_decorator。