drf-前篇

1.Django的架构 浏览器--> wsgi(accept、recv、send) 中间件 路由 视图 数据库 模版
2.前后端分离与不分离 模版是谁渲染 
  step1> 浏览器向 前端服务器 发送请求 --> 前端服务器 返回html+css+js给浏览器,浏览器呈现空荡荡的页面,没有数据
  step2> 浏览器运行js代码向 后端服务器 发送ajax请求 --> 后端服务器 返回json格式的数据 --> 浏览器通过js代码将数据渲染到页面上
  
  前端:前端代码 eg:网页、APP、微信小程序 -- 常见技术 vue.js react.js angular.js
  后端:API -- Django Django-restframeworks

self = cls(**initkwargs)   # --!! 准确点说,self是InfoView的实例!!传入的cls是类InfoView! 
类APIView的实例,**initkwargs意味着在路由里写代码时,path('info/', views.InfoView.as_view()), 
"★" 这个as_view(),括号里是可以传递参数进去的,用作类实例化.
"★" 更有意思的是,APIView里面没有__init__,APIView继承View,所以类实例化时,它用的View的__init__
view的__init__是这样写的,很值得学习.
"""
  class View:
    def __init__(self, **kwargs):
        for key, value in kwargs.items():
            setattr(self, key, value)
"""

as_view()里的**initkwargs用作视图类实例化时构造函数里的参数;
view()里的*args、**kwarg可接收动态路由上传递的参数.

"★" 通过源码,可以得知 在drf的视图函数中,可以通过 self.args、self.kwargs 获取路由传递的参数!!
"""
  def dispatch(self, request, *args, **kwargs):
      self.args = args
      self.kwargs = kwargs
"""

- Django和DRF的CBV写法,都是闭包 + 反射 "★是一个类方法的闭包哦! -- as_view" 返回的都是 view函数.. 
  但DRF得到的是 免除CSRF认证的view..
- 类方法里使用super,super函数的第二个参数是cls.
- request是何时传的? 路由匹配成功时.和动态路由参数一起传过去的,request是位置参数,所以需先传.


1> "★" dispatch中依次是 二次封装request -- [try] 认证、权限 -- 反射执行视图函数 [except] 捕获向上抛出的异常
"""
   "★" # dispatch一开始就将request进行了二次封装,往下的request都是drf中的reuqest
   request = self.initialize_request(request, *args, **kwargs)  # 二次封装request
   self.initial(request, *args, **kwargs)  # 认证、权限、限流
"""
2> 其实Django的as_view里的代码 self.setup(request, *args, **kwargs)
   setup方法里,就执行了 self.args = args self.kwargs = kwargs  不重要,不知道也无妨.

0> 在dispath里,二次封装request后, 有这样一行代码 self.request = request 
   ★ 意味着在视图类的任一实例方法里,都可通过 self.request 使用drf的request!!
1> 二次封装的request self.request.query_params 本质就是 self._request.GET
   @property
   def query_params(self):
       return self._request.GET
2> 一定要注意是哪个对象!! # 若不写这个try..except..抛出异常说的是Django的request中没有,写了后,变成了drf的request中没有.
   class Request:
       def __getattr__(self, attr):
           try:
               return getattr(self._request, attr)
           except AttributeError:
               return self.__getattribute__(attr)

1. 思考下,路由如何传递的参数?
  1> path('auth/<int:pk>/', views.auth),若网址是127.0.0.1:8000/auth/1/ 是以关键字参数的形式将 pk=1 传递给auth函数
     "★" auth函数可以通过 def auth(request,pk):.. 或者 def auth(request,*args,**kwargs):.. 进行接收.
     Ps:pk会在kwargs里.
  2> ★★★ 在Django和drf的CBV里,都会执行view “加括号执行”,也就是说,匹配成功后
     会将路由中的参数给到 def view(request,*args,**kwargs)里;
     然后再将参数传递给 self.dispatch(request,*args,**kwargs) 函数;
     然后再通过反射传递给了相应的get、post..方法. handler(request,*args,**kwargs)
     <底层是怎么加括号的,路由上的参数怎么就传递到view函数的*args和**kwargs里的,不必深究.>
2. 思考下,Django和drf的request有何不同?
  Django的request -- 包含请求相关的所有数据
  drf的request -- 在APIView的dispatch方法中进行了二次封装!(包含原来的request,也新添加了一些东西)
                  Ps:在视图中想获取原来request的值,可以通过 request._request.GET  request._request.POST 

1. 在settings中配置匿名用户 <其实不写也行drf默认配置里写的有>
"""
REST_FRAMEWORK = {
    "UNAUTHENTICATED_USER": None,   # 设置 request.user
    "UNAUTHENTICATED_TOKEN": None,  # 设置 request.auth
}
"""
2.写认证类,重写authenticate和authenticate_header方法..
3.在视图类中进行认证类的应用! (一般这些认证类会作用于该视图类中的所有接口)

-- 若很多视图类都需进行相同的认证类的应用,那么可以进行全局配置减少这类代码的书写!
REST_FRAMEWORK = {
    "UNAUTHENTICATED_USER": None,
    "UNAUTHENTICATED_TOKEN": None,
    "DEFAULT_AUTHENTICATION_CLASSES": [
        "ext.auth.QueryParamsAuthentication",
        "ext.auth.HeaderAuthentication",
        "ext.auth.NoAuthentication",
    ],
  
-- 不管怎样,不需要认证的 视图类 养成好习惯,写上authentication_classes = []

1> 局部&全局配置 -- 底层本质原理就是oop的继承,属性的查找顺序
  案例1: 项目要开发3个接口,其中1个是无需登录就能访问的接口、其余2个是必须登录才能访问的接口.  -- 局部配置
  案例2: 项目要开发100个接口,其中1个是无需登录就能访问的接口、其余99个是必须登录才能访问的接口.. -- 全局配置!!
2> 多个认证类
  案例3: 后端drf项目支持很多应用, 比如网页、小程序、app, 他们都可以访问后端某个接口.访问时需要认证,获取token信息.
      一般来说, 我们可以约定这些应用的token信息通过url传递, 但前端开发不同意..
      它非要在网页中将token放到url、小程序和app中将token放到请求头中.. 这就必须让后端的接口在认证时兼顾这三种情况.
<其实上面应用场景描述中说 接口,不是很严谨. 是初学者的认知>

3> "★★★"
Q:只要给视图类配置了认证,那么该视图类的 所有方法/所有视图函数 都得经过认证后才能执行!
  若我们自己写的视图类中有get、post、put等方法,只需要对put方法进行认证,怎么办?/ 即get、post方法不需要认证就可以执行.
  (每个请求都会执行一遍截图中的认证源码 该请求是get请求就不可能是post请求put等其它请求类型.Hhh‘废话文学’)
A: - 那么在认证类中判断请求类型是否是PUT,只对其进行认证即可!!
   - 或者再写个视图类,单独实现put方法,加上认证,就完了!
   - 还有种方法,重写源码中的 perform_authentication方法!
   def perform_authentication(self, request):
       if request.method == "PUT":
           # 正常的进行认证
           request.user
       # 提示: 不需要认证,就是匿名用户呗.
       request.user = None
       request.auth = None
   - 最优的方法!!推荐 重写get_authenticators方法  "一切的一切都服务于这一次的请求"
   def get_authenticators(self):
       if self.request.method == "PUT":
           return [auth() for auth in self.authentication_classes]
       return []

此处我们需重写authenticate方法: To do 用户认证
用户认证过程: 1.读取请求传递过来的token 2.校验该token的合法性
authenticate方法的返回值有三种:
1> 认证成功,返回元祖
   在后续认证的相关源码中,该元祖的两个值会分别赋值给request.user、request.auth
   一般request.user存储用户信息;request.auth存储Token信息
2> 认证失败,抛出异常,返回错误信息
3> 返回None 涉及到多个认证类 [类1,类2,类3,类4]
   会依次执行认证类的authenticate方法,若当前类的authenticate方法返回None,会逐一往后找
   直到某个类认证成功或失败,往后的认证类的authenticate方法都不再执行
   若这些认证类[都]返回None,会默认返回一个匿名用户! request.user的值为None,表明是匿名访问
  
"""关键的伪代码如下:
for authenticator in [认证类,认证类,认证类]:
    user_auth_tuple = authenticator.authenticate()  # 此处抛出了异常也不会往下执行啦.
    if user_auth_tuple:
        self.user, self.auth = user_auth_tuple
        return
"""
简单来说,执行每个认证类里的authenticate方法
  - 一旦某个认证类认证成功或者认证过程抛出异常导致认证失败,不会再管后续的认证类;
  - 只有返回None,才会继续往后执行下一个认证类里的authenticate方法;
  (简而言之,这么些个认证类,只要有一个认证成功或失败,后续的认证类就不用管了)

DEFAULTS = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.BasicAuthentication'
    ],
    # Authentication
    'UNAUTHENTICATED_USER': 'django.contrib.auth.models.AnonymousUser',
    'UNAUTHENTICATED_TOKEN': None,
}
==> 
  - 关于drf默认配置的认证类,他们皆返回的是None!
  - 关于drf默认的认证配置 --> UNAUTHENTICATED_USER 和 UNAUTHENTICATED_TOKEN
    1. 若我们不重新设置UNAUTHENTICATED_USER,那么 匿名用户访问时/所有认证类都返回None 时,
       在视图函数里打印 request.user 其值是AnonymousUser
    2. 若我们重新设置UNAUTHENTICATED_USER,将其值设置为None,那么 匿名用户访问时/所有认证类都返回None时,
       在视图函数里打印 request.user 其值是None
  - 若我们 设置 authentication_classes = [] 不进行认证, 跟匿名用户访问得到的request.user、request.auth一样.

认证类里,认证不通过,报错 raise AuthenticationFailed({"status": False, "error": "认证失败"})
若在认证类里重写了authenticate_header方法,那么返回http的状态码是401 unauthoried未经授权;
若没有重写的话,返回的http状态码是403 forbidden 禁止;

# 注意此处,传递给AuthenticationFailed的是一个字符串或传递一个字典,认证失败时,返回的结果是不一样的!!
raise AuthenticationFailed("认证失败!")  ===>  {"detail":"认证失败!"}
raise AuthenticationFailed({"code": 1002, "error": "认证失败"})  ===>   {"code": 1002, "error": "认证失败"}

看dispatch中异常处理的源码就明白了!

1. 写权限类,重写has_permission方法.
2. 在视图类中进行权限类的应用! -- 局部配置 (一般这些权限类会作用于该视图类中的所有接口)

-- 若很多视图类都需进行相同的视图类的应用,那么可以进行全局配置减少这类代码的书写!
REST_FRAMEWORK = {
    "DEFAULT_PERMISSION_CLASSES": [
        "ext.per.MyPermission1",
        "ext.per.MyPermission2",
        "ext.per.MyPermission3",
    ],
}

-- 不管怎样,不需要权限的 视图类 养成好习惯,写上permission_classes = []

1. 按照上面“实现权限”的步骤 / 初学者的认知
    -1- 权限是"且"的关系
        一个权限类就是一个条件,视图类A中的所有接口都是在满足[条件1,条件2]时才能访问; 
        视图类B中的所有接口都是在满足[条件3,条件4]时才能访问!!
    -2扩展的- 权限是"或"的关系
        用户登陆后/认证成功后, 访问接口会进行有关角色的权限校验. 举个例子, 用户有三种角色, 总监/经理/员工 ,   
        视图类A中的所有接口只能总监或经理访问; 视图类B中的所有接口只能经理或员工访问!!
2.  "★★★" (权限是"且"的关系)若想视图类A中的 
   GET接口不需要进行,POST接口权限满足条件1和满足条件2才能访问、PUT接口满足条件3和满足条件4才能访问. 如何实现呢??
   最优解,在视图类里重写get_permissions方法!! 关键在于return哪些权限类 Hhh
   def get_permissions(self):
       if self.request.method == "GET":
           return []
       elif self.request.method == "POST":
           return [MyPermission1(),MyPermission2()]
       elif self.request.method == "PUT":
           return [MyPermission3(),MyPermission4()]
       else:
           return [permission() for permission in self.permission_classes]

上面截图中,匿名访问的两种情况,本质都是配置的所有的认证类都返回None!!
关于raise怎样的错误信息,是剖析源码分析出来的!!

提示几点:<怕是只有自己能看懂Hhh>
- 当permission_classes = []时,权限的关键源码中for循环直接执行完啦,check_permissions方法直接返回None,相当于不进行权限!
- 执行permission_denied方法 >> 代表权限不通过
- 当authentication_classes = []时,条件 request.authenticators 为假!!

def initial(self, request, *args, **kwargs):
    self.perform_authentication(request)  # 认证
    self.check_permissions(request)  # 权限

def check_permissions(self, request):
    for permission in self.get_permissions():  # 提醒:注意permission_classes=[]的情况, 不进行权限即权限直接通过了!
        if not permission.has_permission(request, self):
            self.permission_denied(
                request,
                message=getattr(permission, 'message', None),
                code=getattr(permission, 'code', None)
            )

def permission_denied(self, request, message=None, code=None):
    # print(request.user, request.auth, request._authenticator)
    if request.authenticators and not request.successful_authenticator:
        # -- 权限不通过 且 匿名访问
        raise Exception({"code": 1003, "error": "NotAuthenticated 没有提供身份验证凭据!"})  
    # -- 权限不通过且成功访问 、权限不通过且不进行认证
    raise Exception({"code": 1004, "error": "PermissionDenied 没有执行该操作的权限!"})  
        
"""
permission.has_permission(request, self)
这就是为啥在编写权限类时要重写has_permission方法!!并且重写的该方法要返回bool值!

传入的self是当前的视图类的实例对象! 这个设计细品,能感觉很巧妙.
◆ 这意味着,
So, obj = 视图类(), 此时obj通过点语法能取到的东西,权限类的has_permission方法中的view参数都可以取到!!
比如 在视图类里定义一个类变量name='dc' 在权限类的has_permission方法中就可以通过view.name就可以取到!
>> 类变量、__init__里给类实例化变量定制的属性、类中的绑定方法、类中的非绑定方法等. 复习下oop的知识就清楚了!!
"""
      
---- 回顾下认证组件
认证组件=[认证类,认证类,认证类]
循环认证组件,依次执行每个认证类里的authenticate方法
    - 一旦某个认证类认证成功或者认证过程抛出异常导致认证失败,不会再管后续的认证类;
    - 只有返回None,才会继续往后执行下一个认证类里的authenticate方法;
    简而言之,这么些个认证类,只要有一个认证成功或失败,后续的认证类就不用管了
    <None None None raise 只要有一个成功即可> -- 此时,就类似于 or或的关系!!

DEFAULTS = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.AllowAny',
    ],
}
==> 
  - 若啥也不做,drf的配置文件里就有一个默认的权限类,它返回的是True!

默认的权限校验失败错误提示信息是这样的. 
{"detail": "You do not have permission to perform this action."}  # 没有执行该操作的权限!

可以在权限类中自定义错误信息:
- 在权限类中编写一个类变量 message = {"status": 1003, "msg": "无权访问1"}, message的值是啥,不通过返回的结果就是啥!!

class BaseApiView(APIView):
    def check_permissions(self, request):
        """若是or或关系,返回True,表明权限校验成功、返回False,会将错误信息收集起来,当所有权限条件都无一通过,权限校验失败."""
        no_permissions_obj = []
        for permission in self.get_permissions():
            if permission.has_permission(request, self):
                return  # -- 有一个条件满足,就直接结束这个函数啦!!
            no_permissions_obj.append(permission)
        else:
            self.permission_denied(
                request,
                message=getattr(no_permissions_obj[0], 'message', None),
                code=getattr(no_permissions_obj[0], 'code', None)
            )


class OrderView(BaseApiView):
    permission_classes = [MyPermission1, MyPermission2, MyPermission3]

    def get(self, request):
        return Response("OrderView-get")

理清下述的生命周期!! ★★★
请求进来,先经过中间件
1.依次执行完所有中间件的process_request方法
2.进行路由匹配,找到了路由对应的视图函数!!(FBV) 若是drf的CBV,找到的是那个闭包中的函数view 注:此view是免除了csrf认证的!
  (▼ 注意!该函数此时是没有执行的!!)
3.依次执行所有中间件的process_view方法
4.接着,执行闭包中的函数view   view()
  闭包中的view干了几件事
  1> 创建CBV视图类的实例化对象 self = cls()  
  2> 执行self.disptch   注:视图类是继承APIView的,self中没有disptch,APIView中有
     2.1> 请求封装
     2.2> 进行认证、权限的处理
5.最后,执行所有中间件的process_response方法

1. mac安装redis,启动redis 并在Django配置文件中配置redis
2. 写限流类,
   -1- 限流类继承SimpleRateThrottle,重写get_cache_key -- 该方法的返回值将作为redis 一条记录的key值
   -2- 速率相关的设置 二者选其一
       - 设置类变量scope eg: scope="xxx"
         看配置文件中的DEFAULT_THROTTLE_RATES,(优先是django项目的配置文件,再是drf的配置文件)
         若DEFAULT_THROTTLE_RATES字典中没有跟scope值对应的键,那么还得设置类变量 THROTTLE_RATES = {"xxx":"5/m"}
       - 设置类变量rate eg: rate="5/m"
3. 在 视图类 中应用限流类 -- 局部配置 (一般这些限流类会作用于该视图类中的所有接口)

当然限流类也可以像认证和权限一样进行全局配置!! "几乎不会进行全局配置."
REST_FRAMEWORK = {
    'DEFAULT_THROTTLE_CLASSES': [
        'ext.throttle.MyThrottle1',
        'ext.throttle.MyThrottle2',
    ],
}

注: 速率在项目配置文件中的配置,当然若你不想这么做 在限流类里设置类变量 THROTTLE_RATES 也是可以的!!
REST_FRAMEWORK = {
    'DEFAULT_THROTTLE_RATES': {
        'xxx': "5/m",     # 对应 类变量scope值为"xxx" 的限流类
        'yyy': "2000/d",  # 对应 类变量scope值为"yyy" 的限流类
    },
}

-细说- 细说下限流
<已知条件>
   MyThrottle1 -- "throttle_MyThrottle1_1":[时间戳1,时间戳2...] 5/m
   MyThrottle2 -- "throttle_MyThrottle2_2":[时间戳1,时间戳2...] 3/m
   视图类A有 GET类型的接口1 和 POST类型的接口2 ; 视图类B有 GET类型的接口3 和 POST类型的接口4
   ★: "throttle_MyThrottle1_1"是限流类MyThrottle1在redis中的key值/唯一标识,此值就是限流类里get_cache_key方法的返回值!!
<应用>
   ++ 按照初学者的认知 ++
   ① 视图类A局部配置了限流类 throttle_classes = [MyThrottle1,MyThrottle2]
      ==> 那么,MyThrottle1和MyThrottle2都会作用于视图类A下的所有接口(接口1和接口2),
          无论浏览器访问接口1还是接口2,都会消耗每个限流类的一个次数
          (即throttle_MyThrottle1_1的列表新增一个时间戳,throttle_MyThrottle1_1的列表新增一个时间戳)
   ② 视图类A和视图B都局部配置了限流类 throttle_classes = [MyThrottle1,MyThrottle2]
      若项目中仅有视图类A和视图类B,那么,就相当于[MyThrottle1,MyThrottle2]进行了全局配置!
      ==> 意味着,MyThrottle1和MyThrottle2都会作用于 接口1,接口2,接口3,接口4
          同理,访问1-4的任一接口,MyThrottle1和MyThrottle2的可用次数都会减1
   ★ 综上,关于限流,我们绝大多数场景下都选择进行局部配置! 而且每个限流类的get_cache_key方法返回的唯一标识都应是不一样的!!
   ++ 真实的应用场景里 ++
   Q1: [场景1] 视图类A中的接口1不需要限流,接口2需要限流.
   A1: 视图类A中重写get_throttles方法!! 借助self.request.method来实现.
   Q2: [场景2] 视图类A的接口1限流频率 3/m、视图类A的接口2限流频率 5/m+200/h（即不仅要限制每分钟的请求次数,还需要限制每小时的）
   A2: 视图类A中重写get_throttles方法!! 借助self.request.method来实现.
       5/m+200/h 给接口2配置两个限流类就可以实现!
   Q3: [场景3] 视图类A中的接口1在认证成功后限流频率是10/m, 匿名用户/未认证时限流频率是2/m
   A3: 重写get_throttles方法!! 借助self.request.method + self.request.user来实现.

你剖析allow_request方法的源码,你可以发现,关于 redis中某条数据 'xxx':[时间戳1,时间戳2]  的更新,有两个操作:
1> 首先就会检查 列表中的时间戳 有没有过期! 过期了的就剔除掉.
2> 每当我往列表里新增一个时间戳(一般是从下标0的位置插入),该条数据自动删除的时间就会更新
   - 自动删除的时间更新为 新增的那个时间戳+时间间隔! 
   - 新增的那个肯定是最新的,这个新增的都过期了,列表中的其他时间戳肯定都过期了!!

已知条件 -- 假设视图类A下仅有接口1,视图类A局部配置了限流类1,限流类1的速率配置是 100/h
极端场景 -- 我们以一个极端的例子进行分析:
           浏览器在凌晨首次访问了接口1,过了59分钟后,从59分1s开始狂点接口1,当点击达到99次后,再次点击
           会提示 下次访问还需等待多久 等待时间是 第一次访问时间经过1个小时还需多久 比如5s
           5s后,我们再次点击 会提示 下次访问还需等待多久 等待时间是 第二次访问时间经过1个小时还需多久 
           以此类推.
        骚操作:出现限流提示后,你不管它,等待1h后再点击,就可以再狂点100次啦!

例如:以短信验证登陆为例.
  短信平台自身限制每个账号1小时只能发10次验证;
  但这限制的不够严谨.攻击者可以找上万个手机号,向后端的短信登陆接口发送请求,消耗短信数量.增加了维护的费用.
  So,仅仅依靠短信平台的限制来防止"盗刷"是远远不够的.还需加入其他限制手段!
  1> IP限制 (哪怕攻击者找了10万个手机号,也需要切换IP
  2> 验证码 (减缓验证的速度
  3> 像什么商品信息页面,加入防爬虫的机制

限制访问频率,我们需要一些东西来 [构建/组成] 唯一标识
  - 已登陆的用户,唯一标识> 用户信息主键(ID、用户名
  - 匿名用户,唯一标识> IP
    扩展“暂且了解即可”:针对IP,访问者可以通过代理IP来绕过IP的限制.
        SO,现在很多网页和程序在IP限制的基础上,还会加入js算法以增加访问接口的难度(不是直接向该接口发送个json数据那么简单啦)
        IP+JS算法(若想破解该JS算法,需要逆向)

-1- 继承SimpleRateThrottle的限流类需要干些什么?
 1. 必须得重写get_cache_key方法! -- 返回值将会作为redis的键
 2. 速率/限流频率 相关的设置 二者选其一
    - 设置类变量scope eg: scope="xxx"
      若配置文件的DEFAULT_THROTTLE_RATES字典中没有跟scope值对应的键,那么还得设置类变量 THROTTLE_RATES = {"xxx":"5/m"}
    - 设置类变量rate eg: rate="5/m"

-2- 若限流类的频率设置为None 那么相当于该限流没设置; 
-3- 若唯一标识的值为None/get_cache_key方法返回值为None,那么相当于该限流没设置;

def check_throttles(self, request):
    """检查请求是否应受到限制. 如果请求受到限制,则引发相应的异常"""
    throttle_durations = []
    # self.get_throttles() 得到所有限流类的实例化对象列表 将其循环. 注意:此处的类实例化,需看__init__
    for throttle in self.get_throttles():  # 提醒:注意throttle_classes=[]的情况, 不进行限流即限流直接通过了!
        # 注:调用的是SimpleRateThrottle里的allow_request,判断是否应该对该请求进行节流
        if not throttle.allow_request(request, self):  
            throttle_durations.append(throttle.wait())

    if throttle_durations:
        # changes, see #1438
        durations = [
            duration for duration in throttle_durations
            if duration is not None
        ]

        duration = max(durations, default=None)
        self.throttled(request, duration)  # 该方法会抛出异常,告知最大需要等待多久
        
简单来说:
1> 当所有限流类的实例化对象执行throttle.allow_request(request, self)都返回True时,
   那么throttle_durations列表为空,意味着限流的验证结束/check_throttles限流方法执行完毕 
   接着往下就是执行视图函数. - So,都返回True,就不限流呗.
2> 只要有一个throttle.allow_request(request, self)返回False,就会限流
   将 <需要等待的时间 throttle.wait()计算需要等待的时间> 加入throttle_durations列表中
   当有多个限流类的实例化对象返回False时,throttle_durations列表中就会有多个值!

DEFAULTS = {
    'DEFAULT_THROTTLE_CLASSES': [],
}
==> 那就是默认大家都不限流呗!

# 源码中,它只是传递了 最大等待的时间, 提示信息的格式是固定了的!!
def throttled(self, request, wait):
    raise exceptions.Throttled(wait)

from rest_framework import exceptions
from rest_framework import status


class ThrottleException(exceptions.APIException):
    status_code = status.HTTP_429_TOO_MANY_REQUESTS
    default_code = "throttled"

    def __init__(self, wait, code=None):
        if not wait:
            msg = 'Request was throttled.'
        else:
            msg = f"需等待{int(wait)}s后才能访问!"
        detail = {
            "code": 1005,
            "data": "访问频繁",
            "wait": msg,
        }
        super().__init__(detail, code)
    

class LoginView(APIView):
    authentication_classes = []
    permission_classes = []
    throttle_classes = [MyThrottle, ]

    def post(self, request):pass

    def throttled(self, request, wait):
        raise ThrottleException(wait)

源码里allow_request方法
- 返回True,表示当前限流类允许访问 >> check_throttles 里的for循环继续执行 后续限流类的allow_request方法;
- 返回False,表示当前限流类不允许访问,会计算等待时间加入throttle_durations列表中
  >> check_throttles 里的for循环继续执行 后续限流类的allow_request方法;
     当循环完毕,会找到throttle_durations列表中的最大等待时间,返回限流用户提示信息!

上述只是源码提供的流程,我们还可以分析源码,进行扩展.扩展/自定义第三种情况.
check_throttles 当前限流类不允许访问时,不返回False,而是直接抛出异常APIException类型的异常
该异常的抛出会导致循环结束,程序终止,也就是说, '[<后续的限流类都不会执行,不会管啦>]'.
异常会被APIView.dispatch里的try..except..捕获到!!

from rest_framework import exceptions
from rest_framework import status
from rest_framework.throttling import SimpleRateThrottle


class ThrottleException(exceptions.APIException):
    status_code = status.HTTP_429_TOO_MANY_REQUESTS
    default_code = "throttled"

    def __init__(self, wait, code=None):
        if not wait:
            msg = 'Request was throttled.'
        else:
            msg = f"需等待{int(wait)}s后才能访问!"
        detail = {
            "code": 1005,
            "data": "访问频繁",
            "wait": msg,
        }
        super().__init__(detail, code)

 
# 至此,限流类就可以有两个选择, 继承SimpleRateThrottle 或者继承RaiseRateThrottle
# 前者allow_request方法只能返回True和Fasle,后者allow_request方法可返回True、False以及raise!
class RaiseRateThrottle(SimpleRateThrottle):
    def throttle_failure(self):
        wait = self.wait
        raise ThrottledException(wait)

'rest_framework.throttling.UserRateThrottle',
'rest_framework.throttling.AnonRateThrottle',
这两个drf写好了的限流类,我看了下源码,还蛮有意思的,看的时候注意几点:
-1- request.user.is_authenticated 
    匿名用户时,request.user是AnonymousUser; 
    认证成功request.user通常是当前登陆用户对象,我们需要在其model类中添加is_authenticated方法（此处暂时没进行验证）
-2- 限流类的get_ident是获取ip地址.
   
AnonRateThrottle 用于限制未认证用户"匿名用户"的请求频率，主要根据用户的 IP地址来确定用户身份
UserRateThrottle 用于限定认证用户"认证成功、匿名用户"的请求频率 >> 认证成功-id ; 匿名用户-ip  

注: 限流规则复杂了,drf的默认限流就不好使了,只能根据需求自己写限流.