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天）。