给cbv下面的函数加装饰器

写一个验证用户登录的程序

前端页面

# 写一个装饰器验证session
def login_auth(func):def inner(request,*args,**kwargs):if request.session.get('is_login'):return func(request,*args,**kwargs)else:return redirect('/login/')return inner

定义cbv

class Home(View):def get(self,request):passdef post(self,request):pass

视图函数

# 两种加装饰器的方法
# 1,类名上面加装饰器
from django.utils.decoration import method_decorator
@method_decorator(login_auth,name='get')  # 加在类上面的话，必须通过name指定给谁加
class Home(View):def get(self,request):passdef post(self,request):pass

# 2，方法上面加,不要用原生的装饰器，用的话，只能改参数，那样的话不通用
class Home(View):@method_decorator(login_auth) def get(self,request):passdef post(self,request):pass

第三种定义dispatch函数,拦截内置的分发函数，但是写在cbv里的 方法都会被加上装饰器

class MyHome(View):@method_decorator(login_auth)  # 第三种  get和post都会被装饰def dispatch(self, request, *args, **kwargs):super().dispatch(request,*args,**kwargs)# @method_decorator(login_auth)  # 第一种def get(self,request):return HttpResponse('get')def post(self,request):return HttpResponse('post')

Django中间件

Process_request和Process_response方法

继承MiddlewareMixin类 实现自定义中间件

from django.utils.deprecation import MiddlewareMixinclass MD1(MiddlewareMixin):def process_request(self, request):print("MD1里面的 process_request")def process_response(self, request, response):print("MD1里面的 process_response")return responseclass MD2(MiddlewareMixin):def process_request(self, request):print("MD2里面的 process_request")passdef process_response(self, request, response):print("MD2里面的 process_response")return response

在settings.py的MIDDLEWARE配置项中注册上述两个自定义中间件：

MIDDLEWARE = ['middlewares.MD1',  # 自定义中间件MD1'middlewares.MD2'  # 自定义中间件MD2
]

总结：

1. 中间件的process_request方法是在执行视图函数之前执行的。
2. 当配置多个中间件时，会按照MIDDLEWARE中的注册顺序，也就是列表的索引值，从前到后依次执行的。
3. 不同中间件之间传递的request都是同一个对象
4. 多个中间件中的process_response方法是按照MIDDLEWARE中的注册顺序倒序执行的，也就是说第一个中间件的process_request方法首先执行，而它的process_response方法最后执行，最后一个中间件的process_request方法最后一个执行，它的process_response方法是最先执行

process_view

process_view(self, request, view_func, view_args, view_kwargs)该方法有四个参数request是HttpRequest对象。view_func是Django即将使用的视图函数。 （它是实际的函数对象，而不是函数的名称作为字符串。）view_args是将传递给视图的位置参数的列表.view_kwargs是将传递给视图的关键字参数的字典。 view_args和view_kwargs都不包含第一个视图参数（request）。Django会在调用视图函数之前调用process_view方法。

它应该返回None或一个HttpResponse对象。 如果返回None，Django将继续处理这个请求，执行任何其他中间件的process_view方法，然后在执行相应的视图。 如果它返回一个HttpResponse对象，那么将不会执行Django的视图函数，而是直接在中间件中掉头，倒叙执行一个个process_response方法，最后返回给浏览器

process_template_response和process_exception两个方法的触发是有条件的，执行顺序也是倒序。总结所有的执行流程如下：

总结

process request：请求来的时候从上往下依次执行每一个中间件里面的process request processresponse：响应走的时候会从下往上依次执行每一个中间件里面的process response方法
process view：路由匹配成功执行视图之前自动触发（从上往下依次执行）
processexception：当视图函数报错了，自动触发（从下往上依次执行）
processtemplate response：视图函数返回的对象有一个render（）方法（或者表明该对象是一个TemplateResponse对象或等价方法）（从下往上依次执行）

CSRF

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性

可以这样来理解：
攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户

Django中的防止措施在前端页面写

{% csrf_token %}django就会自动帮我们渲染一个随机字符串做校验

不是网站上的所有字段都是需要校验的，这个时候我们需要给函数加上装饰器，给特定的功能加上csrf校验，或者给特定的功能不做csrf校验

在注释掉setting文件中的csrf组件前提下导入

    from django.views.decorators.csrf import csrf_exempt,csrf_protect

给指定的功能加上csrf校验用csrf_protect装饰器

这里写的加装饰器的方式与给cbf加装饰器的方式一样，需要注意的是给某些功能去掉csrf校验的装饰器csrf_exempt只有两种使用方式，都是加给全局的。

csrf_exempt  只能有下面两种方式@method_decorator(csrf_exempt,name='dispatch')  # 第一种 class Index3(View):# @method_decorator(csrf_exempt)   # 第二种  def dispatch(self, request, *args, **kwargs):super().dispatch(request,*args,**kwargs)  其实都是给dispatch加