目录
django中间件三个需要了解的方法
1.process_view
路由匹配成功之后执行视图函数/类之前自动触发(顺序同process_request)
2.process_exception
视图函数/类执行报错自动触发(顺序同process_response)
3.process_template_response
视图函数/类返回的HttpResponse对象含有render并且对应一个方法的时候自动触发(顺序同process_response)
首先自定义中间件：
定义完之后要对中间件进行注册。
process_view
process_view何时触发：
路由匹配成功之后，执行视图函数/类之前自动触发。（顺序同process_request，经过每一个中间件。）
执行顺序：
process_exception
在类中添加此方法:
process_exception何时触发：
如下图可见此方法在正常的一次请求流程中不会触发：
exception和异常相关。当执行视图函数的时候报错了，自动触发。
注意是从下往上执行，process_exception的形参接受视图函数的报错信息。
process_template_response
注意：参数有response的都要使用return进行返回。
执行顺序：
可发现在正常的一次请求流程中此方法没有执行。
process_template_responsed方法的执行条件：
视图函数、视图类返回的Httpresponse对象含有render属性，并且render属性对应一个render方法的时候自动触发。
示例：
基于django中间件实现功能的插拔式设计
将各个功能制作成配置文件的字符串形式
如果想拥有该功能就编写对应的字符串
如果不想有该功能则注释掉对应的字符串
补充知识
如果利用字符串导入模块
import importlib
s1 = 'bbb.b' # aaa.bbb.ccc.b
res = importlib.import_module(s1) # from aaa.bbb.ccc import b
print(res) # <module 'bbb.b' from 'D:\\pythonProject03\\djangomiddle\\bbb\\b.py'>
'''注意字符串的结尾最小单位只能是py文件 不能是py文件里面的变量名'''
思考django中间件是如何处理的(最小单位是类名)
需求分析
模拟编写一个消息通知功能(微信、qq、邮箱)
方式1:基于函数封装的版本
没有眼前一亮的感觉 很一般
方式2:基于django中间件的功能设计
眼前一亮 回味无穷
django中间件中每个字符串都代表特定的功能。
这就叫功能的插拔式设计。
也就是说写字符串相当于导入了某个模块：
正常情况下导模块需要用到import句式：
示例：
importlib模块
importlib模块支持传递字符串来导入模块。
如下使用importlib模块与使用import句式会获得相同的结果。
使用importlib模块：
使用from ... import ...句式：
更多例子：
import importlib
import b
str_module = 'b'
res = importlib.import_module(str_module)
print(type(res)) # <class 'module'>
print(type(b)) # <class 'module'>
importlib模块底层原理：
将字符串按照点切割：
importlib中的字符串的结尾最小单位只能到py文件名，而不能是py文件的的某个变量名。
如下图desc是b.py文件中的变量名：
需求分析：
编写一个消息通知功能（微信、qq、邮箱都会收到消息）。
方式1：基于函数封装
每个功能都写一个函数：
封装总方法：
方式2：基于django中间件的功能设计
创建配置文件settings.py、启动文件start.py。再创建三个功能文件放入notify目录。
实现功能拆分，进行解耦合。
email功能文件下，写一个功能类：
核心功能函数send_msg：
不同的类，当有相同的功能时，他们的名字也应该相同（多态性）：
只要发消息，就使用send_msg方法。
编写settings.py:
思考django中间件是如何处理的：
notify是一个包，在start.py导入包名notify:
导入包名notify实际是导入的包中的__init__文件。
start.py文件中，执行settings定义的函数send_all：
在__init__文件中导入settings.py文件内的列表:
for循环取出列表中的字符串，并使用rsplit方法做切分：
得到用字符串表示模块路径、模块中的类名：
使用importlib模块的功能，通过字符串获得模块类型：
由于模块也是对象，通过反射从模块中拿名字：（也就是拿到真正的类）
类名加括号产生对象：
这个对象里面就有send_msg方法了，调用send_msg传入参数，实现功能。
cookie与session简介
"""
回忆:HTTP协议四大特性
1.基于请求响应
2.基于TCP、IP作用于应用层之上的协议
3.无状态
不保存客户端的状态
4.无连接
"""
最开始的网站都不需要用户注册 所有人来访问获取到的数据都是一样的
随着互联网的发展很多网站需要指定当前用户的状态
cookie
保存在客户端与用户状态相关的信息
session
保存在服务端与用户状态相关的信息
ps:session的工作需要依赖于cookie
补充:浏览器有资格拒绝保存服务端发送过来的cookie数据
早期cookies
最开始的浏览器，每次向服务器的请求都自报家门，即每发一次请求，都把用户名和密码都发过去：
当用户第一次把用户名和密码输对了之后。浏览器自动保存用户名和密码。发请求时，浏览器自动帮你输入用户名密码。
浏览器有能力记住不同网站的用户名和密码。此时浏览器也就是客户端。
产生了cookie的定义：
保存在客户端与用户状态相关的信息（通常情况下类似于字典的kv键值对）
早期的cookies很不安全：
真实的用户名密码保存在浏览器不安全。万一有人打开你的电脑，窃取你浏览器的密码。
随机字符串解决cookies安全问题
所以采取了以下办法：
当第一次输对了用户名和密码，服务端会给你发一个随机字符串。服务端有一张表记着字符串和用户的对应关系。下次访问服务端的时候，你把这个随机字符串带上，服务端可以通过表来确定这个随机字符串对应哪个用户。
这样做的好处：
外人查看随机字符串，也无法查看用户的密码。而用户可以拿着随机字符串进行登录。
session的定义：
用户真正的数据保存在服务端，所以我们把保存在服务端中，跟用户状态相关的信息叫做session。
随机字符串叫什么？
随机字符串既存在于浏览器，也存在于服务端。
在客户端上叫cookies 。
在服务端上叫session。
注意：
session是不可能单独工作的，要依赖于cookies。
所有跟用户状态相关的操作 都要依赖于cookies
禁止浏览器保存cookies
在开发者工具的application查看cookies:
浏览器有资格拒绝保存cookies:
禁用cookies后无法进行登录：
django操作cookie
from django.shortcuts import render,HttpResponse,redirect
return render()
return HttpResponse()
return redirect()
要想操作cookie就不能直接返回HttpResponse对象 必须先用变量接收
obj1 = render()
return obj1
obj2 = HttpResponse()
return obj2
obj3 = redirect()
return obj3
set_cookie
要想操作cookie就不能直接返回HttpResponse对象 必须先用变量接收。
如下图，先产生HttpResponse对象，再用对象调用set_cookie方法，此方法让浏览器保存键值对：
查看浏览器报错的cookies键值对:
request.COOKIES
通过request.COOKIES查看cookies键值对：
因为浏览器现在已经有cookies，所以每次访问路由都会携带cookies。
用户登录功能
def login_func(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'jason' and password == '123':
obj = redirect('/home/')
obj.set_cookie('name', username)
return obj
return render(request, 'loginPage.html')
前端编写表单：
后端视图函数：
让客户端保存凭证，并重定向回home页面
（Home页面只有登录的用户才可以查看）：
Homepage获取cookies:
服务器询问你的cookies有没有name这个键。当浏览器携带cookies时，才能访问home页面，没有cookies就重定向回登录页面。
给视图函数添加装饰器
def login_auth(func_name):
def inner(request, *args, **kwargs):
if request.COOKIES.get('name'):
res = func_name(request, *args, **kwargs)
return res
return redirect('/login/')
return inner
@login_auth
def home_func(request):
return HttpResponse('home页面 只有登录的用户才可以查看')
新需求：
需要登录才能访问的页面有好几个.
极端情况：
我们有三百个视图函数，视图函数返回的页面，登录之后的用户才能查看。
在不影响函数原有的功能的基础下，给其添加新功能，可以使用：
装饰器
在请求访问该页面的时候携带cookies时，继续执行视图函数。
请求未携带cookies时，重定向回登录页面。
给多个视图函数添加装饰器：
登录成功后重定向回原页面
进阶操作:
用户没有登录之前访问某个页面，此时让用户跳转到登录页面，用户输入用户名密码登录之后，跳回用户原来想访问的页面。
def login_func(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'jason' and password == '123':
target_path = request.GET.get('next')
if target_path:
obj = redirect(target_path)
else:
obj = redirect('/home/')
obj.set_cookie('name', username)
return obj
return render(request, 'loginPage.html')
def login_auth(func_name):
def inner(request, *args, **kwargs):
# print(request.path) # 只获取用户输入的路由信息
# print(request.path_info) # 只获取用户输入的路由信息
target_path = request.path_info
# print(request.get_full_path()) # 获取用户输入的路由信息+问号后面携带的数据
if request.COOKIES.get('name'):
res = func_name(request, *args, **kwargs)
return res
return redirect('/login/?next=%s' % target_path)
return inner
获取路由的三个方法
查看三个方法返回的结果：
三个方法的区别：访问home路由时，使用问号携带一些信息。
第三个方法，可以获取整个路由，并且也可以获取问号携带的信息：
总结：
为了实现上述需求，我们使用path_info方法：
先获取用户想访问页面的路由信息，存储在变量名target_path中：
跳转到登录页面时，通过问号携带信息：
如下例子中，用户登录之前想访问的页面路由是/home1/
之前登录成功之后，我们重定向的页面时写死的：
现在我们添加判断：
target_path不存在的情况，意味着用户是直接访问的登录页面。
此时的request.GET.get('next')是获取不到值的，因为这个获取的是路由后面通过问号携带的信息。此时走else分支：跳转回home首页
当target_path存在的情况，意味着用户是从别的页面跳转过来的。此时通过request.GET.get('next')获取用户是从哪里来的。然后给他重定向回到原页面。
django操作session
由于session是保存在服务端上面的数据 就应该有个地方能够存储
我们只需要执行数据库迁移命令即可 django会自动创建很多需要的表
django默认的session失效时间是14天
设置session
request.session['key'] = value
1.生成一个随机字符串
2.对value数据做加密处理 并在django_session表中存储
随机字符串>>>加密数据
3.将随机字符串也发送一份给客户端保存(cookie)
sessionid:随机字符串
获取session
request.session.get('key')
1.自动获取随机字符串
2.去django_session表中根据随机字符串获取加密的数据
3.自动解密数据并处理到request.sesion.get()中
补充说明
1.可以设置过期时间
2.存储session数据的位置也可以修改 各种数据库 甚至一个文件
session保存的位置
由于session是保存在服务端上面的数据 就应该有个地方能够存储
我们只需要执行数据库迁移命令即可 django会自动创建很多需要的表
django默认的session失效时间是14天
如下图所示，django自动创建的表中，有一张session表：
自动创建的session表有如下字段：
设置session
设置session
request.session['key'] = value
1.生成一个随机字符串
2.对value数据做加密处理 并在django_session表中存储
随机字符串>>>加密数据
3.将随机字符串也发送一份给客户端保存(cookie)
sessionid:随机字符串
示例：
在没有进行数据库迁移的情况下，执行这条命令会报错：
正常执行这条命令，会将session表里添加一条数据：
session_data:
存储真正跟用户相关的数据，
我们设置session时使用的是：request.session['key'] = value
而session_data存储的是一个加密过的字典，这个加密字典的键和值就是上面设置session时的键和值。
举个例子：request.session['username']= 'cloud'
那么session中存储的就是加密过的{'username':'cloud'}
session_key:
存储的是加密算法产生的随机字符串。
expire_date:
存储session的过期时间。django中默认的session失效时间是14天。
流程推导（重要）
- 浏览器朝服务端发请求。
- 服务端创建session。
服务端在django_session表中，
生成随机字符串(session_key）、加密之后的用户数据(session_data) - 服务端将随机字符串（session_key）发送给浏览器保存，此时这个随机字符串就称之为cookies.
查看浏览器保存的session_key:
浏览器是以键值对的形式保存的，键是浏览器自己取的，不必在意。这个值就是服务端发送过来的session_key。
下次浏览器访问服务端，就会自动携带session_key（cookies），服务端会拿着浏览器带来的session_key去保存session的表中进行校验，查看是否有相同的字符串。
获取session
获取session
request.session.get('key')
1.自动获取随机字符串
2.去django_session表中根据随机字符串获取加密的数据
3.自动解密数据并处理到request.sesion.get()中
示例：
流程推导（重要）
- 服务端接受浏览器传过来的加密字符串(session_key)
- 拿着加密字符串去session表中查找
- 当查找到相同的字符串，取出其对应的session_data
- 对session_data自动解密，并处理到request.sesion.get()中
设置session过期时间 set_expiry
示例：
set_expiry:设置session的过期时间，括号里填写的单位是秒，这里的意思是session创建后3秒就过期。