【问题标题】：Cookies vs. sessionsCookie 与会话
【发布时间】：2011-09-09 08:45:36
【问题描述】：

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

感谢 StackOverflow 中的所有人！

【问题讨论】：

这两种方法都存储数据。 Cookies 在客户端执行此操作，即在访问者设备的存储中。会话是一个聪明的“扩展”，因为它们只在客户端存储一个唯一的 ID，而在服务器端存储所有实际数据。当他们从客户端的 cookie 中接收到唯一 ID 时，他们就知道要在服务器上加载哪些数据。在大多数情况下，会话将是您所需要的。顺便说一句，您可以使用github.com/delight-im/PHP-Cookie 以更现代的方式管理两者。
顺便说一句，WordPress 核心几年前放弃了使用会话，现在使用solely cookies。有趣的。我想知道他们是否这样做是为了更容易在一组负载平衡的服务器上进行部署和/或减少由于会话垃圾收集而导致的随机注销。

标签： php session cookies

【解决方案1】：

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

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

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

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

【讨论】：

@JiminyCricket 我不认为这是真的......如果是这样，没有人会使用会话变量来存储当前登录的用户——每个人都会这样做。这将是一个巨大的安全风险。可以肯定的是，会话 ID 通常作为 cookie 存储在客户端计算机上，然后在服务器端与会话数据匹配。服务器通常不通过 IP 地址控制会话，而是通过 cookie 值。
我最近才再次开始只使用 cookie，纯粹是因为如果当前正在从同一个会话执行另一个会话，会话会使页面无法加载，除非您在需要时在每个页面前加上 session_write_close();它。滚动您自己的唯一 ID 并与普通 cookie 匹配并没有那么困难，并且让所有页面保持美观和活泼。
您认为我应该使用会话进行身份验证吗？它有任何安全风险吗？如果黑客试图更改他的 session-id，服务器将如何响应（假设猜测的 session-id 有效）？
使用会话然后2FA作为会话可以被劫持。

【解决方案2】：

实际上，会话和 cookie 并不总是分开的。会话经常（但并非总是）使用 cookie。

在此处的这些其他问题中，您的问题有一些很好的答案。由于您的问题是专门关于保存用户的 IDU（或 ID）的，我认为这与其他问题不太重复，但他们的回答应该对您有所帮助。

cookies vs session

Cache VS Session VS cookies?

What is the difference between a Session and a Cookie?

【讨论】：

【解决方案3】：

区分这两者的基本思路。

会话：

UID 存储在服务器上（即服务器端）
更安全（因为 1）
不能设置过期，当用户关闭浏览器时会话变量会过期。（现在它在 php 中默认存储 24 分钟）

Cookie：

UID 存储在网络浏览器（即客户端）
不是很安全，因为黑客可以访问并获取您的信息（因为 1）
可以设置过期时间（更多信息请参见setcookies()）

当您需要存储短期信息/值时首选会话，例如用于计算、测量、查询等的变量。

当您需要存储长期信息/值（例如用户帐户）时，首选 Cookie（这样即使他们关闭计算机 2 天，他们的帐户仍会登录）。我想不出很多关于 cookie 的例子，因为它在大多数情况下都没有被采用。

【讨论】：

请注意：这不是一个好的答案。一开始还不错，但会混淆事物并以虚假信息结尾。这不是会话与 cookie 的解释。这是会话与会话+会话 cookie 的解释。出于上述原因，单独使用 Cookie 并不受欢迎。出于上述原因，首选会话+会话 cookie。
另一个错误是您确实通过 PHP 配置影响了会话生命周期。
Sessions 仍然在用户浏览器上设置了一个cookie，所以这个服务器-客户端的解释是不准确的
会话到期可以由任何应用程序轻松设置。第三点是错误的。另外，您忘记了可以存储在 cookie 与会话中的数据量。这是更重要的一点
IDU 代表什么？

【解决方案4】：

SESSIONS ENDS WHEN USER CLOSES THEIR BROWSER,

COOKIES END DEPENDING ON THE LIFETIME YOU SET FOR IT. SO THEY CAN LAST FOR YEARS

这是您选择的主要区别，

如果你想让id被长时间记住，那么你需要使用cookies；否则，如果您只想让网站识别此访问的用户，那么会话就是要走的路。

会话存储在您的 php 服务器将生成的文件中。为了记住哪个文件是给哪个用户的，php 还会在用户的浏览器上设置一个 cookie 来保存这个 session 文件 id，以便下次访问时 php 会读取这个文件并重新加载 session。

现在 php 默认会在每个时间间隔清除会话，并且会话的命名约定使其自动过期。此外，一旦浏览器关闭或历史记录被清除，浏览器将不会保留保存会话 id 的 cookie。

需要注意的是，现在的浏览器还支持另一种存储引擎，例如 LocalStorage、SessionStorage 和其他 webdb 引擎，javascript 代码可以使用这些引擎将数据保存到您的计算机以记住您。例如，如果您在 Facebook 中打开 javascript 控制台并输入“localStorage”，您将看到 Facebook 用来记住您的所有变量，而无需 cookie。

【讨论】：

实际上，默认情况下，会话会持续到用户关闭浏览器，但是可以在 php.ini 文件中通过将 session.cookie_lifetime = 0 中的 0 更改为您的秒数希望会话持续，或使用 session_set_cookie_params()。
更多有用的信息，这样的问题得到了很多答案..太好了，再次感谢 DOK！
还要记住会话文件可以创建的单点故障。当最小的 dos 风格攻击通过代理、ip 切换器或僵尸发生时，会在您的服务器硬盘或 ssd 上创建一个会话文件。如果您无法跟上读写速度，您的网站将会崩溃。
任何人都可以说：“当用户关闭他的浏览器时会话结束” 1. 如果用户从页面导航 awya.. 然后在不关闭浏览器的情况下返回。 2. 如果他们打开了多个指向同一个站点的浏览器窗口/选项卡怎么办？在这种情况下，一些工作中的网络应用程序会感到困惑，但我不知道他们使用什么类型的 cookie。
@jcansell 好吧，cookie 不会被多个选项卡或导航混淆，在这种情况下，很可能这些 web 应用程序使用本地存储/会话存储来使用 javascript 保存数据

【解决方案5】：

当您将 #ID 保存为 cookie 以识别登录用户时，您实际上是在向用户显示与他们无关的数据。此外，如果第三方试图在他们的浏览器中将随机 ID 设置为 cookie 数据，他们将能够让服务器相信他们是用户，而实际上他们不是。那是缺乏安全感。

您使用了 cookie，并且正如您所说，您已经完成了大部分项目。此外 cookie 具有保留很长时间的特权，而会话结束得更快。所以会话在这种情况下不适合。实际上，许多著名和流行的网站和服务都使用 cookie，您可以长时间保持登录状态。但是如何使用他们的方法来创建更安全的登录过程呢？

这里的想法：您可以帮助您使用 cookie 的方式：如果您使用随机密钥而不是 ID 来识别登录用户，首先，您不会将您的主要数据泄露给随机用户，其次，如果您考虑到足够大的随机密钥，任何人都难以猜测密钥或创建随机密钥。例如，您可以在用户的浏览器中保存一个 40 长度的密钥，如下所示： "KUYTYRFU7987gJHFJ543JHBJHCF5645UYTUYJH54657jguthfn" 并且任何人都不太可能创建确切的密钥并伪装成其他人。

【讨论】：

很好的解释。我在令牌中使用 GUID 来识别单个用户。

【解决方案6】：

会话允许您像使用 cookie 一样存储单个信息，但数据存储在服务器而不是客户端上。

【讨论】：

【解决方案7】：

Session 和 Cookie 不一样。

会话用于存储来自网页的信息。通常网页没有任何记忆来存储这些信息。但是使用我们可以保存必要的信息。

但是 Cookie 是用来识别用户的。使用 cookie 我们可以存储数据。它是存储在用户网络浏览器中的一小部分数据。因此，每当用户下次浏览时，浏览器会将 cookie 数据信息发送回服务器以获取以前的活动。

致谢：Session and Cookie

【讨论】：

如果用户禁用 cookie 会怎样？ cookie如何识别用户？

【解决方案8】：

正如其他人所说，Sessions 很聪明，并且在向客户端隐藏信息方面更有优势。

但 Cookie 至少还有一个优势，您可以通过 Javascript 访问您的 Cookie（例如 ngCookies）。使用 PHP 会话，您无法在 PHP 脚本之外的任何地方访问它。

【讨论】：

你可以.. 当然不是直接的，但是你可以通过一些 ajax 请求访问它来返回会话数据的脚本。但我不确定你应该这样做。

【解决方案9】：

我会选择 Session，首先 session 比 cookies 更安全，cookies 是客户端站点数据， session 是服务器站点数据。 Cookies 用于识别用户，因为它是嵌入我的服务器和用户计算机浏览器的一小段代码。另一方面，Session 帮助您保护您的身份，因为 Web 服务器不知道您是谁，因为 HTTP 地址将状态 192.168.0.1 更改为 765487cf34ert8ded.....或其他数字借助 GET 和 POST 方法。 Session 将用户的数据存储在唯一 ID 会话中，即使用户 ID 也无法相互匹配。 Session 将单个用户信息存储在一个应用程序的所有页面中。 Cookies expires 是在 setcookies() 的帮助下设置的，而 session expires 没有设置它是在用户关闭浏览器时过期。

【讨论】：

【解决方案10】：

我个人同时使用 cookie 和会话。

Cookies 仅在用户点击“记住我” 复选框时使用。并且 cookie 被加密，数据仅在服务器上解密。如果有人试图编辑 cookie，我们的解密器能够检测到它并拒绝该请求。

我见过很多网站将登录信息存储在 cookie 中，任何人都可以简单地更改 cookie 中的用户 ID 和用户名来访问任何人的帐户。

谢谢，

【讨论】：

【解决方案11】：

会话是服务器上与 cookie 信息相关联的一组信息。如果您使用的是 PHP，您可以检查会话。保存_路径位置并实际“查看会话”。 cookie 是发送到客户端和从客户端返回的数据的 sn-p。 Cookies 通常用于促进会话，因为它告诉服务器哪个客户端处理了哪个会话。还有其他方法可以做到这一点（查询字符串魔术等），但 cookie 可能是最常见的。

【讨论】：

【解决方案12】：

简答

按优先级排序的规则：

规则 1. 永远不要相信用户输入：cookie 不安全。对敏感数据使用会话。
规则 2。如果用户关闭浏览器时必须保留持久性数据，请使用 cookie。
规则 3。如果用户关闭浏览器时不需要保留持久性数据，请使用会话。
规则 4。阅读详细答案！

来源：https://www.lucidar.me/en/web-dev/sessions-or-cookies/

详细解答

Cookies

Cookie 存储在客户端（在访问者的浏览器中）。
Cookie 不安全：读取和写入 Cookie 内容非常容易。
使用 Cookie 时，您必须根据欧洲法律 (GDPR) 通知访问者。
可以设置过期时间，但用户或浏览器可以更改。
用户（或浏览器）可以（设置为）拒绝使用 cookie。

会话

会话存储在服务器端。
会话使用 cookie（见下文）。
会话比 cookie 更安全，但并非无懈可击。
在服务器配置中设置了过期时间（例如 php.ini）。
默认过期时间为 24 分钟或浏览器关闭时。
当用户刷新或加载新页面时，过期时间被重置。
用户（或浏览器）可以（设置为）拒绝使用 cookie，因此拒绝会话。
从法律上讲，您还必须通知访问者获取 cookie，但尚不清楚缺乏先例。

适当的选择

会话使用 cookie！ 会话数据存储在服务器端，但 UID 存储在客户端的 cookie 中。它允许服务器将给定的用户与正确的会话数据相匹配。 UID 受到保护且难以破解，但并非无懈可击。对于敏感操作（更改电子邮件或重置密码），不要依赖会话和 cookie：请求用户密码以确认操作。

敏感数据绝不应存储在 cookie 中（电子邮件、加密密码、个人数据......）。请记住，数据存储在外国计算机上，如果计算机不是私人计算机（教室或公共计算机），其他人可能会读取 cookie 内容。

Remember-me数据必须存储在cookies中，否则当用户关闭浏览器时数据会丢失。但是，不要在“记住我”cookie 中保存密码或用户个人数据。将用户数据存储在数据库中，并将此数据与存储在 cookie 中的一对加密的 ID/密钥链接。

在考虑了前面的建议之后，以下问题终于可以帮助您在 cookie 和会话之间进行选择：

用户关闭浏览器时必须保留持久数据吗？

如果答案是是，请使用 cookies。
如果答案是否，请使用会话。

【讨论】：

谢谢帮助。

【解决方案13】：

Cookie 和会话用于存储信息。 Cookie 仅存储在客户端计算机上，而会话存储在客户端和服务器上。

会话

会话在服务器上的临时目录中创建一个文件，其中存储了已注册的会话变量及其值。在访问期间，该数据将可供网站上的所有页面使用。

当用户关闭浏览器或离开网站后会话结束，服务器将在预定时间后终止会话，通常为 30 分钟。

Cookie

Cookie 是存储在客户端计算机上的文本文件，用于跟踪使用情况。服务器脚本向浏览器发送一组 cookie。例如姓名、年龄或身份证号等。浏览器将此信息存储在本地计算机上以供将来使用。

当浏览器下次向网络服务器发送任何请求时，它会将这些 cookie 信息发送到服务器，服务器使用该信息来识别用户。

【讨论】：

【解决方案14】：

TL;DR

Criteria / factors	Sessions	Cookies
Epoch (start of existence)	Created BEFORE an HTTP response	Created AFTER an HTTP response
Availability during the first HTTP request	YES	NO
Availability during the succeeding HTTP requests	YES	YES
Ultimate control for the data and expiration	Server administrator	End-user
Default expiration	Expires earlier than cookies	Lasts longer than sessions
Server costs	Memory	Memory
Network costs	None	Unnecessary extra bytes
Browser costs	None	Memory
Security	Difficult to hijack	Easy to hijack
Deprecation	None	Now discouraged in favor of the JavaScript "Web Storage"

详情

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

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

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

浏览器准备 HTTP请求 -- 会话：不可用； COOKIES：不可用
浏览器发送 HTTP 请求
服务器收到 HTTP 请求
服务器处理 HTTP请求 -- SESSIONS: existed;饼干：演员
服务器发送 HTTP 响应
浏览器收到 HTTP 响应
浏览器处理 HTTP响应 -- 会话：不可用； COOKIES：存在

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

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

浏览器准备 HTTP请求 -- 会话：不可用； COOKIES：可用
浏览器发送 HTTP 请求
服务器收到 HTTP 请求
服务器处理 HTTP请求 -- SESSIONS: available; COOKIES：可用
服务器发送 HTTP 响应
浏览器收到 HTTP 响应
浏览器处理 HTTP响应 -- 会话：不可用； COOKIES：可用

有效载荷

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

弃用

会话没有替代品。对于cookies，there are many other options在浏览器中存储数据而不是old school cookies。

用户数据的存储

Session 存储用户数据更安全，因为它不能被最终用户修改，只能在服务器端设置。 Cookies on the other hand can be hijacked 因为它们只是存储在浏览器中。

【讨论】：

【解决方案15】：

Session 和 Cookie 的主要区别在于 Session 数据存储在服务器上，而 Cookies em> 将数据存储在访问者的浏览器中。

Sessions 比 Cookies 更安全，因为它存储在服务器中。

Cookie 中存储的数据可以存储数月或数年，具体取决于 Cookie 的寿命。但是当浏览器关闭时，Session中的数据会丢失。

【讨论】：