zoukankan      html  css  js  c++  java
  • 三种会话管理方式

    1. Http是无状态的协议

    Http协议不要求客户端(浏览器)在每次请求中标明身份,客户端和服务器间没有一个持久连接来用于多个页面间的访问。客户端发一个请求,服务器给一个回复。

    2. 三种会话管理方式

            第一种:Session        

      • 说明:用户的登录凭证等信息存放在服务器。服务器验证成功后给客户端发一个sessionid,下次服务器根据sessionid(通过cookie来传输)来找出相应的session信息判断是否已经登录(1.URL重写:若cookie被禁用,可以把sessionid写在url后面  2.表单隐藏字段:服务器自动修改表单,添加一个隐藏字段,在表单提交时把sessionid传递回服务器。)
      • 过程

    http过程

    处理动作

    1. 第一次请求

    服务器创建一个session对象,并为其分配唯一的sessionid

    2. 响应:包含sessionid的cookie 把sessionid通过cookie返回浏览器
    3. 请求:登录的信息,用户名和密码

    通过cookie把sessionid传回服务器

    服务器根据sessionid找到对应的session对象

    验证用户名和密码,并把登录凭证放到session中

    4. 响应:包含sessionid的cookie且有登录凭证 把sessionid通过cookie返回浏览器
    5. 请求:新的访问请求 根据sessionid找到session对象,判断其中是否有登录凭证
      • 优点:安全性,cookie保存在客户端可能会被修改
      • 缺点
        • 会话信息存储在服务端,若在线量较多,则会占比较多服务器资源
        • 若采用集群作服务器,那需要在这些服务器间进行session共享
        • 多个应用(不同服务器)需要共享session时的跨域问题

            第二种:Cookie        

      • 说明:用户登录时把信息传到服务端,客户端收到服务端生成的cookie(包含登录凭证)并保存。下次再请求时,把cookie传到服务器进行查库验证。cookie(kv形式)一般包含关键字(key)、值(value)、有效域(domain)、路径(域的路径,一般设置为全局:"")、失效时间、安全标志
      • 过程

    http过程

    处理动作

    1. 请求:登录的用户名和密码

    用户发起登录请求,把登录信息一起传到服务器

    2. 响应:包含登录凭证的cookie(set-cookie头部)

    服务器验证是否满足条件,如果满足则创建一个登录凭证

    将登录凭证进行数字加密,把加密后的信息写入cookie,且给cookie一个名字

    把cookie返回给客户端

    3. 请求:包含cookie头部

    服务器根据cookie名字从请求头部中获取cookie值

    进行解密处理,做数字签名认证

    4. 响应:一个http响应

    根据上面的处理作出反应

      • 优点:实现服务端的无状态,不用管理会话,只要创建和验证cookie即可
      • 缺点
        • cookie有大小限制
        • 每次要传cookie,如果请求量增加,对性能会有影响
        • 不允许跨域(跨域:不同域名之间相互访问,在服务器A的页面中访问服务器B)

            第三种:Token        

      • 说明:用户把登录信息传到服务端,服务端生成token传到客户端,下次请求把token传到服务器,服务器解密验证token用非对称加密,不用保存信息,而是保存解密的规则来验证。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串)(签名后的字符串-用户 ID-指纹)
      • 过程

    http过程

    处理动作

    1. 发起请求,登录用户名和密码

    用户发起登录请求,把登录信息一起传到服务器

    服务器将登录凭证做数字签名,得到token串

    2. 响应:返回token

    把token返回给客户端

    客户端本地保存token

    3. 请求:token放在header或url中

    token保存在header或url中传到服务器

    服务器对token进行解密和签名认证,拿到登录凭证,判断有效性

    4. 响应

    根据上面的处理作出反应

      • 优点
        • 无状态、可扩展
        • 支持移动设备:app应用:有效存储token,保证每次调接口时拿到正确token,每次调接口时把token回到header或接口地址中;web应用:token可存于localStorage或sessionStorage,然后每次发ajax请求时,把token放在header中
        • 跨程序调用:不像session/cookie方式,它们对域有严格限制
        • 安全:采用非对称加密
      • 一个例子(从网上搜出来的)

    当注册 /登录成功后: 
    1. 指定一个指纹,任意值都可以,只要这个值对这个用户没有使用过即可
    2. 将指纹和用户 ID 拼起来并签名,组成 签名后的字符串-用户 ID-指纹 这样结构的 token
    3. 将用户 ID 与指纹对应起来放到缓存中,并且设置缓存过期时间,这个时间就是 token 有效期
    4. 将 token 返回给客户端
    当用户再次请求时: 
    1. 将 token 中的用户 ID 和指纹再签名(通过服务端私钥),比对提交的 token 签名后的字符串 就可将篡改或伪造的 token 过滤掉了(或许这一步有更好的实现方式)。 
    2. 过了上一步,仍然无法确定 token 是否已被吊销。获取缓存中的指纹与提交的 token 的指纹比对,若缓存中取不到指纹值(缓存已设置过有效期期)或缓存中的指纹与 token 的指纹值不相符,就说明这个 token 被吊销了。
    3. 通过了上面两步,表示这个请求是已认证了的 

    3. 参考链接

     还是一些不太清楚的地方,如果有错误还请指出~

  • 相关阅读:
    查找最大回文
    java-线程池
    Java基础 IO流——第一部分
    tomcat优化
    反射
    网络编程——第二部分
    网络编程——第一部分
    Java基础 IO流——第四部分
    Java基础 IO流——第三部分
    Java基础 IO流——第二部分
  • 原文地址:https://www.cnblogs.com/coolqiyu/p/7020506.html
Copyright © 2011-2022 走看看