Javascript 源映射HTTP请求不发送cookie头

关于源代码映射，我在chromium（build 181620）中遇到了一个奇怪的行为。 在我的应用程序中，我使用缩小的jquery，登录后，我开始在服务器日志文件中看到对“jquery.min.map”的HTTP请求。这些请求缺少cookie头（所有其他请求都可以）。 这些请求甚至没有在开发人员工具的net选项卡中公开（这对我来说并没有多大问题）

关键是，这个应用程序中的js文件应该只对登录的客户端可用，所以在这个设置中，源映射要么无法工作，要么我必须将源映射的位置更改为公共目录

---

我的问题是：这是一个期望的行为（意味着源映射请求不应该发送cookie）还是Chromium中的一个bug？

字符串检查器FrontEndHost:：loadResourceSynchronously（const String&url）实现，它被调用用于加载sourcemap资源，使用

donotAllowStoredRedentials

标志，我相信这会导致您观察到的行为

这种方法具有潜在的危险性，因此我们（您）可以使用此标志，以确保安全并避免泄漏敏感数据

---

作为补充说明，在生产环境中部署

jquery.min.js

时，仅将

jquery.min

发送给登录用户（即，不是来自无cookieless域）不是一个很好的主意。我我不确定你的想法，但如果你确实需要避免将文件交给不访问你网站的客户，您可以求助于检查

Referer

HTTP请求头。

我遇到了这个问题，并开始好奇为什么某些身份验证cookie没有在.js.map文件的请求中发送到我们的应用程序

在我使用Chrome 71.0.3578.98进行的测试中，如果cookie设置为

strict

或

lax

，Chrome在请求.js.map文件时将不会发送该cookie。当没有

sameSite

限制时，将发送cookie

---

我不知道预期行为的任何规范。

谢谢你的回答，我只是想确定这种行为是故意的。我知道从cookieless域提供静态文件会更好，但在本例中，jquery只是一个示例，不需要以这种方式提供。我们只需要为公司客户保护我们自己的脚本，这样我们就不会向外界公开任何特定于客户的内部内容。顺便说一句，检查推荐人不是我们想要的那种安全级别。好吧，我现在明白了。解决这个问题的一个方法可能是通过模糊性实现安全性：在资源名称中使用随机的多位Base36（或其他）字符串化值，这应该是绝对不可能猜到的。它们将仅通过编译的JS源代码可用，该源代码将受登录保护。请注意通过模糊性方法实现安全性-除非您使用https，否则任何人都可以通过嗅探流量获取URL。此外，我不认为传递cookie有多危险：脚本可以命中它想要的任何域，它将发送cookie。@zaius：（a）你关于嗅探的说法是正确的；当我提出这个建议时，我想到的是“无关联”的人。如果他们进行有针对性的攻击，他们肯定能做到。OTOH，如果不是通过https传输，他们可以嗅探脚本内容。（b） 是的，脚本可以，但是如果devtool被黑客攻击，后果可能会非常严重（虽然我并不是说他们会这样：）。映射文件本身并不包含代码，所以将它们放在公共目录中不应该是一个安全问题。我只想澄清我观察到的行为是否是故意的，这似乎是故意的