深圳Web培训
达内深圳罗湖中心

185-8886-4961

热门课程

Web ——cookie-based的管理方式

  • 时间:2017-10-09
  • 发布:深圳Web培训
  • 来源:达内新闻

Web ——cookie-based的管理方式

由于前一种方法会增加效劳器的担负和架构的复杂性,所以后来就有人想出直接把用户的登录凭据直接存到客户端的计划,当用户登录成功之后,把登录凭据写到cookie里边,并给cookie设置有用期,后续恳求直接验证存有登录凭据的cookie是否存在以及凭据是否有用,即可判别用户的登录状况。运用它来完成会话办理的全体流程如下:

1)用户建议登录恳求,效劳端依据传入的用户暗码之类的身份信息,验证用户是否满意登录条件,如果满意,就依据用户信息创立一个登录凭据,这个登录凭据简略来说就是一个目标,最简略的方法能够只包括用户id,凭据创立时刻和过期时刻三个值。

2)效劳端把上一步创立好的登录凭据,先对它做数字签名,然后再用对称加密算法做加密处理,将签名、加密后的字串,写入cookie。

cookie的姓名有必要固定(如ticket),由于后边再获取的时分,还得依据这个姓名来获取cookie值。

这一步增加数字签名的意图是避免登录凭据里的信息被篡改,由于一旦信息被篡改,那么下一步做签名验证的时分肯定会失利。做加密的意图,是避免cookie被他人截取的时分,无法轻易读到其间的用户信息。

3)用户登录后建议后续恳求,效劳端依据上一步存登录凭据的cookie姓名,获取到相关的cookie值。然后先做解密处理,再做数字签名的认证,如果这两步都失利,阐明这个登录凭据不合法;

如果这两步成功,接着就能够拿到原始存入的登录凭据了。然后用这个凭据的过期时刻和当时时刻做比照,判别凭据是否过期,如果过期,就需求用户再从头登录;如果未过期,则答应恳求持续。

这种方法最大的长处就是完成了效劳端的无状况化,彻底移除了效劳端对会话的办理的逻辑,效劳端只需求担任创立和验证登录cookie即可,无需坚持用户的状况信息。

关于第一种方法的第二个问题,用户会话信息同享的问题,它也能很好处理:

由于如果仅仅同一个运用做集群布置,由于验证登录凭据的代码都是一样的,所以不管是哪个效劳器处理用户恳求,总能拿到cookie中的登录凭据来进行验证;

如果是不同的运用,只需每个运用都包括相同的登录逻辑,那么他们也是能轻易完成会话同享的,不过这种情况下,登录逻辑里边数字签名以及加密解密要用到的密钥文件或许密钥串,需求在不同的运用里边同享,总而言之,就是需求算法彻底坚持一致。

这种方法由于把登录凭据直接寄存客户端,而且需求cookie传来传去,所以它的缺点也比较明显:

1)cookie有大小约束,存储不了太多数据,所以要是登录凭据存的音讯过多,导致加密签名后的串太长,就会引发其他问题,比方其它事务场景需求cookie的时分,就有可能没那么多空间可用了;

所以用的时分得慎重,得调查实践的登录cookie的大小;

比方太长,就要考虑是非是数字签名的算法太严厉,导致签名后的串太长,那就恰当调整签名逻辑;

比方如果一开始用4096位的RSA算法做数字签名,能够考虑换成1024、2048位;

2)每次传送cookie,增加了恳求的数量,对拜访功能也有影响;

3)也有跨域问题,究竟仍是要用cookie。

相比起第一种方法,cookie-based计划明显仍是要好一些,现在很多web开发平台或结构都默许运用这种方法来做会话办理,比方php里边yii结构,这是我们团队后端现在用的,它用的就是这个计划,以上提到的那些登录逻辑,结构也都现已封装好了,实践用起来也很简略;asp.net里边forms身份认证,也是这个思路,这里有一篇好文章把它的完成细节都说的很清楚:

前面两种会话办理方法由于都用到cookie,不合适用在native app里边:native app欠好办理cookie,究竟它不是浏览器。这两种计划都不合适用来做纯api效劳的登录认证。

要完成api效劳的登录认证,就要考虑下面要介绍的第三种会话办理方法。

想知道更多关于IT行业的信息吗?想远远不如行动,行动起来,一起加入达内,一起进入IT行业,跟着达内的脚步,一起走进如今的互联网信息时代,带给你不一样的色彩生活——【深圳web培训

上一篇:Web基于server端session的管理
下一篇:HTML5的12个小技巧

教你如何学习web前端知识

web上图片应用的优缺点

web前端的技术分析

web前端优化如何实现减小返回数据的体积

选择城市和中心
贵州省

广西省

海南省