11.Django basis of Nine middleware

A foreplay

　　In previous lessons we have learned to view itself plus decorator to determine whether the user is logged in, the user is not logged requests jump to the login page. We realized this need by giving a few specific functions plus view decorator. But after adding the view function you may also need to add a decorator, so is not it a little cumbersome.

　　After learning the contents of it today, we can use a more appropriate way to achieve similar functionality to all requests to do the same operation

Two middleware Introduction

　　Middleware name implies, is interposed between a processing request and response process, relatively lightweight, and changes in the input and output django globally. Because change is global, it is necessary to be cautious and practical, with good will affect the performance.

　　Django middleware definition:

Middleware is a framework of hooks into Django’s request/response processing. <br>It’s a light, low-level “plugin” system for globally altering Django’s input or output.

　　If you want to modify the request, for example, transferred to view the HttpRequest object. Or if you want to change the view to return HttpResponse objects, which can be achieved through the middleware.

　　You may also want to do something before the implementation of view, this situation can use middleware to achieve.

　　Said bluntly middleware can help us to do some additional work performed before and after view function is executed, it is essentially a custom class, a class defines several methods, Django framework will request specific time to implement these methods.

　　We have been using middleware, but did not notice it, open the Django project Settings.py file, see the following MIDDLEWARE configuration items, django default comes with a number of 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',
]

　　MIDDLEWARE configuration items is a list, the list is a string, the string is a fact, these classes, which is a mezzanine.

　　We have previously come into contact with a csrf the associated middleware? We started so that we commented to him, when the post before submitting the request, it will not be forbidden, and later learned after use csrf_token This middleware is no longer a comment.

　　Then we learn that method middleware and when these methods are executed.

Three custom middleware

Would like to know more about the middle of the open-source Chinese had a lot of middleware in a detailed explanation

　　Middleware can define five methods, namely :( main thing is process_request and process_response)

process_request(self,request)
process_view(self, request, view_func, view_args, view_kwargs)
process_template_response(self,request,response)
process_exception(self, request, exception)
process_response(self, request, response)

　　Return value None of the above method may be a HttpResponse object or, if is None, then proceed back to continue according to the rules defined django, if HttpResponse object, the object is returned directly to the user.

　　When the user initiated the request will sequentially go through all the intermediate, process_request request this time, and finally to function views, the rear views of a function, sequentially passing through the intermediate, this time is process_response, and finally returned to the requester By.

　　Above screenshot django middleware are in, we can also define your own middleware, we can write a class, but must inherit MiddlewareMixin

Example of a custom middleware

　　　　table of Contents:

　　　　　　Creating a package in the project, just from the name, they are generally placed inside called utils package, represent a common component that creates a py file, just from the name, for example, is called: middlewares.py, reads as follows

from django.utils.deprecation import MiddlewareMixin

class MD1(MiddlewareMixin):
    #自定义中间件，不是必须要有下面这两个方法，有request方法说明请求来了要处理，有response方法说明响应出去时需要处理，不是非要写这两个方法，如果你没写process_response方法，那么会一层一层的往上找，哪个中间件有process_response方法就将返回对象给哪个中间件
    def process_request(self, request):
        print("MD1里面的 process_request")

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

process_request

　　　　　　process_request has one parameter, the request, the request and view function in the request is the same.

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

　　　　　　我们来看看多个中间件时，Django是如何执行其中的process_request方法的。

from django.utils.deprecation import MiddlewareMixin


class MD1(MiddlewareMixin):

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


class MD2(MiddlewareMixin):
    def process_request(self, request):
        print("MD2里面的 process_request")
        pass

　　　　　　在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',
    'middlewares.MD1',  # 自定义中间件MD1，这个写的是你项目路径下的一个路径，例如，如果你放在项目下，文件夹名成为utils，那么这里应该写utils.middlewares.MD1
    'middlewares.MD2'  # 自定义中间件MD2
]

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

MD1里面的 process_request
MD2里面的 process_requestapp01 中的 index视图

　　　　　　把MD1和MD2的位置调换一下，再访问一个视图，会发现终端中打印的内容如下：

MD2里面的 process_request
MD1里面的 process_requestapp01 中的 index视图

　　　　　　看结果我们知道：视图函数还是最后执行的，MD2比MD1先执行自己的process_request方法。

　　　　　　在打印一下两个自定义中间件中process_request方法中的request参数，会发现它们是同一个对象。

　　　　　　由此总结一下：

　　　　　　　　中间件的process_request方法是在执行视图函数之前执行的。

　　　　　　　　当配置多个中间件时，会按照MIDDLEWARE中的注册顺序，也就是列表的索引值，从前到后依次执行的。

　　　　　　　　不同中间件之间传递的request都是同一个对象

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

process_response

　　　　　　它有两个参数，一个是request，一个是response，request就是上述例子中一样的对象，response是视图函数返回的HttpResponse对象。该方法的返回值也必须是HttpResponse对象。

　　　　　　给上述的M1和M2加上process_response方法：

from django.utils.deprecation import MiddlewareMixin


class MD1(MiddlewareMixin):

    def process_request(self, request):
        print("MD1里面的 process_request")
        #不必须写return值
    def process_response(self, request, response):#request和response两个参数必须有，名字随便取
        print("MD1里面的 process_response")        #print(response.__dict__['_container'][0].decode('utf-8')) #查看响应体里面的内容的方法，或者直接使用response.content也可以看到响应体里面的内容，由于response是个变量，直接点击看源码是看不到的，你打印type(response)发现是HttpResponse对象，查看这个对象的源码就知道有什么方法可以用了。
　　　　 return response  #必须有返回值，写return response  ，这个response就像一个接力棒一样
        #return HttpResponse('瞎搞') ,如果你写了这个，那么你视图返回过来的内容就被它给替代了

class MD2(MiddlewareMixin):
    def process_request(self, request):
        print("MD2里面的 process_request")
        pass

    def process_response(self, request, response): #request和response两个参数必须要有，名字随便取
        print("MD2里面的 process_response") 
        return response  #必须返回response，不然你上层的中间件就没有拿到httpresponse对象，就会报错

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

MD2里面的 process_request
MD1里面的 process_request
app01 中的 index视图
MD1里面的 process_response
MD2里面的 process_response

　　　　　　看结果可知：

　　　　　　process_response方法是在视图函数之后执行的，并且顺序是MD1比MD2先执行。(此时settings.py中 MD2比MD1先注册)

　　　　　　再看一个例子：

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

class Md1(MiddlewareMixin):

    def process_request(self,request):
        print("Md1请求")　　　　 #process_request方法里面不写返回值，默认也是返回None，如果你自己写了return None，也是一样的效果，不会中断你的请求，但是如果你return 的一个httpresponse对象，那么就会在这个方法中断你的请求，直接返回给用户，这就成了非正常的流程了        #并且，如果你在这里return了httpresponse对象，那么会从你这个中间件类中的process_response方法开始执行返回操作，所以这个类里面只要有process_response方法，肯定会执行
 
    def process_response(self,request,response):
        print("Md1返回")
        return response

class Md2(MiddlewareMixin):

    def process_request(self,request):
        print("Md2请求")
        #return HttpResponse("Md2中断")
    def process_response(self,request,response):
        print("Md2返回")
        return response

　　　　结果：

Md1请求
Md2请求
view函数...
Md2返回
Md1返回

　　　　注意：如果当请求到达请求2的时候直接不符合条件返回，即return HttpResponse("Md2中断")，程序将把请求直接发给中间件2返回，然后依次返回到请求者，结果如下：

　　　　返回Md2中断的页面，后台打印如下：

Md1请求
Md2请求
Md2返回
Md1返回

　　　　流程图如下：

　　　　之前我们做的cookie认证，都是通过在函数上面加装饰器搞的，比较麻烦，看看中间件怎么搞，如果写的是session认证的，你必须放在django自带的session中间件的下面，所以自定义中间之后，你需要注意你的中间件的摆放顺序。

class M1(MiddlewareMixin):

    def process_request(self,request):

        #设置路径白名单，只要访问的是login登陆路径，就不做这个cookie认证
        if request.path not in [reverse('login'),]:
            print('我是M1中间件') #客户端IP地址
            # return HttpResponse('sorry,没有通过我的M1中间件')
            is_login = request.COOKIES.get('is_login', False)

            if is_login:
                pass
            else:
                # return render(request,'login.html')
                return redirect(reverse('login'))
        else:
            return None #别忘了return None，或者直接写个pass

    def process_response(self,request,response):

        print('M1响应部分')
        # print(response.__dict__['_container'][0].decode('utf-8'))
        return response
        # return HttpResponse('瞎搞')

　　　　　　练习：尝试一下通过中间件来控制用户的访问次数，让用户在一分钟之内不能访问我的网站超过20次。

　　　　后面要学的方法不常用，但是大家最好也要知道。

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方法并将应用到该HttpResponse并返回结果。

　　　　　　给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__) #就是url映射到的那个视图函数，也就是说每个中间件的这个process_view已经提前拿到了要执行的那个视图函数        #ret = view_func(request) #提前执行视图函数，不用到了上图的试图函数的位置再执行，如果你视图函数有参数的话，可以这么写 view_func(request,view_args,view_kwargs) 
        #return ret  #直接就在MD1中间件这里这个类的process_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

    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方法是在process_request之后，reprocess_response之前，视图函数之前执行的，执行顺序按照MIDDLEWARE中的注册顺序从前到后顺序执行的

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方法直接返回了一个响应对象。

process_template_response（用的比较少）

　　　　　　process_template_response(self, request, response)

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

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

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

    def process_template_response(self, request, response):
        print("MD1 中的process_template_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

    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")

    def process_template_response(self, request, response):
        print("MD2 中的process_template_response")
        return response

　　　　　　views.py中：

def index(request):
    print("app01 中的 index视图")
　　#raise ValueError('出错啦') 
    def render():
        print("in index/render")          #raise ValueError('出错啦') #至于render函数中报错了，那么会先执行process_template_response方法，然后执行process_exception方法，如果是在render方法外面报错了，那么就不会执行这个process_template_response方法了。
        return HttpResponse("O98K") #返回的将是这个新的对象
    rep = HttpResponse("OK")
    rep.render = render
    return rep

　　　　　　访问index视图，终端输出的结果：

MD2里面的 process_request
MD1里面的 process_request
--------------------------------------------------------------------------------
MD2 中的process_view
<function index at 0x000001C111B97488> index
--------------------------------------------------------------------------------
MD1 中的process_view
<function index at 0x000001C111B97488> index
app01 中的 index视图
MD2 中的process_template_response
MD1 中的process_template_response
in index/render
MD1里面的 process_response
MD2里面的 process_response

　　　　　　从结果看出：

　　　　　　视图函数执行完之后，立即执行了中间件的process_template_response方法，顺序是倒序，先执行MD2的，在执行MD1的，接着执行了视图函数返回的HttpResponse对象的render方法，返回了一个新的HttpResponse对象，接着执行中间件的process_response方法。

四中间件执行流程

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

　　请求到达中间件之后，先按照正序执行每个注册中间件的process_reques方法，process_request方法返回的值是None，就依次执行，如果返回的值是HttpResponse对象，不再执行后面的process_request方法，而是执行当前对应中间件的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 and triggered two methods process_exception is conditional execution order is the reverse order. All summary execution process is as follows:

Five middleware version login authentication

Middleware version of the login authentication need to rely on session, so there must be django_session database table.

　　　　urls.py

from django.conf.urls import url
from app01 import views

urlpatterns = [
    url(r'^index/$', views.index),
    url(r'^login/$', views.login, name='login'),
]

　　　　views.py

from django.shortcuts import render, HttpResponse, redirect


def index(request):
    return HttpResponse('this is index')


def home(request):
    return HttpResponse('this is home')


def login(request):
    if request.method == "POST":
        user = request.POST.get("user")
        pwd = request.POST.get("pwd")

        if user == "Q1mi" and pwd == "123456":
            # 设置session
            request.session["user"] = user
            # 获取跳到登陆页面之前的URL
            next_url = request.GET.get("next")
            # 如果有，就跳转回登陆之前的URL
            if next_url:
                return redirect(next_url)
            # 否则默认跳转到index页面
            else:
                return redirect("/index/")
    return render(request, "login.html")

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="x-ua-compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>登录页面</title>
</head>
<body>
<form action="{% url 'login' %}">
    <p>
        <label for="user">用户名：</label>
        <input type="text" name="user" id="user">
    </p>
    <p>
        <label for="pwd">密 码：</label>
        <input type="text" name="pwd" id="pwd">
    </p>
    <input type="submit" value="登录">
</form>
</body>
</html>

　　　　middlewares.py

class AuthMD(MiddlewareMixin):
    white_list = ['/login/', ]  # 白名单
    balck_list = ['/black/', ]  # 黑名单

    def process_request(self, request):
        from django.shortcuts import redirect, HttpResponse

        next_url = request.path_info
        print(request.path_info, request.get_full_path())

        if next_url in self.white_list or request.session.get("user"):
            return
        elif next_url in self.balck_list:
            return HttpResponse('This is an illegal URL')
        else:
            return redirect("/login/?next={}".format(next_url))

　　　　Registered in the 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',
    'middlewares.AuthMD',
]

　　　　After AuthMD middleware registration, all requests must go process_request method of AuthMD.

　　　　URL access in the whitelist or user session has a user name, then do not do block the normal flow away;

　　　　If the URL in the blacklist, string This is an illegal URL is returned;

　　　　But after a normal URL need to log in to access, let the browser to jump to the login page.

　　　　Note: AuthMD middleware need to session, so AuthMD position to be registered under the middle of the session.

　　　　Annex: Django flowchart request

Six middleware Case

Applications

1, do IP access frequency limit

　　　　　　High frequency of certain IP access server, to intercept, such restrictions can not be more than 20 times per minute.

2, URL filtering access

　　　　　　If a user visits a login view (let go)

　　　　　　If you access other views, needs testing is not a session authentication, has been released, did not return to login, so you write decorators save multiple views on the function!

Source probation

　　　　As an extension of extended content, there is spare capacity of students can try to read the following two built-in middleware:

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