Django框架之 中间件

一、中间件介绍

官方的说法：中间件是一个用来处理Django的请求和响应的框架级别的钩子。它是一个轻量、低级别的插件系统，用于在全局范围内改变Django的输入和输出。每个中间件组件都负责做一些特定的功能。

但是由于其影响的是全局，所以需要谨慎使用，使用不当会影响性能。

中间件位于web服务端与url路由层之间

说的直白一点中间件是帮助我们在视图函数执行之前和执行之后都可以做一些额外的操作，它本质上就是一个自定义类，类中定义了几个方法，Django框架会在请求的特定的时间去执行这些方法。

我们一直都在使用中间件，只是没有注意到而已，打开Django项目的Settings.py文件，看到下图的MIDDLEWARE配置项，每一个配置项都对应着一个中间件。

请求来的时候，是自上而下一个个中间件执行，在走到urls中

响应走的时候，是自下而上一个个中间件执行

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

# 实际上每一个中间件都对应一个类  
# 例如：
from django.middleware.security import SecurityMiddleware
...

中间件在框架中帮我们做了很多重要的操作，比如Session的中间件，就帮我们把添加的session值进行加密和生成随机字符串给cookie，发送到浏览器上。当数据来的时候，又要先通过校验帮我们解密等等。。。

二、自定义中间件

说了这么多，中间件的牛逼之处就不多说了。那我们如何自定义中间件呢。实际上在django框架中我们可以自定义实现中间件，主要实现其中的五个方法。（主要的是process_request和process_response）

• process_request(self,request)，

  扫描二维码关注公众号，回复： 7692075 查看本文章

  请求来的时候触发
  
  会从上往下依次经过每一个中间件里面process_request,一旦里面返回了HttpResponse对象那么就不再往后执行了 会执行同一级别的process_response

• process_view(self, request, view_func, view_args, view_kwargs)

  路由匹配成功之后执行视图函数之前触发

• process_template_response(self,request,response)

  当视图函数执行完毕之后并且返回的对象中含有render方法的情况下才会触发

• process_exception(self, request, exception)

  当视图函数出现异常(bug)的时候自动触发

• process_response(self, request, response)

  响应走的时候触发,
  
  会从下往上依次进过每一个中间件里面的process_response

实现

1. 先在任意位置创建一个文件，自定义一个类，并添加至middleware列表中。

   

2. 在自定义类中，实现五个方法中你需要的任意方法

   

2.1 process_request

process_request有一个参数，就是request，这个request和视图函数中的request是一样的(在交给Django后面的路由之前，对这个request对象可以进行一系列的操作)。

由于request对象是一样的，所以我们可以对request对象进行一系列的操作，包括request.变量名=变量值,这样的操作，我们可以在后续的视图函数中通过相同的方式即可获取到我们在中间件中设置的值。

它的返回值可以是None也可以是HttpResponse对象。返回值是None的话，按正常流程继续走，交给下一个中间件处理，如果是HttpResponse对象，Django将不执行视图函数，而将相应对象返回给浏览器。

from django.utils.deprecation import MiddlewareMixin
class MyMiddle_1(MiddlewareMixin):
    def process_request(self,request):
        print(request)
        print("我是自定义中间件 MyMiddle_1的process_request")

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

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'app01.MyMiddleware.middleware_test.MyMiddle_1',    # 自定义中间件
]

此时，我们访问一个视图，会发现终端中打印如下内容：

我是自定义中间件 MyMiddle_1的process_request

总结：

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

2.2 process_response

多个中间件中的process_response方法是按照MIDDLEWARE中的注册顺序倒序执行的，也就是说第一个中间件的process_request方法首先执行，而它的process_response方法最后执行，最后一个中间件的process_request方法最后一个执行，它的process_response方法是最先执行。

定义process_response方法时，必须给方法传入两个形参，request和response。request就是上述例子中一样的对象，response是视图函数返回的HttpResponse对象(也就是说这是Django后台处理完之后给出一个的一个具体的视图)。该方法的返回值(必须要有返回值)也必须是HttpResponse对象。如果不返回response而返回其他对象，则浏览器不会拿到Django后台给他的视图，而是我的中间件中返回的对象

from django.utils.deprecation import MiddlewareMixin
class MyMiddle_1(MiddlewareMixin):
    def process_request(self,request):
        print(request)
        print("我是自定义中间件 MyMiddle_1的process_request")

    def process_response(self,request, response):
        print("我是自定义中间件 MyMiddle_1的process_response")
        return response # 必须返回，否则报错

访问一个视图，看一下终端的输出：

我是自定义中间件 MyMiddle_1的process_request
我是自定义中间件 MyMiddle_1的process_response

总结：

1. 多个中间件中的process_response方法是按照MIDDLEWARE中的注册顺序倒序执行的
2. 如果同一个中间件中的process_request方法直接返回了，那么会接着执行同一个中间件中的process_response方法

2.3 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方法，最后返回给浏览器

给MD1和MD2添加process_view方法:

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

    def process_view(self, request, view_func, view_args, view_kwargs):
        print("-" * 80)
        print("MD1 中的process_view")
        print(view_func, view_func.__name__)


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

    def process_view(self, request, view_func, view_args, view_kwargs):
        print("-" * 80)
        print("MD2 中的process_view")
        print(view_func, view_func.__name__)

访问index视图函数，看一下输出结果：

MD2里面的 process_request
MD1里面的 process_request
--------------------------------------------------------------------------------
MD2 中的process_view
<function index at 0x000001DE68317488> index
--------------------------------------------------------------------------------
MD1 中的process_view
<function index at 0x000001DE68317488> index
app01 中的 index视图
MD1里面的 process_response
MD2里面的 process_response

process_view方法是在Django路由系统之后，视图系统之前执行的，执行顺序按照MIDDLEWARE中的注册顺序从前到后顺序执行的

2.4 process_exception

process_exception(self, request, exception)

该方法两个参数:

一个HttpRequest对象

一个exception是视图函数异常产生的Exception对象。

这个方法只有在视图函数中出现异常了才执行，它返回的值可以是一个None也可以是一个HttpResponse对象。如果是HttpResponse对象，Django将调用模板和中间件中的process_response方法，并返回给浏览器，否则将默认处理异常。如果返回一个None，则交给下一个中间件的process_exception方法来处理异常。它的执行顺序也是按照中间件注册顺序的倒序执行。

给MD1和MD2添加上这个方法：

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

    def process_view(self, request, view_func, view_args, view_kwargs):
        print("-" * 80)
        print("MD1 中的process_view")
        print(view_func, view_func.__name__)

    def process_exception(self, request, exception):
        print(exception)
        print("MD1 中的process_exception")


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

    def process_view(self, request, view_func, view_args, view_kwargs):
        print("-" * 80)
        print("MD2 中的process_view")
        print(view_func, view_func.__name__)

    def process_exception(self, request, exception):
        print(exception)
        print("MD2 中的process_exception")

如果视图函数中无异常，process_exception方法不执行。

想办法，在视图函数中抛出一个异常：

def index(request):
    print("app01 中的 index视图")
    raise ValueError("呵呵")
    return HttpResponse("O98K")

在MD1的process_exception中返回一个响应对象：

class MD1(MiddlewareMixin):

    def process_request(self, request):
        print("MD1里面的 process_request")

    def process_response(self, request, response):
        print("MD1里面的 process_response")
        return response

    def process_view(self, request, view_func, view_args, view_kwargs):
        print("-" * 80)
        print("MD1 中的process_view")
        print(view_func, view_func.__name__)

    def process_exception(self, request, exception):
        print(exception)
        print("MD1 中的process_exception")
        return HttpResponse(str(exception))  # 返回一个响应对象

看输出结果：

MD2里面的 process_request
MD1里面的 process_request
--------------------------------------------------------------------------------
MD2 中的process_view
<function index at 0x0000022C09727488> index
--------------------------------------------------------------------------------
MD1 中的process_view
<function index at 0x0000022C09727488> index
app01 中的 index视图
呵呵
MD1 中的process_exception
MD1里面的 process_response
MD2里面的 process_response

注意，这里并没有执行MD2的process_exception方法，因为MD1中的process_exception方法直接返回了一个响应对象。

2.5 process_template_response（用的比较少）

process_template_response(self, request, response)

它的参数，一个HttpRequest对象，response是TemplateResponse对象（由视图函数或者中间件产生）。

process_template_response是在视图函数执行完成后立即执行，但是它有一个前提条件，那就是视图函数返回的对象有一个render()方法（或者表明该对象是一个TemplateResponse对象或等价方法）。

三、中间件的执行流程

上一部分，我们了解了中间件中的5个方法，它们的参数、返回值以及什么时候执行，现在总结一下中间件的执行流程。

请求到达中间件之后，先按照正序执行每个注册中间件的process_request方法，process_request方法返回的值是None，就依次执行，如果返回的值是HttpResponse对象，不再执行后面的process_request方法，而是执行当前对应中间件的process_response方法(注意不是掉头执行所有的process_response方法)，将HttpResponse对象返回给浏览器。也就是说：如果MIDDLEWARE中注册了6个中间件，执行过程中，第3个中间件返回了一个HttpResponse对象，那么第4,5,6中间件的process_request和process_response方法都不执行，顺序执行3,2,1中间件的process_response方法。

process_request方法都执行完后，匹配路由，找到要执行的视图函数，先不执行视图函数，先执行中间件中的process_view方法，process_view方法返回None，继续按顺序执行，所有process_view方法执行完后执行视图函数。假如中间件3 的process_view方法返回了HttpResponse对象，则4,5,6的process_view以及视图函数都不执行，直接从最后一个中间件，也就是中间件6的process_response方法开始倒序执行。

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

四、中间件的应用场景

1、做IP访问频率限制

某些IP访问服务器的频率过高，进行拦截，比如限制每分钟不能超过20次。

2、URL访问过滤

如果用户访问的是login视图（放过）

如果访问其他视图，需要检测是不是有session认证，已经有了放行，没有返回login，这样就省得在多个视图函数上写装饰器了！

作为延伸扩展内容，有余力的同学可以尝试着读一下以下两个自带的中间件：

'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',

4.1 中间件版登录验证

中间件版的登录验证需要依靠session，所以数据库中要有django_session表。

urls.py

from app02 import views as v2
urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^login/',v2.login),
    url(r'^home/',v2.home),
    url(r'^index/',v2.index)
]

views.py

from django.shortcuts import render,redirect,HttpResponse
from app02 import models
# Create your views here.
def login(request):
    error_msg=''
    if request.method=='POST':
        username=request.POST.get('username')
        password=request.POST.get('password')
        user_obj=models.User.objects.filter(username=username,password=password)
        if  user_obj:
            #设置session
            request.session['login']='ok'
            #获取用户想直接访问的URL
            url=request.GET.get('next')
            #如果有，就跳转到客户初始想访问的URL
            if not url:
                #没有则默认跳转到home页面
                url='/home/'
            return redirect(url)
        else:
            error_msg='username or password error!'
    return render(request,'login.html',{'error_msg':error_msg})

def home(request):
    return HttpResponse('<h1>这是home页面 只有登录了才能看到</h1>')

def index(request):
    return HttpResponse('<h1>这是index页面 也只有登录了才能看到<h1>')

login.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>登陆页面</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<form action="" method="post">
    {% csrf_token %}
    <label for="">username:<input type="text" name="username"></label>
    <label for="">password:<input type="password" name="password"></label>
    <input type="submit" value="submit">
</form>
<h1 style="color: red">{{ error_msg }}</h1>

</body>
</html>

middlewares.py

from django.utils.deprecation import MiddlewareMixin
from django.shortcuts import redirect

class Check_Login(MiddlewareMixin):
    def process_request(self,request):
        next_url=request.path_info
        if not next_url.startswith('/login/'):
            is_login=request.session.get('login','')
            if not is_login:
                return redirect('/login/?next={}'.format(next_url))

在settings.py中注册

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'middleware.my_middleware.Check_Login',
]

五 CSRF_TOKEN跨站请求伪造

5.1 什么是csrf

SRF（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网站的合法用户

5.2 csrf攻击原理

目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证

最简单的原理：

你写的form表单中 用户的用户名 密码都会真实的提交给银行后台，但是收款人的账户却不是用户填的 你暴露给用户的是一个没有name属性的input框，你自己提前写好了一个隐藏的带有name和value的input框

5.3 解决

只要是用户想要提交post请求的页面 我在返回给用户的时候就提前设置好一个随机字符串，当用户提交post请求的时候 我会自动先取查找是否有该随机字符串 ，如果有 正常提交，如果没有 直接报403 。

在django中，已经有csrf中间件来帮你解决这个问题。

使用方法：

• form表单：

  你在form表单的时候，你只需要在其中加上一个{% csrf_token %}即可

• ajax：

  第一种: 自己再页面上先通过{% csrf_token %}获取到随机字符串  然后利用标签查找 
    data：{'username':'jason','csrfmiddlewaretoken':$('[name="csrfmiddlewaretoken"]').val()},
  第二种: 在data 要发送的数据中通过模板语法 {{ csrf_token }}
      data:{'username':'jason','csrfmiddlewaretoken':'{{ csrf_token }}'},
  第三种: 拷贝js文件
      下面的js直接拷贝即可
  

  csrf_token的JS代码

  function getCookie(name) {
      var cookieValue = null;
      if (document.cookie && document.cookie !== '') {
          var cookies = document.cookie.split(';');
          for (var i = 0; i < cookies.length; i++) {
              var cookie = jQuery.trim(cookies[i]);
              // Does this cookie string begin with the name we want?
              if (cookie.substring(0, name.length + 1) === (name + '=')) {
                  cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                  break;
              }
          }
      }
      return cookieValue;
  }
  var csrftoken = getCookie('csrftoken');
  
  
  
  function csrfSafeMethod(method) {
    // these HTTP methods do not require CSRF protection
    return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
  }
  
  $.ajaxSetup({
    beforeSend: function (xhr, settings) {
      if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
        xhr.setRequestHeader("X-CSRFToken", csrftoken);
      }
    }
  });
  

5.4 csrf装饰器

只对个别网站进行csrf 忽略（csrf_exempt）或限制（csrf_protect）,可以使用装饰器

• csrf_exempt：忽略csrf校验的装饰器，被装饰的视图函数不用csrf校验
• csrf_protect：校验csrf的装饰器，被装饰的视图函数需要csrf校验

FBV实现方式

# 只对个别网站进行csrf 忽略（csrf_exempt）或限制（csrf_protect）
from django.views.decorators.csrf import csrf_exempt, csrf_protect
# @csrf_exempt    # 忽略csrf校验
@csrf_protect   # 添加csrf校验
def csrf(request):
    return render(request,"csrf.html")

CBV实现方式

'''csrf_exempt''' 

# 第一种
@method_decorator(csrf_exempt,name='dispatch')
class CBV_csrf(View):   #  CBV
    '''第二种,直接放在dispatch上'''
    @method_decorator(csrf_exempt)
    def dispatch(self, request, *args, **kwargs):
        return super().dispatch(request, *args, **kwargs)
    def post(self,request):
        return HttpResponse('hahaha')
    
    
'''csrf_protect'''

# 第一种
@method_decorator(csrf_protect,name='post')
class CBV_csrf(View):
    # 第二种
    @method_decorator(csrf_protect)
    def dispatch(self, request, *args, **kwargs):
        return super().dispatch(request,*args,**kwargs)
    def get(self,request):
        return HttpResponse('hahaha')
    # 第三种
    @method_decorator(csrf_protect)
    def post(self,request):
        return HttpResponse('post')

附：Django请求流程图