Req/Res循环和Django中间件。

Django的中间件以及Request/Response循环

Django的中间件以及Request/Response循环

前言:萌新的疑问

在建立一个新的Django项目时,你要做的第一件事就是连接你的URLconf并设置一些视图。 但是这里真的发生了什么? Django如何将流量路由到视图,中间件在这个周期中扮演什么角色? 我以前眼中的Django:

image

WSGI

WSGI是为解决一个基本问题而创建的工具:将Web服务器连接到Web框架。 WSGI有两个方面:'服务器'方面和'应用程序'方面。 为了处理WSGI响应,服务器执行应用程序,并向应用程序端提供回调函数。 应用程序处理请求并使用提供的回调将响应返回给服务器。 本质上,WSGI处理程序充当您的Web服务器(Apache,NGINX等)和您的Django项目之间的守门员。

服务器和应用程序之间是中间件。 您可以将中间件视为一系列双向过滤器:它们可以改变(或短路)在网络和Django应用程序之间来回传输的数据。

整个Django的执行过程:数据流

当用户请求你的应用程序时,WSGI处理程序被实例化,然后Django按照顺序处理以下环节: 1. 导入你的settings.py文件和Django的异常类。 2. 加载它在位于settings.py中的MIDDLEWARE_CLASSES或者。MIDDLEWARES(取决于Django版本)元组中找到的所有中间件类。 3. 构建处理 requestview, responseexception的四个方法列表。 4. 通过请求方法循环,按顺序运行它们。 5. 解决了所请求的URL。 6. 循环每个视图处理方法。 7. 调用视图函数(通常是渲染模板)。 8. 处理任何异常方法。 9. 循环遍历每个响应方法(从内向外,从请求中间件的相反顺序)。 10. 最后建立一个返回值并调用web服务器的回调函数。

中间件

中间件被用在Django项目中的许多关键功能中:例如,使用CSRF中间件来防止跨站请求伪造攻击。 他们用来处理会话数据。 身份验证和授权是使用中间件完成的。 您可以编写自己的中间件类来通过应用程序调整(或短路)数据流。

image

process_request

Django中间件必须至少包含以下方法之一:process_requestprocess_responseprocess_viewprocess_exception。 这些是由WSGI处理程序收集的方法,然后按列出的顺序调用。 让我们快速浏览django.contrib.auth.middleware.AuthenticationMiddleware,这是运行django-admin.py startproject时默认安装的中间件之一:

```python

def get_user(request): if not hasattr(request, '_cached_user'): request._cached_user = auth.get_user(request) return request._cached_user

class AuthenticationMiddleware(MiddlewareMixin): def process_request(self, request): assert hasattr(request, 'session'), ( "The Django authentication middleware requires session middleware " "to be installed. Edit your MIDDLEWARE%s setting to insert " "'django.contrib.sessions.middleware.SessionMiddleware' before " "'django.contrib.auth.middleware.AuthenticationMiddleware'." ) % ("_CLASSES" if settings.MIDDLEWARE is None else "") request.user = SimpleLazyObject(lambda: get_user(request))

```

正如你所看到的,这个中间件只能处理来自Django应用程序的数据流的“请求”步骤。 该中间件首先验证会话中间件是否已经被使用,然后通过调用get_user帮助函数来设置用户。 当WSGI处理程序迭代process_request方法列表时,它会构建这个请求对象,最终将被传递到视图中,并且您将能够引用request.user。 settings.py中有一些中间件没有有process_request方法。 不过没关系,在这个阶段刚刚被跳过。

process_request应该返回None(如本例),或者可以返回一个HttpResponse对象。 在前一种情况下,WSGI处理程序将继续处理process_request方法,后者将“短路”进程并开始process_response循环。【如上图所示,跳过view过程,直接去response】

Resolve the URL(解析URL)

现在process_request方法已经被调用了,现在我们有一个请求对象将被传递给视图。在此之前,Django必须解析URL并确定调用哪个视图函数。这只是通过正则表达式匹配来完成的。您的settings.py将会有一个名为ROOT_URLCONF的键,它表示“root”urls.py文件,您将从中为每个应用程序添加urls.py文件。 URL路由在Django教程中已经非常广泛地介绍了,所以在这里就不需要了。

一个观点有三个要求:

  1. 它必须是可调用的。它可以是基于函数的视图,也可以是继承自基于类的视图。根据HTTP动作(GET,POST等)查看as_view() 方法以使其可调用。
  2. 它必须接受一个HttpRequest对象作为第一个位置参数。这是调用所有process_request和process_view中间件方法的结果。
  3. 它必须返回一个HttpResponse对象,或引发一个异常。这是用于启动WSGI处理程序的process_view循环的响应对象。

process_view

现在WSGI处理程序知道要调用哪个视图函数,它再次遍历其中间件方法列表。 任何Django中间件的process_view方法都是这样声明的:

process_view(request,view_function,view_args,view_kwargs)

和process_request一样,process_view函数必须返回None或HttpResponse对象(或引发异常),从而允许WSGI处理程序继续处理视图或“短路”并返回响应。 查看CSRF中间件的源代码,查看process_view的实例。如果存在CSRF cookie,那么process_view方法将返回None并执行视图。 如果不是,请求被拒绝,并且进程被短路,导致失败消息。

process_exception

如果view函数产生一个异常,Handler将遍历它的process_exception方法列表。 这些方法以相反的顺序执行,从settings.py中列出的最后一个中间件到第一个。 如果发生异常,则进程将短路,并且不会调用其他进程中断件。 通常我们依靠Django的BaseHandler提供的异常处理程序,但是在编写自己的定制中间件类时,您当然可以实现自己的异常处理。

process_response

在这一点上,我们将有一个HttpResponse对象,可以是由视图或由WSGI处理程序构建的process_view方法列表返回的,也可以轮流循环访问响应中间件。这是任何中间件都必须修改数据的最后机会,并且是从内层向外执行的(想象一下洋葱,视图在中心)。看一下缓存中间件源代码中的process_response实例:取决于应用程序中的不同条件(即缓存是否关闭,如果我们正在处理流等),我们需要响应存储在缓存中还是不存在。

注意:在1.10之前的Django和更高版本之间的一个区别是:在旧式MIDDLEWARE_CLASSES中,即使较早的中间件使进程短路,每个中间件也将始终调用其process_response方法。在新的MIDDLEWARES风格中,只有中间件和之前执行的中间件才会调用其process_response方法。有关MIDDLEWARES和MIDDLEWARE_CLASSES之间差异的更多详细信息,请参阅文档。

好了~

最后,Django的WSGI Handler从HttpResponse对象构建一个返回值,并执行回调函数将该数据发送到Web服务器并发送给用户。

所以,两个关键要点:

  1. 现在我们知道view函数是如何与URLconf相匹配的,以及实际调用的是什么(WSGI Handler)。
  2. 有四个关键点可以通过您自己的定制中间件进入请求/响应循环:process_request,process_response,process_view和process_exception。 想一想:请求中间件是从外部执行的,在中心点击查看,然后通过响应中间件返回到表面。