DRF(十四)：认证源码分析

认证源码分析

认证的执行，是发生在dispatch函数的过程中。

image-20201230142921787

值得注意的是，封装request的时候，我们的指定的认证类也会一起封装在新的request里面。

image-20201230144040055

接下来看看get_authenticators的执行。

image-20201230144621995

使用列表生成式挨个实例化了每个authentication_classes里面的认证类。而authentication_classes读取了我们自定义的认证类。

注：

如果是局部认证，那么就是我们直接给authentication_classes赋值

如果是全局认证，那么就是读取我们settings中的DEFAULT_AUTHENTICATION_CLASSES配置项。

image-20201230144321708

之后，在initial函数中，执行了三大验证，其中就有认证。

image-20201230143144627

而认证直接执行了request.user，它其实是一个被@property装饰的方法。

image-20201230143539050

接下来的操作都是在rest_framework.request模块里面。新封装的request就是这下面的Request类的实例。

image-20201230143610541

当没有_user属性的时候，说明还未认证，则会执行 _authenticate() 方法

image-20201230145633396

• 认证成功，返回元组。
• 认证失败，执行_not_authenticated。
• 元组值为空则，遍历下一个authenticator对象

补充

最后，一个问题，当配置了全局认证以后，之后每个接口的访问都要执行认证，而有的借口并不需要认证或者认证的类不一样（如登陆接口），该怎么办呢？

其实很好办，全局设置以后并不影响局部设置的生效，因为局部设置的优先级大于全局设置，就比如对于登陆接口来说，我们只需要在登陆接口CBV中设置authentication_classes为空就可以了。如果有特殊需要，也可以指定其他认证类。

python

class LoginAPIView(APIView):
    authentication_classes = []