Cookie与session(会话)

Cookie与session(会话)的由来

HTTP 是无状态协议。这就是说，当你在浏览器中加载页面，然后转到同一网站的另一页面时，服务器和浏览器都没有任何内在的方法可以认识到，这是同一浏览器访问同一网站。换一种说法，Web 工作的方式就是在每个HTTP 请求中都要包含所有必要的信息，服务器才能满足这个请求。在需要登录的页面上，每次重新加载页面时都需要重新登录操作，相关的流媒体也无法工作。网站不能记忆你从一个页面到下一个页面的喜好。所以我们需要用某种办法在HTTP 上建立状态，于是便有了cookie 和会话。

 

Cookie

cookie 的想法很简单：服务器发送一点信息，浏览器在一段可配置的时期内保存它。发送哪些信息确实是由服务器来决定：通常只是一个唯一ID 号，标识特定浏览器，从而维持一个有状态的假象，当然Cookie也可以保存一些其他相关信息。

关于cookie，有些重要的事情需要你了解：

• cookie对用户来说不是加密的

服务器向客户端发送的所有cookie 都能被客户端查看。你可以向客户端发送一些加密过的信息以保护其中的内容，但几乎不会有这种需求（至少在你不做坏事时是这样的）。而签名cookie，它可以混淆cookie 中的内容，但对于窥探者来说这Cookie与会话绝没有加密那样的安全性。

• 用户可以删除或禁用cookie
用户对cookie 有绝对的控制权，并且浏览器支持批量或单个删除cookie。除非你图谋不轨，否则用户没理由去删它，但在测试过程中有这种需求。用户也可以禁用cookie，但这更容易造成问题，因为只有最简单的Web 应用程序才不需要依赖cookie。

• 一般的cookie可以被篡改
不管浏览器什么时候发起一个跟cookie 关联的请求，只要你盲目地相信cookie 中的内容，都有可能会受到攻击。比如说，有些极其愚蠢的人会执行cookie 中的代码。要确保cookie 不被篡改，请使用签名cookie。

• cookie可以用于攻击

这几年出现了一种叫作跨站脚本攻击 （XSS）的攻击方式。XSS 攻击中有一种技术就涉及用恶意的JavaScript 修改cookie 中的内容。所以不要轻易相信返回到你的服务器的cookie 内容。用签名cookie 会有帮助（不管是用户修改的还是恶意JavaScript 修改的，这些篡改都会在签名cookie 中留下明显的痕迹），并且还可以设定选项指明cookie 只能由服务器修改。这些cookie 的用途会受限，但它们肯定更安全。

• 如果你滥用cookie，用户会注意到

如果你在用户的电脑上设了很多cookie，或者存了很多数据，这可能会惹恼用户，所以你应该避免出现这种情况。尽量把对cookie 的使用限制在最小范围内。

 

Cookie的安全

为了保证cookie 的安全，必须有一个cookie 秘钥。cookie 秘钥是一个字符串，服务器知道它是什么，它会在cookie 发送到客户端之前对cookie 加密。这是一个不需要记住的密码，所以可以是随机字符串。
外化第三方凭证是一种常见的做法，比如cookie 秘钥、数据库密码和API 令牌（Twitter、Facebook 等）。这不仅易于维护（容易找到和更新凭证），还可以让你的版本控制系统忽略这些凭证文件。这对放在GitHub 或其他开源源码控制库上的开源代码库尤其重要。

如何查看浏览器中的cookie

大多数浏览器都可以查看单个cookie 和它们存储的值。在Chrome 中，打开开发者工具（Ctrl+Shift+I），选择Application标签然后找到左侧树中的Cookies 一项。展开它，你会看到当前访问的网站。点击它，你会看到所有跟这个网站关联的cookie。你也可以右键点击域名清除所有的cookie，或者右键点击单个cookie 移除它。

 

Session会话

会话实际上只是更方便的状态维护方法。要实现会话，必须在客户端存些东西，否则服务器无法从一个请求到下一个请求中识别客户端。通常的做法是用一个包含唯一标识的cookie，然后服务器用这个标识获取相应的会话信息。cookie 不是实现这个目的的唯一手段，在“cookie 恐慌”的高峰时期（当时cookie 滥用的情况非常猖獗），很多用户直接关掉了cookie，因此发明了其他维护状态的方法，比如在URL 中添加会话信息。这些技术混乱、困难且效率低下，所以最好别用。HTML5 为会话提供了另一种选择，那就是本地存储，但现在还没有令人叹服的理由去采用这种技术而放弃经过验证有效的cookie。

从广义上来说，有两种实现会话的方法：把所有东西都存在cookie 里，或者只在cookie 里存一个唯一标识，其他东西都存在服务器上。前一种方式被称为“基于cookie 的会话”，并且仅仅表示比使用cookie 便利。然而，它还意味着要把你添加到cookie 中的所有东西都存在客户端浏览器中，所以我不推荐用这种方式。只有在你知道自己只存少量信息，并且不介意用户能够访问这些信息，而它也不会随着时间的增长而失控时，你才可以用这种方式。

如果你更愿意把会话信息存在服务器上，这也是我推荐的方式，那么你必须找个地方存储它。入门级的选择是内存会话。它们非常容易设置，但也有个巨大的缺陷：重启服务器后会话信息就消失了。更糟的是，如果你扩展了多台服务器，那么每次请求可能是由不同的服务器处理的，所以会话数据有时在那里，有时不在。这明显是不可接受的用户体验。然而出于开发和测试的需要，有它就足够了。这里会在后续的博文中介绍一下如何长时间存储会话信息。

Session的用途

当你想跨页保存用户的偏好时，可以用会话。会话最常见的用法是提供用户验证信息，你登录后就会创建一个会话。之后你就不用在每次重新加载页面时再登录一次。即便没有用户账号，会话也有用。网站一般都要记住你喜欢如何排列东西，或者你喜欢哪种日期格式，这些都不需要登录。

 

Cookie与Session的选择

如果可以选择，会话要优于cookie，大多数情况下，你可以用会话维持状态，一般来说这样做是明智的。并且会话更容易，你不用担心会滥用用户的存储，而且也更安全。当然，会话要依赖cookie。

尽管我建议你优先选择会话而不是cookie，但理解cookie 的工作机制也很重要（特别是因为有cookie 才能用会话）。它对于你在应用中诊断问题、理解安全性及隐私问题都有帮助。

 

 

参考：《Node与Express开发》—— [美] Ethan Brown 著，吴海星、苏文 译