cookie与session简介
会话跟踪技术
什么是会话跟踪？
我们需要先了解一下什么是会话！可以把会话理解为客户端与服务器之间的一次会晤，在一次会晤中可能会包含多次请求和响应。例如你给10086打个电话，你就是客户端，而10086服务人员就是服务器了。从双方接通电话那一刻起，会话就开始了，到某一方挂断电话表示会话结束。在通话过程中，你会向10086发出多个请求，那么这多个请求都在一个会话中。
在Web中，客户向某一服务器发出第一个请求开始，会话就开始了，直到客户关闭了浏览器会话结束。
在一个会话的多个请求中共享数据，这就是会话跟踪技术。例如在一个会话中的请求如下： 请求银行主页；
- 请求登录（请求参数是用户名和密码）；
- 请求转账（请求参数与转账相关的数据）；
- 请求信誉卡还款（请求参数与还款相关的数据）。
在这上会话中当前用户信息必须在这个会话中共享的，因为登录的是张三，那么在转账和还款时一定是相对张三的转账和还款！这就说明我们必须在一个会话过程中有共享数据的能力。
会话路径技术使用Cookie或session完成
我们知道HTTP协议是无状态协议，也就是说每个请求都是独立的！无法记录前一次请求的状态。但HTTP协议中可以使用Cookie来完成会话跟踪！在Web开发中，使用session来完成会话跟踪，session底层依赖Cookie技术。
cookie介绍
cookie的由来
大家都知道HTTP协议是无状态的。
无状态的意思是每次请求都是独立的，它的执行情况和结果与前面的请求和之后的请求都无直接关系，它不会受前面的请求响应情况直接影响，也不会直接影响后面的请求响应情况。
对服务器来说，每次的请求都是全新的。
状态可以理解为客户端和服务器在某次会话中产生的数据，那无状态的就以为这些数据不会被保留。会话中产生的数据又是我们需要保存的，也就是说要“保持状态”。因此Cookie就是在这样一个场景下诞生。
什么是cookie
其实Cookie是key-value结构，类似于一个python中的字典。随着服务器端的响应发送给客户端浏览器。然后客户端浏览器会把Cookie保存起来，当下一次再访问服务器时把Cookie再发送给服务器。 Cookie是由服务器创建，然后通过响应发送给客户端的一个键值对。客户端会保存Cookie，并会标注出Cookie的来源（哪个服务器的Cookie）。当客户端向服务器发出请求时会把所有这个服务器Cookie包含在请求中发送给服务器，这样服务器就可以识别客户端了！
cookie的原理
cookie的工作原理是：由服务器产生内容，浏览器收到请求后保存在本地；当浏览器再次访问时，浏览器会自动带上Cookie，这样服务器就能通过Cookie的内容来判断这个是“谁”了。
Cookie规范
Cookie大小上限为4KB；
一个服务器最多在客户端浏览器上保存20个Cookie；
一个浏览器最多保存300个Cookie；
上面的数据只是HTTP的Cookie规范，但在浏览器大战的今天，一些浏览器为了打败对手，为了展现自己的能力起见，可能对Cookie规范“扩展”了一些，例如每个Cookie的大小为8KB，最多可保存500个Cookie等！但也不会出现把你硬盘占满的可能！
注意，不同浏览器之间是不共享Cookie的。也就是说在你使用IE访问服务器时，服务器会把Cookie发给IE，然后由IE保存起来，当你在使用FireFox访问服务器时，不可能把IE保存的Cookie发送给服务器。
Cookie的覆盖
如果服务器端发送重复的Cookie那么会覆盖原有的Cookie，例如客户端的第一个请求服务器端发送的Cookie是：Set-Cookie: a=A；第二请求服务器端发送的是：Set-Cookie: a=AA，那么客户端只留下一个Cookie，即：a=AA。
在浏览器中查看cookie
浏览器中按F12，点network---cookies就能看到
Session
Session****的由来
Cookie虽然在一定程度上解决了“保持状态”的需求，但是由于Cookie本身最大支持4096字节，以及Cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是Session。
问题来了，基于HTTP协议的无状态特征，服务器根本就不知道访问者是“谁”。那么上述的Cookie就起到桥接的作用。
我们可以给每个客户端的Cookie分配一个唯一的id，这样用户在访问时，通过Cookie，服务器就知道来的人是“谁”。然后我们再根据不同的Cookie的id，在服务器上保存一段时间的私密资料，如“账号密码”等等。
总结而言：Cookie弥补了HTTP无状态的不足，让服务器知道来的人是“谁”；但是Cookie以文本的形式保存在本地，自身安全性较差；所以我们就通过Cookie识别不同的用户，对应的在Session里保存私密的信息以及超过4096字节的文本。
另外，上述所说的Cookie和Session其实是共通性的东西，不限于语言和框架。
Session流程解析
总结：
cookie: 服务端保存在客户端浏览器上的信息都可称为cookie，它的表现形式一般都是k:v键值对(可以有多个)
session: 数据是保存在服务端的并且表现形式也是k:v键值对(可以有多个)
- cookie就是保存在客户端浏览器上的信息
- session就是保存在服务端上的信息
- session是基于cookie工作的(大部分保存用户状态的操作都是用到cookie)
token简单聊一下
# session虽然数据是保存在服务端的，但是禁不住数据的量大
那么token呢不需要再服务端保存数据：
用户登录成功之后呢，将一段用户信息进行加密处理(加密算法只有开发人员知道)
将加密之后的结果拼接在信息后面，整体返回给浏览器保存
浏览器下次访问的时候带着该加密信息，服务端自动会切取前面的一段真实信息再次使用自己的加密算法跟浏览器尾部的密文进行比对，比对成功则成功访问。这样就无需在服务端进行数据的保存。大大节省了存储空间。
在Django中cookie操作
首先。我们之前操作视图函数的返回值:
return HttpResponse( )
return render( )
return redirect( )
如果想要操作cookie需要如下编写:
obj1 = HttpResponse()
# 操作cookie
return obj1
obj2 = render()
# 操作cookie
return obj2
obj3 = redirect()
# 操作cookie
return obj3
# 如果你想要操作cookie，你就不得不利用obj对象
cookie关键字：
设置cookie：
设置cookie:
obj.set_cookie(key,value)
加盐处理:
obj.set_signed_cookie(key,value,salt='盐')
获取cookie:
获取cookie：
request.COOKIES.get('key')
加盐数据获取：
request.get_signed_cookie(key,salt='盐')
举例：
点击提交按钮跳转到home页面
def login(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'junjie' and password == '123':
return redirect('/home/')
return render(request,'login.html')
def home(request):
return HttpResponse('我是home页面，只有登录的用户才能进来。')
但是上述存在一个问题：我们需求是必须输入正确的用户名密码才可以进入home页面，但是我们直接访问/home/路由也可以直接进入home页面对吧。那么这就就需要用到cookie
逻辑代码如下：
def login(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'junjie' and password == '123':
# 应用cookie
obj = redirect('/home/')
"""
这里可以随意书写键值对，
目的是为了让请求携带cookie发送至服务端并且让客户端浏览器进行保存
"""
obj.set_cookie('name','junjie6')
return obj
return render(request,'login.html')
def home(request):
# 获取客户端cookie信息，判断是否有cookie，并且是否一致
if request.COOKIES.get('name') == 'junjie6':
return HttpResponse('我是home页面，只有登录的用户才能进来。')
# 如果没有重新跳转至登录页面
return redirect('/login/')
此时，直接访问home是不允许的，必须登录之后才能访问，并且登录之后会记录登录状态，下次也能直接访问home页面。
以上代码逻辑的不足之处：
- 现在只有一个home页面，如果存在很多页面难道都需要做一次判断是否存在cookie？
- 解决思路：给每一个页加一个登录装饰器
解决逻辑代码：
# 此时func就是home函数
def login_auth(func):
# 在装饰器中通过request拿cookie值
def inner(request, *args, **kwargs):
# 利用request做判断，判断cookie是否有值
if request.COOKIES.get('name'):
res = func(*args, **kwargs)
return res
else:
return redirect('/login/')
return inner
def login(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'junjie' and password == '123':
# 应用cookie
obj = redirect('/home/')
"""
这里可以随意书写键值对，
目的是为了让请求携带cookie发送至服务端并且让客户端浏览器进行保存
"""
obj.set_cookie('name', 'junjie6')
return obj
return render(request, 'login.html')
@login_auth
def home(request):
return HttpResponse('我是home页面，只有登录的用户才能进来。')
@login_auth
def index(request):
return HttpResponse('我是index页面，只有登录的用户才能进来。')
@login_auth
def func(request):
return HttpResponse('我是func页面')
不足之处二：
用户如果在没有登陆的情况下想访问一个需要登陆的页面 那么先跳转到登陆页面 当用户输入正确的用户名和密码之后 应该跳转到用户之前想要访问的页面去 而不是直接写死，比如：url写的index，先跳转到login页面，成功输入用户密码，再跳转到index页面
访问登录页面的两种情况：
直接访问登录页面
通过装饰器跳转到登录页面
补充：
# 获取当前用户请求的url
print(request.path_info)
# 能够获取到当前用户上访问url?后面的。
print(request.get_full_path())
"在上述案例中表示：跳转到login页面之前想要访问的页面"
代码展示：
from django.shortcuts import render, HttpResponse, redirect
# Create your views here.
# 装饰器
# 此时func就是home函数
def login_auth(func):
# 在装饰器中通过request拿cookie值
def inner(request, *args, **kwargs):
"""
获取用户输入的上一次想要访问的url,假设输入index
因没有cookie自动跳转到login
:param request:
:param args:
:param kwargs:
:return:
控制跳转的函数是login,所以需要将上一次用户输入的url传给login函数
"""
target_url = request.get_full_path()
# 利用request做判断，判断cookie是否有值
if request.COOKIES.get('name'):
res = func(request,*args, **kwargs)
return res
else:
"""
假设用户输入index,地址栏就会出现 ?next=index,
login函数就能通过get_full_path()获取用户输入的url
"""
return redirect('/login/?next=%s' % target_url)
return inner
def login(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'junjie' and password == '123':
"""
获取用户上一次想要访问的url
不过此时可能为None,因为用户直接访问login页面
"""
target_url = request.GET.get('next')
if target_url:
print(target_url)
obj = redirect(target_url)
else:
# 应用cookie
obj = redirect('/home/')
"""
这里可以随意书写键值对，
目的是为了让请求携带cookie发送至服务端并且让客户端浏览器进行保存
"""
# 让浏览器记录cookie数据
obj.set_cookie('name', 'junjie6')
return obj
return render(request, 'login.html')
@login_auth
def home(request):
return HttpResponse('我是home页面，只有登录的用户才能进来。')
@login_auth
def index(request):
return HttpResponse('我是index页面，只有登录的用户才能进来。')
@login_auth
def func(request):
return HttpResponse('我是func页面')
cookie参数补充：
1、# 可以设置超时时间：cookie可以存在多长时间，过了时间就自动清除cookie，不保存登录状态则下次需要重新登录。
参数：
max_agr=时间限制(以秒为单位)
expires=时间限制(以秒位单位)
#### 两者区别：
在设置cookie的时候可以添加一个超时时间
obj.set_cookie('username', 'jason666',max_age=3,expires=3)
max_age
expires
两者都是设置超时时间的 并且都是以秒为单位
需要注意的是 针对IE浏览器需要使用expires
2、主动删除cookie(类似于退出登录/注销功能)
@login_auth # 注意退出登录也是登录后才能操作的所以需要添加装饰器
def logout(request):
obj = redirect('/login/')
obj.delete_cookie('username')
return obj
session操作
设置session
request.session['key'] = value
获取session
request.session.get('key')
session数据是保存在服务端的，给客户端返回的是一个随机字符串的形式。不是(key:value)的形式，而是(sessionid:随机字符串)的形式
实操设置session
urls.py
# 设置 session
url(r'set_session',views.set_session)
views.py
# session 操作
def set_session(request):
request.session['hobby'] = 'girl'
return HttpResponse('hello 小姐姐！')
为什么会出现上述情况？
因为上述提到session的数据是保存在服务端的，在默认情况下操作session的时候需要django默认的一张django_session表。是否还记得在做数据库迁移命令的时候，会自动创建出很多的表，其中就有一张我们需要的的django_session。
django默认session的过期时间是14天，也可认为的修改。
上述代码为设置session，有设置就有获取，以下获取session。
def get_session(request):
print(request.session.get('hobby'))
return HttpResponse('下次再见！')
django中session内部运行你所应该直到的事
def set_session(request):
request.session['name'] = 'junjie'
"""
内部运行发生的事
1.Django内部会自动生成一个随机字符串
2.Django内部自动将随机字符串个对应的数据存储到django_session表中
2.1先在内存中产生操作数据的缓存
2.2在响应经过Django中间件的时候才真正的操作数据库
"""
return HttpResponse('设置session的返回结果')
def get_session(request):
print(request.session.get('name'))
"""
内部运行发生的事
1.自动从浏览器请求中获取session对应的随机字符串
2.拿着该随机字符串到django_session表中查找对应的数据
3.如果比对上，则将对应的数据取出并以字典的形式封装到request.session中
4.如果比对不上，则request.session.get返回的是None
"""
return HttpResponse('获取session的返回结果')
这是设置一条的情况，如果设置多条session尼？
def set_session(request):
request.session['hobby'] = 'girl'
request.session['hobby2'] = 'girl1'
request.session['hobby2'] = 'girl2'
request.session['hobby3'] = 'girl3'
return HttpResponse('hello 小姐姐！')
# 可同时设置多个session，但是只占用一条记录
但是获取的时候都可以获取到
# 并且取得时候都可以取到。
def get_session(request):
print(request.session.get('hobby'))
print(request.session.get('hobby1'))
print(request.session.get('hobby2'))
print(request.session.get('hobby3'))
return HttpResponse('下次再见！')
总结：django_session 表中数据条数是取决于浏览器的，同一个计算机上(同一个ip地址)同一个浏览器只会有一条数据有效，当session过期的时候，可能会出现多条数据对应一个浏览器，但是该现象不会持续很久，内部会自动识别过期数据并清除，也可以手动清除或者代码清除，目的为了节省服务端数据库资源。
设置过期时间：
"""
括号内可以放四种类型的参数：
1.整数 --- 多少秒
2.日期对象 --- 到指定日期就失效
3.0 --- 一旦当前浏览器窗口关闭立刻失效
4.不写 --- 失效时间取决于django内部全局默认的失效时间
"""
request.session.set_expiry() # 单独书写
清除session
request.session.delete() # 只删服务端的，客户端的不删
request.session.flush() # 浏览器和服务端都清空
Django中默认支持Session，其内部提供了5种类型的Session供开发者使用。
1. 数据库Session
SESSION_ENGINE = 'django.contrib.sessions.backends.db' # 引擎（默认）
2. 缓存Session
SESSION_ENGINE = 'django.contrib.sessions.backends.cache' # 引擎
SESSION_CACHE_ALIAS = 'default' # 使用的缓存别名（默认内存缓存，也可以是memcache），此处别名依赖缓存的设置
3. 文件Session
SESSION_ENGINE = 'django.contrib.sessions.backends.file' # 引擎
SESSION_FILE_PATH = None # 缓存文件路径，如果为None，则使用tempfile模块获取一个临时地址tempfile.gettempdir()
4. 缓存+数据库
SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db' # 引擎
5. 加密Cookie Session
SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies' # 引擎
其他公用设置项：
SESSION_COOKIE_NAME ＝ "sessionid" # Session的cookie保存在浏览器上时的key，即：sessionid＝随机字符串（默认）
SESSION_COOKIE_PATH ＝ "/" # Session的cookie保存的路径（默认）
SESSION_COOKIE_DOMAIN = None # Session的cookie保存的域名（默认）
SESSION_COOKIE_SECURE = False # 是否Https传输cookie（默认）
SESSION_COOKIE_HTTPONLY = True # 是否Session的cookie只支持http传输（默认）
SESSION_COOKIE_AGE = 1209600 # Session的cookie失效日期（2周）（默认）
SESSION_EXPIRE_AT_BROWSER_CLOSE = False # 是否关闭浏览器使得Session过期（默认）
SESSION_SAVE_EVERY_REQUEST = False # 是否每次请求都保存Session，默认修改之后才保存（默认）
CBV如何添加装饰器
注意：CBV无法直接像给函数添加装饰器一样添加
from django.views import View
class MyLogin(View):
@login_auth
def get(self,request):
return HttpResponse('GET请求')
def post(self,request):
return HttpResponse('POST请求')
# 直接添加报错
以下为固定写法：
方式一：method_decorator
# 格式：在类的方法上添加：@method_decorator(装饰器名)
from django.views import View
from django.utils.decorators import method_decorator # 需要导入该模块(模块名即为：装饰方法(见明知意))
class MyLogin(View):
@method_decorator(login_auth) # 使用装饰器
def get(self,request):
return HttpResponse('GET请求')
def post(self,request):
return HttpResponse('POST请求')
方式二：@method_decorator(装饰器名,name='指定给那个方法添加')
# 在类的上方添加：@method_decorator(装饰器名,name='指定给那个方法添加')
@method_decorator(login_auth,name='get')
@method_decorator(login_auth,name='post')
class MyLogin(View):
def get(self,request):
return HttpResponse('GET请求')
def post(self,request):
return HttpResponse('POST请求')
方式三：dispatch
# CBV源码剖析详解地址：https://www.cnblogs.com/garyhtml/p/15955229.html
# 剖析CBV源码得知：定义一个dispatch方法添加(他会作用域当前类里面得所有的方法)
class MyLogin(View):
@method_decorator(login_auth)
def dispatch(self, request, *args, **kwargs):
return super().dispatch(request,*args,**kwargs)
def get(self,request):
return HttpResponse('GET请求')
def post(self,request):
return HttpResponse('POST请求')