Cookie、Session登陆验证相关介绍和用法

　　首先、HTTP协议是无状态的；所谓的无状态是指每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求都无直接关系，它不会受前面的请求响应直接影响，也不会直接影响后面的请求响应情况。简单来说就是，对服务器来说，每次的请求都是全新的。

　　状态可以理解为客户端和服务器在某次会话中产生的数据，那无状态的就以为这些数据不会被保留。会话中产生的数据又是我们需要保存的，也就是说要“保持状态”。因此Cookie就是在这样一个场景下诞生。

　　cookie虽然在一定程度上解决了“保持状态”的需求，但是由于cookie本身最大支持4096字节，以及cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是session。

　　问题来了，基于http协议的无状态特征，服务器根本就不知道访问者是“谁”。那么上述的cookie就起到桥接的作用。

　　我们可以给每个客户端的cookie分配一个唯一的id，这样用户在访问时，通过cookie，服务器就知道来的人是“谁”。然后我们再根据不同的cookie的id，在服务器上保存一段时间的私密资料，如“账号密码”等等。

　　总结而言：cookie弥补了http无状态的不足，让服务器知道来的人是“谁”；但是cookie以文本的形式保存在本地，自身安全性较差；所以我们就通过cookie识别不同的用户，对应的在session里保存私密的信息以及超过4096字节的文本。

　　另外，上述所说的cookie和session其实是共通性的东西，不限于语言和框架。

二、用户登陆应用的原理

　　用户从登陆到登陆成功后的其他展示操作页面是怎么联系的，也就是说，是怎么确保用户只有登陆验证成功后才能打开其他展示操作页面的。实际测试的情况是，如果绕过登陆页面，直接输入后台的url地址也可以直接访问其他页面，这样显然是不合理的，这就需要cookie和session配合验证。有了这个验证过程，我们就可以实现和其他网站一样只有登陆验证成功后才能进入其他后台页面。

　　这种认证机制的过程。每当我们使用浏览器访问一个登陆页面的时候，一旦我们通过了认证。服务器端就会发送一组随唯一的字符串（比如是 abcdef）到浏览器端并暂时储存起来，这个被储存在浏览器的东西就叫cookie，而服务器端也会自己存储一下用户当前的状态，比如 login = True，username = beibei 之类的用户信息。但是这种存储是以字典形式存储的，字典的唯一key就是刚才发给用户的唯一的cookie值。那么如果在服务器端查看session信息的话，理论上就会看到如下的字典

{abcdef:{'login':True,'username:beibei}}

因为每个cookie都是唯一的，所以我们在电脑上换个浏览器在登陆同一个网站也需要再次验证。那么为什么说我们只是理论上看到这样子的字典呢？因为出于安全性的考虑，其实对于上面那个大字典，不只是key值abcdef是被加密的，value值{'login':True,'username:beibei}在服务器端也是一样被加密的。所以我们在服务器上就算打开session信息看到的也是一串被加密过的字符串。

Cookie的定义

　　cookie翻译成中文意思是曲奇饼、饼干。然而，在因特网内cookie就和饼干没关系了。Cookie具体指的是一段小信息，它是服务器发送出来存储在浏览器上的一组组键值对，下次访问服务器时会自动携带这些键值对，以便服务器提取有用信息。

查看Cookie

使用Chrome浏览器，打开开发者工具。

Cookie、Session登陆验证相关介绍和用法

三、Django中操作Cookie

获取Cookie

request.COOKIES['key']
request.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)

参数说明：

default: 默认值
salt：加密盐
max_age：后台控制过期时间

设置Cookie

rep = HttpResponse(...)
rep ＝ render(request, ...)

rep.set_cookie(key,value,...)
rep.set_signed_cookie(key,value,salt='加密盐',...)

参数：

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获取（不是绝对，底层抓包可以获取到也可以被覆盖）

删除Cookie

def logout(request):
    rep = redirect("/login/")
    rep.delete_cookie("user")  # 删除用户浏览器上之前设置的usercookie值
    return rep

登录认证示例：

需要知道几点

一共有三次请求　　

注意：form表单的action走的路径还是/login/ 　　　　　

第一次请求：url:http://127.0.0.1:8080/login get请求　　　　

第一次请求：url:http://127.0.0.1:8080/login post请求 user pasw 　　　　

第一次请求：url:http://127.0.0.1:8080/main post请求携带着cookie的了　　　　

所以在main页面中就会取到cookie,因为这是的main里面已经有cookie了

Cookie版登陆校验：只需要在views.py中的后台函数上加一个验证装饰器

def check_login(func):    #装饰器函数
    def inner(request, *args, **kwargs):
        next_url = request.get_full_path()
        if request.get_signed_cookie("login", salt="SSS", default=None) == "yes":
            # 已经登录的用户...
            return func(request, *args, **kwargs)
        else:
            # 没有登录的用户，跳转刚到登录页面
            return redirect("/login/?next={}".format(next_url))
    return inner


def login(request):
    if request.method == "POST":
        username = request.POST.get("username")
        passwd = request.POST.get("password")
        if username == "xxx" and passwd == "dashabi":
            next_url = request.GET.get("next")
            if next_url and next_url != "/logout/":
                response = redirect(next_url)
            else:
                response = redirect("/main/")
            response.set_signed_cookie("login", "yes", salt="SSS")
            return response
    return render(request, "login.html")

cookie版登录