Django---Django的中间件

一丶中间件介绍

什么是中间件

官方的说法：中间件是一个用来处理Django的请求和响应的框架级别的钩子。它是一个轻量、低级别的插件系统，用于在全局范围内改变Django的输入和输出。每个中间件组件都负责做一些特定的功能。 但是由于其影响的是全局，所以需要谨慎使用，使用不当会影响性能。 #中间件是:在视图函数执行之前和执行之后都可以做一些额外的操作，它本质上就是一个自定义类，类中定义了几个方法，Django框架会在处理请求的特定的时间去执行这些方法。 # 打开Django项目的Settings.py文件，看到下图的MIDDLEWARE配置项。 MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', # 全局session 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ] # MIDDLEWARE配置项是一个列表，列表中是一个个字符串，这些字符串其实是一个个类，也就是一个个中间件。

二丶自定义中间件

中间件可以定义五个方法，分别是：（主要的是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对象，则直接将该对象返回给用户。

自定义一个中间件示例

# 实现中间件的类 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 # 必须返回response # settings配置注册中间件 'app01.middleware.MD1',

process_request(self,request):

def process_request(self, request): ''' 正常流程: 返回值必须为none ,按照 settings配置的中间件的顺序从上到下执行, # 若返回 HTTPResponse对象,则直接通过当前中间件的 process_response返回. # 在路由(urls.py)和函数(view)之前进行处理 :param request: :return: ''' print('In M1 process_request ') # 执行时间： 在执行视图函数之前,也在路由匹配之前 # 参数： request： 请求对象 和视图是同一个 # 执行的顺序： 按照中间件的注册顺序 顺序执行 # 返回值： None ： 正常流程 HttpResponse：当前中间件之后的中间件的process_request、路由匹配、视图函数都不执行，直接执行当前中间的process_response的方法，倒序执行之前的process_response的方法，最终返回给浏览器

process_response(self, request, response):

def process_response(self, request, response): ''' 正常流程: 必须返回response, 按照settings配置中的中间件顺序,倒序返回. # 可以自己指定返回的HttpResponse对象 # request 在一次请求中 ,始终是同一个 # 在路由(urls.py)和函数(view)之后进行处理 :param request: :param response: :return: ''' print('out M1 process_response ') return response # 必须返回 # 执行时间： 在执行视图函数之后 # 参数： request： 请求对象 和视图是同一个 response: 返回的response对象 # 执行的顺序： 按照中间件的注册顺序 倒序执行 # 返回值： HttpResponse：必须返回response对象

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

def process_view(self, reques, view_func, view_args, view_kwargs): ''' # 正常流程: 返回none ,按照 settings配置的中间件的顺序从上到下执行, # 可以修改函数的参数,或者修改函数返回的HttpResponse # M1 process_view 处理完, 交给 M2 process_view处理. 处理完毕后执行 真正要处理的视图函数(view_func函数) # 在 路由之后,函数之前进行处理 :param reques: :param view_func: :param view_args: :param view_kwargs: :return: ''' print('in M1 process_view ') print(view_func, view_args, view_kwargs) # 执行时间： 在执行视图函数之前，在路由匹配之后 # 参数： request： 请求对象 和视图是同一个 view_func： 视图函数 view_args： 传递给视图函数的位置参数 分组的参数 view_kwargs： 传递给视图函数的关键字参数 命名分组的参数 # 执行的顺序： 按照中间件的注册顺序 顺序执行 # 返回值： None : 正常流程 HttpResponse：当前中间件之后的中间件的process_view、视图函数都不执行，直接执行最后一个中间的process_response的方法，倒序执行之前的process_response的方法，最终返回给浏览器

process_exception(self, request, exception):

def process_exception(self, request, execption): ''' # 使用process_exception 方法 , 条件必须是 出现异常错误 # 执行顺序: 按照settings设置中间件的顺序 ,倒序执行. 如果 最后一个中间件的 process_exception 不能处理,交给 上一个中间件的process_exception处理 如果 都不能处理这个异常,则交给Django默认的配置处理. 最后有Django生成一个HttpResponse对象 # 由settings配置的最后一个中间件 process_response方法 逐层返回. :param request: :param execption: :return: ''' print('in M1 process_exception') print(execption) # 打印异常信息 # 执行时间（触发条件）： 视图层面有异常才执行 # 参数： request： 请求对象 和视图是同一个 exception： 错误对象 # 执行的顺序： 按照中间件的注册顺序 倒序执行 # 返回值： None : 交给下一个中间件处理异常，所有的中间件都没有处理，交给django处理 HttpResponse：当前中间件之前的中间件的process_exception不执行，直接执行最后一个中间的process_response的方法，倒序执行之前的process_response的方法，最终返回给浏览器

process_template_response(self,request,response):

def process_template_response(self, request, response): ''' # 执行顺序: 按照settings设置中间件的顺序 ,倒序执行. # response得到是一个TemplateResponse对象 # 可以修改属性和值 # 存在视图函数之后, 按照倒序执行完毕后,才进行最终的渲染. 然后交由 settings最后中间件 执行 process_response逐层返回 :param request: :param response: :return: ''' print(response, type(response), '这是TemplateResponse对象') # <TemplateResponse status_code=200, "text/html; charset=utf-8"> # <class 'django.template.response.TemplateResponse'> 这是TemplateResponse对象 # 可以通过 response 获取模板文件的名字, 或者修改传递的参数 # print(response.__dict__) # 查看都有什么属性 print(response.template_name) # 获得模版的名字 print(response.context_data) # 获得传递需要渲染的参数 # 修改 模版文件 response.template_name = 'logout.html' print('in M1 process_template_response ') return response # 必须返回response # 执行时间（触发条件）： 视图返回的response 是一个template_response对象 # 参数： request： 请求对象 和视图是同一个 response： 响应对象 # 执行的顺序： 按照中间件的注册顺序 倒序执行 # 返回值： HttpResponse：必须返回

三丶执行中间件的流程

# 请求到达中间件之后，先按照正序执行每个注册中间件的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两个方法的触发是有条件的，执行顺序也是倒序。总结所有的执行流程如下

附：Django请求流程图

帮主博客

转载于:https://www.cnblogs.com/dengl/p/11479658.html