给cbv下面的函数加装饰器
写一个验证用户登录的程序
前端页面
# 写一个装饰器验证session
def login_auth(func):
def inner(request,*args,**kwargs):
if request.session.get('is_login'):
return func(request,*args,**kwargs)
else:
return redirect('/login/')
return inner
定义cbv
class Home(View):
def get(self,request):
pass
def post(self,request):
pass
视图函数
# 两种加装饰器的方法
# 1,类名上面加装饰器
from django.utils.decoration import method_decorator
@method_decorator(login_auth,name='get') # 加在类上面的话，必须通过name指定给谁加
class Home(View):
def get(self,request):
pass
def post(self,request):
pass
# 2，方法上面加,不要用原生的装饰器，用的话，只能改参数，那样的话不通用
class Home(View):
@method_decorator(login_auth)
def get(self,request):
pass
def post(self,request):
pass
第三种定义dispatch函数,拦截内置的分发函数，但是写在cbv里的 方法都会被加上装饰器
class MyHome(View):
@method_decorator(login_auth) # 第三种 get和post都会被装饰
def dispatch(self, request, *args, **kwargs):
super().dispatch(request,*args,**kwargs)
# @method_decorator(login_auth) # 第一种
def get(self,request):
return HttpResponse('get')
def post(self,request):
return HttpResponse('post')
Django中间件
Process_request和Process_response方法
继承MiddlewareMixin类 实现自定义中间件
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
在settings.py的MIDDLEWARE配置项中注册上述两个自定义中间件：
MIDDLEWARE = [
'middlewares.MD1', # 自定义中间件MD1
'middlewares.MD2' # 自定义中间件MD2
]
总结：
- 中间件的process_request方法是在执行视图函数之前执行的。
- 当配置多个中间件时，会按照MIDDLEWARE中的注册顺序，也就是列表的索引值，从前到后依次执行的。
- 不同中间件之间传递的request都是同一个对象
- 多个中间件中的process_response方法是按照MIDDLEWARE中的注册顺序倒序执行的，也就是说第一个中间件的process_request方法首先执行，而它的process_response方法最后执行，最后一个中间件的process_request方法最后一个执行，它的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方法，最后返回给浏览器
process_template_response和process_exception两个方法的触发是有条件的，执行顺序也是倒序。总结所有的执行流程如下：
总结
process request：请求来的时候从上往下依次执行每一个中间件里面的process request processresponse：响应走的时候会从下往上依次执行每一个中间件里面的process response方法
process view：路由匹配成功执行视图之前自动触发（从上往下依次执行）
processexception：当视图函数报错了，自动触发（从下往上依次执行）
processtemplate response：视图函数返回的对象有一个render（）方法（或者表明该对象是一个TemplateResponse对象或等价方法）（从下往上依次执行）
CSRF
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性
可以这样来理解：
攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户
Django中的防止措施在前端页面写
{% csrf_token %}django就会自动帮我们渲染一个随机字符串做校验
不是网站上的所有字段都是需要校验的，这个时候我们需要给函数加上装饰器，给特定的功能加上csrf校验，或者给特定的功能不做csrf校验
在注释掉setting文件中的csrf组件前提下导入
from django.views.decorators.csrf import csrf_exempt,csrf_protect
给指定的功能加上csrf校验用csrf_protect装饰器
这里写的加装饰器的方式与给cbf加装饰器的方式一样，需要注意的是给某些功能去掉csrf校验的装饰器csrf_exempt 只有两种使用方式，都是加给全局的。
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加