哪些因素影响IE决定是否发送跨域cookie？
致力于对第三方使用的接口进行故障排除。快速概述：
- 第 3 方将用户发送到我们的网站
example.com/login，让用户向我们进行身份验证。 - 登录后，我们将用户重定向回
thirdparty.com - < code>thirdparty.com 使用我们网站上的动态 JS 文件，用于返回有关登录用户的信息
example.com/dynamicJs.js- 由于此请求是针对
example.com发出的，因此它应该包含登录期间删除的 Cookie（它们是实现其目的所必需的） - 对于 IE，它们不再包含在请求中
- 由于此请求是针对
研究中：
- cookie 本身似乎没有改变，手动将 IE 导航到
dynamicJS.js的 URL 会导致正在传输必要的cookie。 example.com已制定 P3P 策略，并且不会使用 IE 生成任何可见的警告/错误- 其他浏览器包含 cookie
那么，还有哪些其他变量可能会影响 IE 并导致其忽略 示例加载 cookies？example.com/dynamicJS.js 时使用 .com
Working on troubleshooting an interface consumed by 3rd parties. The quick overview:
- 3rd party sends the user out our site
example.com/loginto let the user authenticate with us - After signin we redirect the user back to
thirdparty.com thirdparty.comconsumes a dynamic JS file on our site used to return information about the logged in userexample.com/dynamicJs.js- Since this request is made against
example.comit should include the cookies dropped during login (they are required for it to serve its purpose) - for IE, they are no longer being included in the request
- Since this request is made against
In researching:
- the cookies themselves don't appear to have changed, and manually navigating IE to the URL of
dynamicJS.jsresults in the necessary cookies being transmitted. example.comhas P3P policies in place and is not generating any visible warnings/errors with IE- other browsers include the cookies
So, what other variables could be influencing IE and resulting in it omitting the example.com cookies when loading example.com/dynamicJS.js?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
经过大量研究，我们发现问题的根源在于 IIS 的自定义 HTTP 响应标头。
之前我们已将站点配置为返回
P3P标头，但在诊断此问题时，我们发现标头现在以3P的形式返回。将密钥返回到P3P解决了问题。在研究此更改的实际原因时，我们发现错误标头起源于
web.config，但是它似乎在一段时间前就被放置在那里并保持休眠状态，直到应用程序池被停止/重新启动进行维护。After much research we identified the root of the issue was within IIS's Custom HTTP Response Headers.
Previously we had configured the site to return a
P3Pheader, but in diagnosing this issue we found that somehow the header was now being returned as3P. Returning the key toP3Presolved out issue.In researching the actual cause of this change we found that the bad header originated in the
web.config, within the<httpProtocol><customHeaders>element -- however it appeared to have been placed there some time ago and remained dormant until the AppPool was stopped/restarted for maintenance.