Cookie 与会话

新手上路,请多包涵

几个月前我开始使用 PHP。为了为我的网站创建登录系统,我阅读了 cookie 和会话及其差异(cookie 存储在用户的浏览器和服务器上的会话)。那时,我更喜欢 cookie(谁不喜欢 cookie?!),只是说:“谁在乎呢?我没有任何好的协议将它存储在我的服务器中”,所以,我继续使用 cookie我的本科毕业设计。但是,在完成我的应用程序的大部分之后,我听说对于存储用户 ID 的特殊情况,会话更合适。所以我开始思考,如果陪审团问我为什么使用 cookie 而不是会话,我会说什么?我有这个原因(我不需要在内部存储有关用户的信息)。这足以 作为一个理由 吗?还是不止于此?

您能告诉我使用 cookie 保存用户 ID 的优点/缺点吗?

感谢 StackOverflow 中的所有人!

原文由 Nadjib Mami 发布,翻译遵循 CC BY-SA 4.0 许可协议

阅读 515
2 个回答

这个概念是为 Web 访问者跨页面加载存储持久数据。 Cookies 将其直接存储在客户端上。会话使用 cookie 作为排序键,与存储在服务器端的数据相关联。

最好使用会话,因为实际值对客户端是隐藏的,并且您可以控制数据何时过期并变为无效。如果这一切都基于 cookie,则用户(或黑客)可以操纵他们的 cookie 数据,然后向您的站点发出请求。

编辑:除了简单之外,我认为使用 cookie 没有任何优势。这样看……用户有什么理由知道他们的ID#吗?通常我会说不,用户不需要这些信息。提供信息应限制在需要知道的基础上。如果用户将他的 cookie 更改为具有不同的 ID,您的应用程序将如何响应?这是一个安全风险。

在会议风靡一时之前,我基本上有自己的实现。我在客户端上存储了一个唯一的 cookie 值,并将我的持久数据与该 cookie 值一起存储在数据库中。然后在页面请求中,我匹配了这些值并拥有我的持久数据,而不让客户控制那是什么。

原文由 Fosco 发布,翻译遵循 CC BY-SA 3.0 许可协议

TL;博士

标准/因素会话饼干纪元(存在的开始)在 HTTP 响应之前创建在 HTTP 响应之后创建第一个 HTTP 请求期间的可用性是的不后续 HTTP 请求期间的可用性是的是的最终控制数据和过期服务器管理员最终用户默认到期比 cookie 更早过期持续时间比会话长服务器成本记忆记忆网络成本没有任何不必要的额外字节浏览器费用没有任何记忆安全难以劫持容易劫持弃用没有任何现在不赞成 JavaScript “Web Storage”

细节

优点和缺点是主观的。它们可能导致二分法(对某些人来说是优势,但对其他人来说是劣势)。相反,我在上面列出了可以帮助您决定选择哪一个的因素。

在第一个 HTTP 请求和响应期间存在

假设您是一个想要同时处理会话和 cookie 的服务器端人员。第一次 HTTP 握手将如下所示:

  1. 浏览器 准备 HTTP 请求-- SESSIONS: not available ;饼干: 不可用
  2. 浏览器发送 HTTP 请求
  3. 服务器收到 HTTP 请求
  4. 服务器 处理 HTTP 请求-- SESSIONS: exists ;饼干: 演员
  5. 服务器发送 HTTP 响应
  6. 浏览器收到 HTTP 响应
  7. 浏览器 处理 HTTP 响应-- SESSIONS: not available ;饼干: 存在

在第 1 步中,浏览器不知道会话和 cookie 的内容。在第 4 步中,服务器可以有机会设置会话和 cookie 的值。

后续 HTTP 请求和响应期间的可用性

  1. 浏览器 准备 HTTP 请求-- SESSIONS: not available ;饼干: 可用
  2. 浏览器发送 HTTP 请求
  3. 服务器收到 HTTP 请求
  4. 服务器 处理 HTTP 请求-- SESSIONS: available ;饼干: 可用
  5. 服务器发送 HTTP 响应
  6. 浏览器收到 HTTP 响应
  7. 浏览器 处理 HTTP 响应-- SESSIONS: not available ;饼干: 可用

有效载荷

假设在一个网页中加载 example.com 托管的 20 个资源,这 20 个资源将携带有关 cookie 的额外字节信息。即使它只是对 CSS 或 JPG 图像的资源请求,它仍然会在到达服务器的途中在其标头中携带 cookie。对 JPG 资源的 HTTP 请求是否应该携带一堆不必要的 cookie?

弃用

会话没有替代品。对于 cookie,在浏览器中存储数据 还有许多其他选项,而不是 老式的 cookie

存储用户数据

Session 存储用户数据更安全,因为它不能被最终用户修改,只能在服务器端设置。 另一方面,Cookie 可能会被劫持,因为它们只是存储在浏览器中。

原文由 Abel Callejo 发布,翻译遵循 CC BY-SA 4.0 许可协议

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
logo
Stack Overflow 翻译
子站问答
访问
宣传栏