Django学习笔记10

中间件

中间件介绍

什么是中间件？

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

可是因为其影响的是全局，因此须要谨慎使用，使用不当会影响性能。

咱们一直都在使用中间件，只是没有注意到而已，打开Django项目的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',
]

　　MIDDLEWARE配置项是一个列表，列表中是一个个字符串，这些字符串实际上是一个个类，也就是一个个中间件。

咱们以前已经接触过一个csrf相关的中间件了？咱们一开始让你们把他注释掉，再提交post请求的时候，就不会被forbidden了，后来学会使用csrf_token以后就再也不注释这个中间件了。

自定义中间件

中间件能够定义五个方法，分别是：（主要的是process_request和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)

以上方法的返回值能够是None或一个HttpResponse对象，若是是None，则继续按照django定义的规则向后继续执行，若是是HttpResponse对象，则直接将该对象返回给用户。

自定义一个中间件示例（自定义以后要在MIDDLEWARE中注册才有用）

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

　　上面中间件的做用分别为在请求以前和请求以后在控制台打印一句话

process_request

process_request有一个参数，就是request，这个request和视图函数中的request是同样的。

它的返回值能够是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
    'middlewares.MD2'  # 自定义中间件MD2
]

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

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

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

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

　　看结果咱们知道：视图函数仍是最后执行的，MD2比MD1先执行本身的process_request方法。

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

由此总结一下：

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

process_response

执行顺序：
按照注册顺序的倒序（在settings.py里面设置中 从下到上的顺序）
什么时候执行：
请求有响应的时候
返回值：
必须返回一个response对象

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

　　终端的输出：

MD2里面的 process_request
MD1里面的 process_request
app01 中的 index视图
MD1里面的 process_response
MD2里面的 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方法并将应用到该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__)


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以后，视图函数以前执行的，执行顺序按照MIDDLEWARE中的注册顺序从前到后顺序执行的

process_exception

process_exception(self, request, exception)

该方法两个参数:

一个HttpRequest对象

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

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

执行顺序：
按照注册顺序的倒序（在settings.py里面设置中 从下到上的顺序）
什么时候执行：
视图函数中抛出异常的时候才执行
返回值：
返回None,继续执行后续中间件的process_exception
返回response

process_template_response（用的比较少）

process_template_response(self, request, response)
执行顺序：
按照注册顺序的倒序（在settings.py里面设置中 从下到上的顺序）
什么时候执行：
视图函数执行完，在执行视图函数返回的响应对象的render方法以前
返回值：
返回None,继续执行后续中间件的process_exception
返回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和process_exception两个方法的触发是有条件的，执行顺序也是倒序。总结全部的执行流程以下：

 

 

中间件版登陆验证 

中间件版的登陆验证须要依靠session，因此数据库中要有django_session表。

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

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

在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',
]

AuthMD中间件注册后，全部的请求都要走AuthMD的process_request方法。

访问的URL在白名单内或者session中有user用户名，则不作阻拦走正常流程；

若是URL在黑名单中，则返回This is an illegal URL的字符串；

正常的URL可是须要登陆后访问，让浏览器跳转到登陆页面。

注：AuthMD中间件中须要session，因此AuthMD注册的位置要在session中间的下方。

Django请求流程图

Django 的 CSRF 保护机制

• 每次初始化一个项目时都能看到 django.middleware.csrf.CsrfViewMiddleware 这个中间件
  • csrf是基于中间件实现的，那么是放在哪一个中间件里的呢？---放在_view中间件里
  • 为何放在_view里？缘由：由于CBV的csrf有个装饰器，启用或弃用csrf，可是_request只是得到视图函数，_view才是执行视图函数，这里才能判断出哪一个启用csrf，因此是放在_view里的
• 每次在模板里写 form 时都知道要加一个 {% csrf_token %} tag
• 每次发 ajax POST 请求，都须要加一个 X_CSRFTOKEN 的 header

什么是 CSRF 

CSRF, Cross Site Request Forgery, 跨站点伪造请求。

举例来说，当你看小姐姐照片的同时，登录了银行网站，而后你银行帐户尚未退出，这时，你又回去看小姐姐，点击了小姐姐的图片，可是，小姐姐的图片上有个连接，正好是一个post请求发给你登录的银行网页，请求的内容就是给小姐姐转帐，平时状况下，你没登录，转帐不可能成功（后天验证不经过），可是，你帐户是你本身登录的（有cookie了），连接是你本身点的，就这样，你的钱就到小姐姐那里去了。

正经一点的话就是：

别的某个恶意的网站上有一个指向你的网站的连接，若是某个用户已经登陆到你的网站上了，那么当这个用户点击这个恶意网站上的那个连接时，就会向你的网站发来一个请求，你的网站会觉得这个请求是用户本身发来的，其实呢，这个请求是那个恶意网站伪造的。

要完成一次CSRF攻击，受害者必须依次完成两个步骤：

　　1.登陆受信任网站A，并在本地生成Cookie。

　　2.在不登出A的状况下，访问危险网站B。

Django 提供的 CSRF 防御机制

django 第一次响应来自某个客户端的请求时，会在服务器端随机生成一个 token，把这个 token 放在 cookie 里。而后每次 POST 请求都会带上这个 token，这样就能避免被 CSRF 攻击。

简单的说就是在form表单里加个csrftoken 字段，由于攻击者不能得到第三方的Cookie(理论上)，也不知道服务器上生成的字段值，因此表单中的数据也就构造失败了

1. 在返回的 HTTP 响应的 cookie 里，django 会为你添加一个 csrftoken 字段，其值为一个自动生成的 token
2. 在全部的 POST 表单时，必须包含一个 csrfmiddlewaretoken 字段 （只须要在模板里加一个 tag， django 就会自动帮你生成，见下面）
3. 在处理 POST 请求以前，django 会验证这个请求的 cookie 里的 csrftoken 字段的值和提交的表单里的 csrfmiddlewaretoken 字段的值是否同样。若是同样，则代表这是一个合法的请求，不然，这个请求多是来自于别人的 csrf 攻击，返回 403 Forbidden.
4. 在全部 ajax POST 请求里，添加一个 X-CSRFTOKEN header，其值为 cookie 里的 csrftoken 的值

Django 里如何使用 CSRF 防御

• 首先，最基本的原则是：GET 请求不要用有反作用。也就是说任何处理 GET 请求的代码对资源的访问都必定要是“只读“的。
• 要启用 django.middleware.csrf.CsrfViewMiddleware 这个中间件
• 再次，在全部的 POST 表单元素时，须要加上一个 {% csrf_token %} tag
• 在渲染模块时，使用 RequestContext。RequestContext 会处理 csrf_token 这个 tag,  从而自动为表单添加一个名为 csrfmiddlewaretoken 的 input