1. 中间件
Django中的中间件是一个轻量级、底层的插件系统,可以介入Django的请求和响应处理过程,并用于修改Django的输入或输出。中间件的设计为开发者提供了一种无侵入式的开发方式,增强了Django框架的健壮性。
Django的中间件预置了五个方法:
(1)方法一:__init__()初始化方法,无需任何参数,服务器响应第一个请求时则调用一次,用于确定是否启用了当前中间件,如下:
def __init__(self):
pass
(2)方法二:处理请求前的process_request()方法,在每个请求上,request对象产生之后,url匹配之前调用,返回None或HttpResponse对象,如下:
def process_request(self,request):
pass
(3)方法三:处理视图前的process_view()方法,在每个请求上,url匹配之后,视图函数调用之前调用,返回None或HttpResponse对象,如下:
def process_view(self,request,view_func,*view_args,**view_kwargs):
pass
(4)方法四:处理响应后的process_response()方法,视图函数调用之后,所有响应返回浏览器之前被调用,在每个请求上调用,返回HttpResponse对象,如下:
def process_response(self,request,response):
pass
(5)方法五:异常处理的process_exception()方法,当视图抛出异常时调用,在每个请求上调用,返回一个HttpResponse对象,如下:
def process_exception(self,request,exception):
pass
注意,若在自定义中间件中仅有__init__()初始化方法而未定义__call__()方法,则通常报错如下:
TypeError:__init__()takes1positionalargumentbut2weregiven.
创建中间件类的时候要继承‘MiddlewareMixin’类
from django.utils.deprecation import MiddlewareMixin
# 自定义中间件
class UserSessionMiddleware(MiddlewareMixin):
pass
创建的中间件要添加到主目录下的settings.py中的‘MIDDLEWARE’中,否则无法生效
中间件的应用场景:路由拦截、封禁IP等等
2. Cookie
状态保持:
实际上,浏览器与服务器之间是使用Socket套接字进行通信的,服务器将请求结果返回给浏览器之后,会关闭当前的Socket连接,而且服务器也会在处理页面完毕之后销毁页面对象。有时候,开发者需要保存用户浏览的状态,例如用户是否登录过、浏览过哪些商品等。要实现状态保持主要有两种方式,分别是:①在客户端存储信息使用Cookie;②在服务器端存储信息使用Session。
Cookie有时也用其复数形式Cookies,指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)。
正常情况下,Cookie的特点主要有以下几点:
(1)Cookie以键值对的格式进行信息的存储,例如BIDUPSID=AD2A7EBE88E19663FC6112407119C266、PSTM=1521183013等;
(2)Cookie基于域名安全,不同域名的Cookie是不能互相访问的,例如访问baidu.com时向浏览器中写了Cookie信息,使用同一浏览器访问alibaba.com时,则无法访问到baidu.com写的Cookie信息;
(3)当浏览器请求某网站时,会将浏览器存储的跟网站相关的所有Cookie信息提交给网站服务器。
针对Cookie的这些特点,其中一个非常典型应用如记住用户名,进而进行网站的广告推送
若要设置Cookie值,则要使用到HttpResponse类的如下函数:
set_cookie(key,value) | 设置Cookie值。 |
def index(request):
# 获取HttpResponse
res = HttpResponse("ok")
# 设置cookie
res.set_cookie("is_login",1)
return res
下面来使用Django读取Cookie值。Cookie信息是被包含在请求头中,可以使用request对象的COOKIES属性访问,如下:
request.COOKIES | 获取Cookies信息。 |
还需要使用到HttpResponse类的如下函数:
write(content) | 写入数据内容到HttpResponse对象中。 |
Cookie的过期时间:
笼统地说,Cookie分为2类:会话Cookie和 持久Cookie
会话Cookie是一种临时Cookie,它记录用户访问长点是的设置和偏好。用户退出浏览器时,会话Cookie就被删除了。
持久Cookie的生存时间更长一些,他们存储在硬盘上,浏览器退出,计算机重启时,他们仍然存在。通常用持久Cookie维护某个用户会周期性访问的站点的配置文件或登录名。
会话Cookie和持久Cookie之间的唯一区别就是他们的过期时间。没有指定Expires(过期时间)时,默认为会话Cookie。
Cookie的存储大小:
Firefox和Safari允许cookie多达4097个字节,包括名(name)、值(value)和等号。
Opera允许cookie多达4096个字节,包括:名(name)、值(value)和等号。
Internet Explorer允许cookie多达4095个字节,包括:名(name)、值(value)和等号。
注:多字节字符计算为两个字节。在所有浏览器中,任何cookie大小超过限制都被忽略,且永远不会被设置。
3. Session
实际开发应用中,对于敏感、重要的信息,建议要存储在服务器端,而不能存储在浏览器(客户端)中,如用户名、余额、等级、验证码等信息。通常情况下,在服务器端进行状态保持的方案就是Session。
Django项目中是默认启用Session的
若要查看session的具体存储方式,则需要打开项目主目录下的settings.py文件,并设置SESSION_ENGINE项来指定Session数据存储的方式,可以存储在数据库、缓存、Redis等。
(1)存储在数据库中,如下设置可以写,也可以不写,这是默认存储方式,如下:
SESSION_ENGINE='django.contrib.sessions.backends.db'
(2)存储在缓存中,即存储在本机内存中,若丢失则不能找回,此方式比数据库存储的方式读写更快,如下:
SESSION_ENGINE='django.contrib.sessions.backends.cache'
(3)混合存储,优先从本机内存中存取,若没有则从数据库中存取,如下:
SESSION_ENGINE='django.contrib.sessions.backends.cached_db'
(4)若存储在数据库中,需要在INSTALLED_APPS项中来安装Session应用,如下:
(5)当进行迁移文件后会在数据库中创建出存储Session的表,如下:
(6)django_session数据表结构如下:
操作Session包括三个数据字段,分别是键session_key、值session_data、过期时间expire_date。
我们知道,所有请求者的Session都会存储在服务器中,那么,服务器是如何区分请求者和Session数据的对应关系呢?
其实,在使用Session后,都会在Cookie中存储一个sessionid的数据,每次请求时浏览器都会将这个数据发给服务器,服务器在接收到sessionid后,会根据这个值找出这个请求者的Session。而若想使用Session,浏览器必须支持Cookie,否则就无法使用Session了。
当然了,在存储Session时,键与Cookie中的sessionid是相同的,而值是开发人员设置的键值对信息,且进行了base64编码,过期时间则由开发人员设置。
Session常用的对象和方法:
使用HttpRequest对象对session进行操作
(1)以键值对的格式写入session,如下:
request.session['键']=值
(2)根据键的get()方法读取值,如下:
request.session.get('键',默认值)
(3)清除所有session,在存储中删除值的部分,如下:
request.session.clear()
(4)清除session数据,在存储中删除session的整条数据,如下:
request.session.flush()
(5)删除session中的指定键及值,在存储中只删除某个键及对应的值,如下:
delrequest.session['键']
(6)设置会话的超时时间,若未指定过期时间,则两周后自动过期,如下:
request.session.set_expiry(value)
当value是一个整数时,会话将在value秒且没有活动后过期;当value为0,那么用户会话的Cookie,将在用户的浏览器关闭时过期;当value为None,那么会话永不过期。
cookie和session的区别:http协议-无状态的,cookie和session进行用户状态的保持,cookie是存在客户端的,以后这个域名下面的其他页面的访问会携带这个cookie,不安全的,可以被随机篡改,session将用户的状态存在服务端,生成一个sessionId通过cookie存到浏览器端,浏览段每次请求携带sessionid,服务端通过sessionid获取存储在副段的用户信息