cookie与session简介 django操作cookie django操作session
cookie与session简介
"""
回忆:HTTP协议四大特性
1.基于请求响应
2.基于TCP、IP作用于应用层之上的协议
3.无状态
不保存客户端的状态
4.无连接
"""
最开始的网站都不需要用户注册 所有人来访问获取到的数据都是一样的
随着互联网的发展很多网站需要指定当前用户的状态
cookie
保存在客户端与用户状态相关的信息
session
保存在服务端与用户状态相关的信息
ps:session的工作需要依赖于cookie
ps:浏览器有资格拒绝保存服务端发送过来的cookie数据
ps:以后我们还会接触到token、jwt等各种技术 目的都只有一个>>>:记录某种状态
早期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键值对:
set_signed_cookie
HttpResponse对象.set_signed_cookie(key,
value,
salt='加密盐',
max_age=None,
expires=None
...
)
参数:
- key, 键
- value='', 值
- max_age=None, 超时时间
- expires=None, 超时时间(IE requires expires, so set it if hasn't been already.)
- path='/', Cookie生效的路径,/ 表示根路径,特殊的:根路径的cookie可以被任何url的页面访问
- domain=None, Cookie生效的域名
- secure=False, https传输
- httponly=False 只能http协议传输,无法被JavaScript获取(不是绝对,底层抓包可以获取到也可以被覆盖)
cookies也是可以有过期时间的。
request.COOKIES
通过request.COOKIES查看cookies键值对:
因为浏览器现在已经有cookies,所以每次访问路由都会携带cookies。
delete_cookie
def logout(request):
rep = redirect("/login/")
rep.delete_cookie("user") # 删除用户浏览器上之前设置的usercookie值
return rep
'''所谓退出登录本质其实就是将客户端的标识用户身份的cookie删除'''
用户登录功能
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'
举个例子:request.session['username']= 'cloud'
那么session中存储的就是加密过的'cloud'
session_key
:
存储的是针对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秒就过期。
session补充方法
# 将所有Session失效日期小于当前日期的数据删除
request.session.clear_expired()
# 检查会话session的key在数据库中是否存在
request.session.exists("session_key")
# 删除当前会话的所有Session数据
request.session.delete() # 只删除客户端的cookies
# 删除当前的会话数据并删除会话的Cookie。
request.session.flush() # 客户端cookies、服务端session都删除
# 设置会话Session和Cookie的超时时间
request.session.set_expiry(value)
* 如果value是个整数,session会在些秒数后失效。
* 如果value是个datatime或timedelta,session就会在这个时间后失效。
* 如果value是0,用户关闭浏览器session就会失效。
* 如果value是None,session会依赖全局session失效策略(在django框架下默认14天)。