博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Web框架之Django_09 重要组件(Django中间件、csrf跨站请求伪造)
阅读量:6305 次
发布时间:2019-06-22

本文共 16934 字,大约阅读时间需要 56 分钟。

摘要

  • Django中间件

  • csrf跨站请求伪造

一、Django中间件:

  什么是中间件?

  官方的说法:中间件是一个用来处理Django的请求和响应的框架级别的钩子。它是一个轻量、低级别的插件系统,用于在全局范围内改变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之后就不再注释这个中间件了。

  那接下来就学习中间件中的方法以及这些方法什么时候被执行。

  Django默认有七个中间件,但是django暴露给用户可以自定义中间件并且里面可以写五种方法

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

自定义中间件:
  自定义中间件需要在Django配置文件中告诉Django去哪找这个自定义的中间件,默认可以放在项目的对应app中,新建一个文件夹middleware,在此文件夹中新建文件my_middleware.py,然后在此文件中自定义五个方法中的任意一个或多个:
  tip:中间件的本质就是含有五个可以修改的内置方法的类,所以自定义的时候需要做的就是先继承一个Django提供的中间件混合的父类。

  • process_request方法:

    process_request有一个参数,就是request,这个request和视图函数中的request是一样的(在交给Django后面的路由之前,对这个request对象可以进行一系列修改操作)。
    由于request对象是一样的,所以我们可以对request对象进行操作,包括给其增加属性,修改属性,这样就可以在后续的视图函数中通过这个request获取到我们在中间件添加的值。
    它的返回值可以是None,按正常流程继续走,交给下一个中间件处理,如果是HttpResponse对象,Django将不执行视图函数,,而将响应对象返回给浏览器。
    # 导入MiddlewareMixin模块from django.utils.deprecation import MiddlewareMixin#定义中间件的类,它继承MiddlewareMixinclass Md1(MiddlewareMixin):    def process_request(self, request):        print('Md1里面的process_request')class Md2(MiddlewareMixin):    def process_request(self, request):        print('Md2里面的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.middleware.my_middleware.Md1',    'app01.middleware.my_middleware.Md2',]

    此时访问一个视图,查看终端打印内容:

    根据结果可以知道:执行顺序Md1、Md2、视图函数内容

    接着打印每个自定义中间件Md1和Md2中的request,发现是一个request对象
    总结:
    ## 中间件的process_request方法是在执行视图函数之前执行的
    ## 当配置多个中间件时,执行顺序按照Django配置文件中的MIDDLEWARE列表中的顺序依次由上至下执行
    ## 不同的中间件之间传递的request其实都是同一个对象
    ps:当前端发来请求,Django会执行每个中间件中的process_request,执行顺序按照配置文件由上至下执行。

  • process_response方法:

            当Django处理完请求,发出返回相应的返回结果时候,process_response方法就会执行,同时多个中间件中的process_response方法是按照MIDDLEWARE中的注册顺序倒序执行的,也就是说当请求走的时候,process_response方法会由下至上依次执行每个中间件的该方法

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

    # 导入MiddlewareMixin模块from django.utils.deprecation import MiddlewareMixin#定义中间件的类,它继承MiddlewareMixinclass Md1(MiddlewareMixin):    def process_request(self, request):        print('Md1里面的process_request')    def process_response(self, request, response):        print('Md1中的process_response')        return responseclass Md2(MiddlewareMixin):    def process_request(self, request):        print('Md2里面的process_request')    def process_response(self, request, response):        print('Md2中的process_response')        return response

    总结:

    ## process_response方法是在视图函数之后执行的,并且顺序是Md2比Md1先执行,也就是执行顺序从下到上

  • process_view 方法:路由匹配成功执行视图函数之前自动触发(从上到下依次执行每个中间件中的该方法)

    详情:

    中间件的process_request方法最后一个执行,它的process_response方法是最先执行。process_viewprocess_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 MiddlewareMixinclass 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_requestMD1里面的 process_request--------------------------------------------------------------------------------MD2 中的process_view
    index--------------------------------------------------------------------------------MD1 中的process_view
    indexapp01 中的 index视图MD1里面的 process_responseMD2里面的 process_responseprocess_view方法是在Django路由系统之后,视图系统之前执行的,执行顺序按照MIDDLEWARE中的注册顺序从前到后顺序执行的
    process_view
  • process_exception 方法:当视执行视图函数报错时,自动触发该方法(从下往上依次执行)
    详情:

    process_exceptionprocess_exception(self, request, exception)该方法两个参数:一个HttpRequest对象一个exception是视图函数异常产生的Exception对象。这个方法只有在视图函数中出现异常了才执行,它返回的值可以是一个None也可以是一个HttpResponse对象。如果是HttpResponse对象,Django将调用模板和中间件中的process_response方法,并返回给浏览器,否则将默认处理异常。如果返回一个None,则交给下一个中间件的process_exception方法来处理异常。它的执行顺序也是按照中间件注册顺序的倒序执行。 给MD1和MD2添加上这个方法:from django.utils.deprecation import MiddlewareMixinclass 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_requestMD1里面的 process_request--------------------------------------------------------------------------------MD2 中的process_view
    index--------------------------------------------------------------------------------MD1 中的process_view
    indexapp01 中的 index视图呵呵MD1 中的process_exceptionMD1里面的 process_responseMD2里面的 process_response注意,这里并没有执行MD2的process_exception方法,因为MD1中的process_exception方法直接返回了一个响应对象。
    process_exception
  • process_template_response 方法 :视图函数返回的对象有一个render()方法(或者表明该对象是一个TemplateResponse对象或等价方法)(从下往上依次执行)详情:

    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 responseclass 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视图")    def render():        print("in index/render")        return HttpResponse("O98K")    rep = HttpResponse("OK")    rep.render = render    return rep访问index视图,终端输出的结果:MD2里面的 process_requestMD1里面的 process_request--------------------------------------------------------------------------------MD2 中的process_view
    index--------------------------------------------------------------------------------MD1 中的process_view
    indexapp01 中的 index视图MD1 中的process_template_responseMD2 中的process_template_responsein index/renderMD1里面的 process_responseMD2里面的 process_response从结果看出:视图函数执行完之后,立即执行了中间件的process_template_response方法,顺序是倒序,先执行MD1的,在执行MD2的,接着执行了视图函数返回的HttpResponse对象的render方法,返回了一个新的HttpResponse对象,接着执行中间件的process_response方法。
    process_template_response

    中间件的执行流程:

    上一部分,我们了解了中间件中的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两个方法的触发是有条件的,执行顺序也是倒序。总结所有的执行流程如下:

    中间件版登录验证:

    中间件版的登录验证需要依靠session,所以数据库中要有django_session表。
    urls.pyfrom app02 import views as v2urlpatterns = [    url(r'^admin/', admin.site.urls),    url(r'^login/',v2.login),    url(r'^home/',v2.home),    url(r'^index/',v2.index)]----------------------------------------------------------------------------views.pyfrom django.shortcuts import render,redirect,HttpResponsefrom 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('

    这是home页面 只有登录了才能看到

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

    这是index页面 也只有登录了才能看到

    ')----------------------------------------------------------------------------login.html
    登陆页面
    {
    % csrf_token %}

    {
    { error_msg }}

    ----------------------------------------------------------------------------middlewares.pyfrom django.utils.deprecation import MiddlewareMixinfrom django.shortcuts import redirectclass 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',]
    中间件版的登录验证

    附:Django请求流程图

   总结:django中间件能够帮我实现 网站全局的身份验证,黑名单,白名单,访问频率限制,反爬相关

二、csrf跨站请求伪造

   啥叫跨站请求伪造:

  首先:创造2个Django项目,模拟2个web服务框架:一个假设是正规转账服务框架,一个是钓鱼网站服务框架
  正规转账服务框架(Django项目1,端口默认8000):

# 交易页面trade.html    
官方网站

官方网站交易页面

用户名:

转账金额:

转账目标账户名:

# 交易视图函数:def trade(request): if request.method == 'POST': user_name = request.POST.get('username') money = request.POST.get('money') target_account = request.POST.get('target_account') # 模拟转账成功后的提示 res = '%s 给 %s 转账了 %s,成功!' % (user_name, target_account, money) return HttpResponse(res) return render(request, 'trade.html')(记得配路由,注释掉setting文件中的crsf中间件)

  钓鱼网站服务框架(Django项目2,端口改为8001):

# trade.html页面    
钓鱼网站

钓鱼网站伪造的交易页面

用户名:

转账金额:

转账目标账户名:

(记得配路由)

  以上过程就是跨站请求伪造的过程,主要就是仿照和银行一模一样的的网站,里面的用户名和转账的接口都是指向银行的,只是在网站上form表单处做了手脚,让用户选择的转账用户以为是转给他了,但是实际上是转给了隐藏input标签预设好的账户,达到一种不正当的目的。

  当然此处仅仅是展现一下钓鱼的基本简单过程,也就是它实现的基础。

  当我们知道存在这种安全隐患的时候,就可以认识这个csrf中间件的作用了,它的作用就是给每一个post请求创造一个按照它的规则和用户制作出来的特殊字符串,每当用户在提交post请求时候都会拿这个字符串与Django中的进行比对,如果不一样则拒绝请求,如果一样则允许该请求进行路由对应的视图函数操作。

   接下来就可以将setting配置文件中的中间件部分的csrf部分取消注释,让他生效,只要每次在前端页面提交post请求出加上一行{% csrf_token %}就可以了。这样就完美解决了用户post请求的安全性。

  (它的实现过程实际上是在post请求处,比如form表单里加上标签:<input type="hidden" name="csrfmiddlewaretoken" value="2vzoo1lmSWgLTdI2rBQ4PTptJQKRQTRwnqeWRGcpdAQGagRp8yKg8RX2PdkF4aqh">,value是动态生成的,每一次刷新都不一样)

  当使用ajax发送post请求的时候csrf校验该如何进行:

正经的网站

{
% csrf_token %}

username:

money:

others:

也可以自定义那个视图函数需要csrf校验和不需要csrf校验:

from django.views.decorators.csrf import csrf_exempt, csrf_protect# csrf_protect设置校验crsf# csrf_exempt设置不校验crsffrom django.utils.decorators import method_decoratorfrom django.views import View@csrf_exempt  # 不校验csrfdef index1(request):    return HttpResponse('ok')@csrf_protect  # 校验csrfdef index2(request):    return HttpResponse('ok')'''csrf装饰CBV需要注意(** ** ** )csrf_protect跟正常的CBV装饰器一样三种csrf_exempt只能有下面两种方式'''@method_decorator(csrf_exempt, name='dispatch')  # 第一种class Index3(View):    # @method_decorator(csrf_exempt)   # 第二种    def dispatch(self, request, *args, **kwargs):        super().dispatch(request, *args, **kwargs)        # 其实都是给dispatch加

 

转载于:https://www.cnblogs.com/suguangti/p/11046100.html

你可能感兴趣的文章
计算机网络与Internet应用
查看>>
Django 文件下载功能
查看>>
走红日本 阿里云如何能够赢得海外荣耀
查看>>
在市场营销中使用敏捷方法:过程、团队与成功案例
查看>>
新书问答:Agile Management
查看>>
苹果将iOS应用带入macOS
查看>>
react入门
查看>>
VUE高仿饿了么app
查看>>
针对Kubernetes软件栈有状态服务设计的思考
查看>>
你的可用性达标了吗?云端业务性能高可用的深度实践
查看>>
linux yum清缓存脚本
查看>>
基于epoll封装的事件回调miniserver
查看>>
天猫高管全面解读大快消2018新零售打法
查看>>
idea springboot热部署无效问题
查看>>
第八章 进程间通信
查看>>
HttpSession接口中的方法(Jsp中的session类的用法)
查看>>
「镁客早报」AI可预测心脏病人死亡时间;机器人开始在美国送外卖
查看>>
MoQ(基于.net3.5,c#3.0的mock框架)简单介绍
查看>>
物联网全面升级,十年内推动工业进入智能化新阶段
查看>>
spring-通过ListFactory注入List
查看>>