这种方法因为把登录凭证直接存放客户端，并且须要cookie传来传去，所以它的缺点也比脚绫趋显：

1)cookie有大年夜小限制，存储不了太多半据，所以如果登录凭证存的消息过多，导致加密签名后的串太长，就会激发其余问题，比如其它营业场景须要cookie的时刻，就有可能没那么多空间可用了;所以用的时刻得谨慎，得不雅察实际的登录cookie的大年夜小;比如太长，就要推敲长短是数字签名的算法太严格，导致签名后的串太长，那就恰当调剂签名逻辑;比如如不雅一开端用4096位的RSA算法做数字签名，可以推敲换成1024、2048位;

1) 办事端session是用户第一次拜访应用时，办事器就会创建的对象，代表用户的一次会话过程，可以用来存放数据。办事器为每一个session都分派一个独一的sessionid，以包管每个用户都有一个不合的session对象。

2)每次传送cookie，增长了请求的数量，对拜访机能也有影响;

3)也有跨域问题，毕竟照样要用cookie。

比拟起第一种方法，cookie-based筹划明显照样要好一些，今朝很多多少web开辟平台或框架都默认应用这种方法来做会话治理，比如php琅绫擎yii框架，这是我们团队后端今朝用的，它用的就是这个筹划，以上提到的那些登录逻辑，框架也都已经封装好了，实际用起来也很简单;asp.net琅绫擎forms身份认证，也是这个思路，这里有一篇好文┞仿把它的实现细节都说的很清跋扈：

http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html

这种方法不经由过程cookie进行token的传递，而是每次请求的时刻，主动把token加到http header琅绫擎或者url后面，所以即使在native app琅绫擎也能应用它来调用我们经由过程web宣布的api接口。app琅绫擎还要做两件工作：

前面两种会话治理方法因为都用到cookie，不合实用在native app琅绫擎：native app不好治理cookie，毕竟它不是浏览器。这两种筹划都不合实用来做纯api办事的登录认证。要实现api办事的登录认证，就要推敲下面要介绍的第三种会话治理方法。

3. token-based的治理方法

这种方法大年夜流程和实现上来说，跟cookie-based的方法没有太多差别，只不过cookie-based琅绫擎写到cookie琅绫擎的ticket在这种方法下称为token，这个token在返回给客户端之后，后续请求都必须经由过程url参数或者是http header的情势，主动带上token，如许办事端接收到请求之后就能直接大年夜http header或者url琅绫擎取到token进行验证：

1)有效存储token，得包管每次调接口的时刻都能大年夜同一个地位拿到同一个token;

2)每次调接口的的代率攀里都得把token加到header或者接口地址琅绫擎。

看起来麻烦，其实也不麻烦，这两件工作，对于app来说，很轻易做到，只要对接口调用的模块稍加封装即可。

这种方法用在web应用里也有跨域的问题，比如应用如不雅安排在a.com，api办事安排在b.com，大年夜a.com琅绫擎发出ajax请求到b.com，默认情况下是会报跨域缺点的，这种问题可以用CORS(跨域资本共享)的方法来快速解决，相干细节可去浏览前面给出的CORS文┞仿具体懂得。

这种方法跟cookie-based的方法同样都还有的一个问题就是ticket或者token刷新的问题。有的产品琅绫擎，你肯定不欲望用户登录后，操作了半个小时，结不雅ticket或者token到了过不时光，然后用户又得去从新登录的情况出现。这个时刻就得推敲ticket或token的主动刷新的问题，简单来说，可以在验证ticket或token有效之后，主动把ticket或token的掉效时光延长，然后把它再返回给客户端;客户端如不雅检测到办事器有返回新的ticket或token，就调换本来的ticket或token。

4. 安然问题

在web应用琅绫擎，会话治理的安然性始终是最重要的安然问题，这个对用户的影响极大年夜。

起首大年夜会话治理凭证来说，第一种方法的会话凭证仅仅是一个session id，所以只要这个session id足够随机，而不是一个自增的数字id值，那么其它人就弗成能随便马虎地假装别人的session id进行操作;第二种方法的凭证(ticket)以及第三种方法的凭证(token)都是一个在办事端做了数字签名，和加密处理的串，所以只要密钥不泄漏，别人也无法随便马虎地拿到这个串中的有效信息并对它进行修改。总之，这三种会话治理方法的凭证本身是比较安然的。

然后大年夜客户端和办事端的http过程来说，当别人截获到客户端请求中的会话凭证，就能拿这个凭证假装原用户，做一些不法操作，而办事器也认不出来。这种安然问题，可以简单采取https来解决，固然可能还有http劫持这种更高程度的威逼存在，然则我们大年夜代码能做的防备，确切也就是这个层次了。

最后的安然问题就是CSRF(跨站请求捏造)。这个跟代码有很大年夜关系，本质上它就是代码的马脚，只不过一般情况下这些马脚，作为开辟人员都不轻易发明，只有那些一门心思惟搞些工作的人才会专门去找这些马脚，所以这种问题的防备更多地照样依附于开辟人员对这种进击方法的懂得，包含常见的进击情势和应对办法。不管凭证信息本身多么安然，别人应用CSRF，就能拿到别人的凭证，然后用它假装别人进行不法操作，所以有时光还真得多去懂得下它的相干材料才行。举例来说，假如我们把凭证直接放到url后面进行传递，就有可能成为一个CSRF的马脚：当恶意用户在我们的应用内上传了1张引用了他本身网站的图片，当正常的用户登录之后拜访的页面琅绫擎包含这个图片的时刻，因为这个图片加载的时刻会向恶意网站发送get请求;当恶意网站收到请求的时刻，就会大年夜这个请求的Reffer header琅绫擎看到包含这个图片的页面地址，而这个地址正好包含了正常用户的会话凭证;于是恶意用户就拿到了正常用户的凭证;只要这个凭证还没掉效，他就能用它假装用户进行不法操作。

5. 总结

针对问题1和问题2，我见过的解决筹划是采取redis这种中心办事器来治理session的增删改查，一来减轻web办事器的包袱，二来解决不合web办事器共享session的问题。针对问题3，因为办事端的session依附cookie来传递sessionid，所以在实际项目中，只要解决各个项目琅绫擎若何实现sessionid的cookie跨域拜访即可，这个是可以实现的，就是比较麻烦，前后端有可能都要做处理。

　　推荐阅读

　　Windows 7仍然是桌面王者 用户无视Windows 10

对于微软来说，不少Windows 7用户一向疏忽Win10的存在，这让他们很是无语。如今，市场调研机构NetMarketShare给出的最新统计显示，Windows 7仍然是全球应用最多的桌面操作体系，其市场份额>>>详细阅读

本文标题：关于Web会话管理的3种方式

地址：http://www.17bianji.com/lsqh/37143.html

 1/2    1