Cookie和Session机制浅析——线下分享预热

[Tamce]

昂，这是为了线下分享的预热做一个简单的预告和梗概。
才学尚浅，如有错误欢迎指正

HTTP 的状态保持机制（如记住用户的登录状态等）要用到 cookie 这个玩意，而常常 cookie 又和 session 一起出现，而这两个玩意又是比较容易搞混的，因此这次的分享我就来谈谈 cookie 和 session，顺便简单引出几点安全问题以及解决方案。

Cookie 的实现原理

cookie 是由客户端 UserAgent 所负责管理的文本文件，由服务器要求设置，保存在客户端，在客户端访问页面时，会在 HTTP 请求中附上已经设置的 cookie 值。

UserAgent 是指用户代理，即代表用户发起 HTTP 请求的软件（用户上网都需要代理，除非你人肉可以直连端口向外发送 HTTP 请求），如浏览器、curl、XHR等。

关于 HTTP 状态保持机制参见 RFC2109

Cookie 的安全问题及解决

暂略，线下分享

Session 的实现原理

session 是由服务器端进行实现的用于存储会话数据的玩意，它可以直接由 HTTP 服务器软件进行实现，也可由一些服务端语言进行实现，会话数据可以保存在任何地方如内存、内存型数据库、文件、数据库、其他服务器（分布式架构之类的）等等，这些都只是一个载体，我们不具体讨论。
session 会话机制主要由服务端和客户端共同维护一个 session id 来实现，服务端通过 cookie 来把一个特定的随机产生的 session id 发送给客户端，客户端之后每次请求时都会通过 cookie 来提交这个 session id 给服务器。
服务器获得一个 session id 时，从 session 载体（上述）中把该 id 对应的数据重新读出使用。

如 PHP 中会话数据将会恢复到 $_SESSION 变量中，同时也可以对该变量进行修改以达到写入会话数据的作用。

Session 机制的安全问题及解决

暂略，线下分享

额外的阅读资料

随意搜索网上很多（
别告诉我搞技术的搜索引擎都不会用（逃

[SunDoge]

简单补充几点

• 正常来说服务器上的session是明文保存的，如果服务器权限设置很随意（比如像我一样chmod -R 777）就会有被看穿的风险。Laravel应对这个问题使用了自己的session加密方法。
• 如果可以，少用session，保持stateless。首先以文件方式储存其实挺慢的，redis缓存好一点（前提是你的session也是自己实现的）；其次是要兼顾移动端app，所以json web token可能是更好的解决方案。

[Tamce]

用 jwt 的话依旧不能在客户端保存敏感信息，只能做用户身份确认和授权，当检查授权成功时如果要读取用户数据的话依然要从数据库中取出，且现代框架大部分都支持直接设置 session 载体，使用 memcache, redis 等可以有效降低读写文件/数据库带来的开销；当然将数据加密之后放到 jwt 里的话确实可行，但就算是加密过的敏感数据放到客户端，我总有种不安心的感觉。
而且关于移动端适配我有一种并不算十分好的解决方案，那就是将 session-id 签名后作为 token 放到 HTTP Header 中来使用，且可以使用 app-secret 进行签名，服务端确认签名后直接使用 session-id 恢复会话数据，这样将 API 拓展到给移动端使用的时候仅需要在重建会话时加一层验证即可。

[SunDoge]

你这样和自己实现session有什么区别，所以我说不如抛弃session-cookie的模式，这样连共享session的问题也不用考虑了，redis共享用户信息就行

[Tamce]

哈哈哈哈哈好像确实是这样，只是名义上还顶着一个 session 的名字