M. *_*FAN 4 javascript cookies session-cookies
我正在从事一个业余爱好项目。该项目基本上是一个可集成的实时支持服务。为了方便地描述我的问题，我将致电我的服务service.com并致电使用我的服务的网站website.com。我正在考虑实施会话管理来恢复断开连接的访客聊天。为此，我计划使用基于 cookie 的会话管理。如果所有者website.com想要使用我的服务，我将为他们提供一个 JavaScript 文件，该文件将在正文中注入一些 HTML，在头部注入样式标签并实现交互。所有website.com要做的就是导入该 JS 文件并调用该 JS 文件定义的函数。website.com要在我的Cookie 上设置第 3 方 Cookie，service.com我将使用此请求/响应。当website.com从 请求我的 JS 文件时service.com，我的服务将使用 JS 文件和 cookie 来响应请求，以管理访问者的会话。这种方式将为的访问者service.com设置第 3 方。website.com
第一个问题：在 的访问者上设置 cookie 的这一阶段可以website.com在前端使用请求的 JS 文件或本地（从 的website.comWeb 服务器）请求的 JS 文件完成吗？那是否仍然是第 3 方 cookie，因为它会设置在 的前端website.com？
第二个问题：我的另一个问题是关于 cookie 同意的。service.com在其他网站（例如）上设置第 3 方 cookie（例如website.com）的网站是否可以要求允许他们的 cookie website.com？换句话说，我可以要求website.com访问者仅允许service.com使用我提供/提供的 JS 文件设置的第 3 方 cookiewebsite.com吗？这合法吗？
第三个问题： cookie 同意横幅在幕后如何工作？当您接受/拒绝网站上使用的所有第 3 方 cookie 时会发生什么？或者当您过滤并仅接受其中的一些时会发生什么？允许/禁止的过程如何进行？当您单击“接受”按钮或“拒绝”按钮时是否会触发某种 JavaScript？您可以向我提供有关此主题的任何资源。
谢谢！
website.com 所要做的就是导入该 JS 文件并调用该 JS 文件定义的函数。要从我的 service.com 在该 website.com 上设置第 3 方 cookie，我将使用此请求/响应。当 website.com 向 service.com 请求我的 JS 文件时，我的服务将使用 JS 文件以及 cookie 来响应请求，以管理访问者的会话。这样，service.com 将在 website.com 的访问者上设置第 3 方。
如果“请求/响应”是指对 service.com 的 http 请求，该请求将使用存储在 website.com（客户域）下的 cookie 进行回复...这不适用于 http cookie，因为您只能阅读在您的域名空间内设置 cookie。即对 api.foo.example.com 请求的响应可以在以下位置接收和设置 cookie：
但不包括 cookie www.example.com。
因此，如果从 website.com 到 service.com 的请求... service.com 只能在 service.com 下设置 cookie。在这种情况下，这些被称为“第三方 cookie”，因为“第一方”是 website.com，而您的 service.com 是第三方（网站访问者正在与 website.com 进行交互）。许多浏览器（safari、firefox）默认阻止第三方 cookie。
要解决此问题并拥有更可靠的 cookie（即使您仅将其用于会话而不是多次访问 website.com），您有两种选择：
客户白标 DNS。 客户创建 DNS 记录 livechat.website.com 和 CNAME 到 api.service.com。然后 api.service.com 通过 livechat.website.com 域处理流量，并可以在那里读取/设置 cookie。然而，这需要客户方面进行更多的技术连接，因为除了添加脚本标记之外，还涉及添加 DNS 记录。
JavaScript cookie。 从 service.com 返回的 javascript 不是在来自 service.com 的 http 响应中设置 cookie，而是在 website.com 域中运行，因此可以设置 javascript cookie以及读取该域下的 cookie（只要它们不存在） t 使用httponly选项设置）。js-cookie如果您不想在针对本机浏览器 document.cookies API 进行编码时担心跨浏览器问题，请查看库。
如果您不执行上述操作之一，您在响应 service.com 请求时设置的 cookie 将是第三方 cookie，并且可能无法一致工作。
...是通过 http 响应标头设置的 cookie set-cookie，并且只能为所请求的主机的域名称空间设置。如果此主机（带有子域的完整域名）与用户地址栏中的域不同，则这被视为第三方 cookie 并受到一些限制。
如果客户将其域下的 DNS 记录指向您的服务，您可以将第一方 http cookie 设置为第三方。
是由 javascript 在页面内设置的 cookie。他们可以在 javascript 运行的框架的域/命名空间内设置 cookie。他们可以从该域/命名空间读取 cookie，只要它们没有设置httponly选项（通常这样做是为了防止第三方 javascript 劫持会话 cookie）。
您可以通过将 javascript cookie 加载到适当域的框架中来使用第三方 cookie。
您可能还想阅读内容安全策略，如果客户使用 CSP 锁定其站点，该策略可以阻止您的第三方 javascript 作为客户部署文档的一部分运行。
http cookie 和 javascript cookie 之间的区别在于它们的设置方式。
http cookie由服务器设置 http 响应标头来设置set-cookie: name=value。
A cookie是通过在浏览器（即“客户端”）中运行的javascript调用标准浏览器API来设置的cookies.set()。
如果 cookie 设置正确（未过期等）并且“粘住”（即未被 CSP 或其他内容阻止）...那么该 cookie 将可用
cookies.get()（如果 cookie 未指定为HttpOnly（如果出于安全原因Cookie: name=value。请注意，cookie 并不总是被发送。Cookie 的范围可以限定为域和路径（文件夹）。cookie 可以指定为安全，在这种情况下，它将仅在 https 请求上发送，而不会在 http 请求上发送。
在隐身模式下，第三方 cookie 通常会默认被阻止，因此即使它们存在，也可能无法发送到服务器或可供 JavaScript 使用。我还遇到了奇怪的问题，第三方 cookie 不会显示在 chrome devtools 网络请求标头中，即使它们是由服务器发送和接收的。
在 website.com 的访问者上设置 cookie 的这个阶段可以吗？
使用请求的 JS 文件在前端完成
是的，这是 javascript cookie。往上看。
或本地（从 website.com 的网络服务器）请求的 JS 文件
不确定你的意思。website.com 网络服务器可以托管/代理您的 js 文件，但这只是静态文件服务，因此它并不能真正帮助您处理会话 cookie 逻辑。
客户可以托管您的 api 代理，其中包括在您的响应中重写 cookie 标头，使其成为第一方。虽然技术上可行，但这过于复杂，我不推荐这样做。只是表明很多事情都是可能的。
当然，你可以想出很多解决方案。例如，您的客户可以托管一个非常简单的 Web 应用程序，该应用程序可以根据需要处理读取/设置 cookie，以响应 JavaScript 请求。即客户在其域下托管您构建的一个小应用程序，以便读取/设置某些 http cookie 并提供此信息以响应来自您的 javascript 的 API 调用。不过，我认为这需要在客户端进行比自定义 DNS（上面）选项更多的技术集成。
我建议您坚持以下其中一项...
在其他网站（例如 website.com）上设置第 3 方 cookie（例如 service.com）的网站是否可以请求允许在该 website.com 上使用他们的 cookie？
所有这些 cookie 同意均来自两项相关法规。欧盟的 GDPR 和加利福尼亚州的 CCPA。
您看到的大多数 cookie 弹出窗口都与 GDPR 相关，并且遵循由互联网广告局 (IAB) 管理的名为透明度同意框架 (TCF) 的标准。提供 cookie 弹出功能的技术方在 TCF 规范中称为同意管理平台 (CMP) 。它们位于网站（又名“发布商”）和可能想要对该网站上的访问者数据（cookie 或其他方式）执行某些操作的各种第三方供应商之间。供应商/cookie 被分为“目的”，允许访问者同意一种类型的数据使用，但不能同意另一种类型的数据使用。有必需的 cookie（网站正常运行所需的...如登录 cookie）以及分析、营销和其他类型的目的。如果您想了解这些人（出版商 - CMP - 供应商）如何工作的所有技术细节，请随意阅读规范。
但长话短说，您不会从 cookie 弹出窗口中请求任何内容，您的公司已注册作为供应商参与规范，然后 CMP 可以将您添加到访问者可以同意的网站上的第三方供应商列表中到。作为个人爱好项目，组建公司并加入 TCF 框架可能超出了您目前想做的事情。但如果您的 cookie 需要披露，网站通常可以手动将您添加到其 cookie 披露中。
这仅在欧盟（以及加利福尼亚、加拿大）需要，如果您没有上述客户/用户，您可能不需要担心这一点。
您的实时聊天将属于网站所需/功能性 Cookie 的范围，以便使网站的实时聊天功能正常工作...因此，只要您小心数据收集/存储位置/处理...您可能也可以在欧盟运营没有问题，并且不需要任何特殊的额外 cookie 同意，因为您可以属于网站所需/功能 cookie 的范围。将数据处理和隐私责任交给 website.com。
最好使用带有 DNS 选项的会话 cookie（在 website.com 域下）。不要在会话恢复之外跟踪用户，也不要将任何敏感数据放入将跨会话保留的 cookie（或本地存储）中。
如果您打算将聊天日志存储在自己的服务器上，那么当用户向支持代理提供个人数据（电话号码、姓名、地址等）时，您获取个人数据的风险很高。就法律要求和披露而言，这很快就会变得棘手。如果您不是公司，那么由于缺乏数据安全/隐私责任，在欧洲开展业务的合法公司都不会使用您的实时聊天。
理想情况下，欧盟访问者使用欧盟的服务器，以避免在未经同意的情况下无意中将数据传输到国外（即使是短暂的）。
不要在您的 service.com 服务器上记录任何个人身份信息、用户 ID 等。只需记录聊天 ID、开始/结束时间、代理 ID、主题和计费所需的其他统计信息...但不记录任何有关访客的信息。如果要记录 IP 地址，请截断最后一个八位字节（或将其设置为 0）以半匿名化 IP。
制作一份隐私解释“一张纸”，从技术上解释您如何避免接触（或保留）任何潜在的敏感数据（“设计上的隐私”），并将其包含在您的营销材料中，因为它将有助于缩短潜在客户的任何询问法律团队。
Cookie 同意横幅在幕后如何工作？
大多数大公司都使用合法的 cookie 同意横幅来实施TCF框架（政策和技术规范）。所有技术规格均在该网站上公开（对于供应商的 CMP 等）。实现 TCF 支持的 cookie 同意供应商通常也添加了对 CCPA 规则的支持。加拿大现在也采用了欧盟的 TCF，以使事情变得更简单。不过，您也可以手动添加到大多数 Cookie 弹出窗口中。
您不能仅通过回调集成到 TCF 中。那样不行。您需要注册才能作为供应商参与该框架。然后，您可以调用 CMP 提供的特定 API 函数来检查访问者是否已提供同意，以及您（作为第三方供应商）是否已收到针对任何特定目的以及哪些目的的同意。
Cookie 同意提供商通常为网站提供手动（或通过爬虫自动）添加和声明 TCF 框架（以广告为重点）范围之外的其他供应商/Cookie 的功能。如果需要，这将适用于您。
一些 cookie 同意提供者会复制/删除/解析页面，以阻止第三方脚本的触发，然后重新注入经过修改的页面。我不是粉丝，因为这可能会导致奇怪的行为。一些提供商还用于MutationObserver监视正在加载的第三方内容。常见/手动情况是使用数据属性手动修改第三方 iframe/javascript/image/etc html 标签，以便将其标记为 cookie 同意...并防止加载（即移动src不同的属性，以便标签不会加载）负载）。如果给予同意，则 cookie 同意库可以更新这些元素以进行加载。
然而，正如我在问题 2 的答案中提到的，如果你小心的话，你可能不需要担心这一点。
一些网站推出了自己的 cookie 同意小部件，因为它们太小，无法处理完整 CMP 的复杂许可，而且它们需要披露的第三方供应商通常非常有限（可能只是谷歌分析、谷歌广告和 Facebook 再营销像素） ）。如果这些代码构建得很好，应该可以阻止加载任何第三方 javascript（或其他 http 调用），直到获得同意（或拒绝）为止。
我几年前构建的一个使用谷歌标签管理器（同意后）来管理使用 GTM 触发器加载的内容。在收到用户的信号之前，我们不会加载 GTM。在我们启动 GTM 之前，我们会向数据层添加同意信号，指示用户已同意（或不同意）的目的（功能/分析/营销）。如果用户之前访问过该网站，则会从 cookie 加载之前的同意，因此该小部件不会再次弹出。如果同意披露详细信息（供应商、目的）发生变化，所有用户都会再次收到弹出窗口。一年过去后，他们也会收到弹出窗口。无论如何，在 GTM 中，我们设置了触发器，以便只有在获得适当的同意后才会触发标签。功能/必需 cookie 始终在 GTM 外部加载。如果我们没有任何分析或营销许可，那么我们根本不会加载 GTM，从而为“无”访问者加快网站速度。 GTM在某些时候还添加了特定于同意的功能。
TCF 的工作方式相反，大多数供应商总是会加载，但他们应该“自我管理”自己，并检查来自 CMP 的信号，无论他们是否同意......这意味着他们的代码必须进行广泛修改以支持什么在不同意设置/读取 cookie 的情况下处理请求（例如）。供应商可能会为了一个目的而获得同意，但不会为另一个目的获得同意……所以他们的代码必须尊重这一点。如果供应商有许多不同的 cookie 和用途，事情就会很快变得复杂。遵守该政策是供应商在加入 TCF 框架时同意的一部分。由于比利时数据保护局的裁决， TCF 目前也面临着一些重大挑战对 TCF 执行隐私立法有效性的但这又是另一回事了。要点是：对 cookie 单击“否”并不一定意味着 TCF 世界中运行的网络请求或 JavaScript 会减少。
如果您仔细考虑存储（不存储）哪些数据并将您存储的内容保留在客户域下，那么您可能不需要担心 cookie 弹出窗口作为功能性 cookie。
如果您决定基于聊天数据（例如 disqus 风格）构建业务模型，那么您需要做更多的事情来遵守法律并让大客户的法律/隐私团队放心。
其他一些 cookie 弹出窗口是纯光学的。旧网站有大量手动添加的脚本标签并且没有标签管理。从技术上来说，要遵守规定对他们来说是一场噩梦。因此，他们添加了一个小部件，使其看起来像是合规的，但幕后没有任何变化。这些通常是小型网站，几乎没有收入，因此他们认为欧洲 DPA 永远不会费心去追捕他们……然而，专业律师事务所拥有机器人和信件生成工具来自动处理大规模骚扰，这只是时间问题。长尾网站。目前的主要问题是这些律师事务所如何获得报酬，但如果他们能够设法协商 DPA 罚款的一定比例，以提供执法即服务……那么这将成为一件大事。
| 归档时间： |
|
| 查看次数： |
3786 次 |
| 最近记录： |