cbv装饰器中间件跨站请求伪造

给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):

    pass

  def 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):

    pass

  def post(self,request):

    pass

# 2，方法上面加,不要用原生的装饰器，用的话，只能改参数，那样的话不通用

class Home(View):

  @method_decorator(login_auth)

  def get(self,request):

    pass

  def 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 MiddlewareMixin

class MD1(MiddlewareMixin):

    def process_request(self, request):

        print("MD1里面的 process_request")

	def process_response(self, request, response):

        print("MD1里面的 process_response")

        return response

class MD2(MiddlewareMixin):

    def process_request(self, request):

        print("MD2里面的 process_request")

        pass

    def process_response(self, request, response):

        print("MD2里面的 process_response")

        return response

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

MIDDLEWARE = [

    'middlewares.MD1',  # 自定义中间件MD1

    'middlewares.MD2'  # 自定义中间件MD2

]

总结：

中间件的process_request方法是在执行视图函数之前执行的。
当配置多个中间件时，会按照MIDDLEWARE中的注册顺序，也就是列表的索引值，从前到后依次执行的。
不同中间件之间传递的request都是同一个对象
多个中间件中的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加