绕过 IE 文件下载安全规则的技术有哪些？答案

【问题标题】：What are techniques to get around the IE file download security rules?绕过 IE 文件下载安全规则的技术有哪些？
【发布时间】：2010-01-14 14:47:01
【问题描述】：

如果相应的请求不是直接从用户操作（如“点击”处理程序或本机表单提交）。可能还有更多细节和细微差别，但这是让我感到沮丧的基本行为。

在我看来，这种情况很常见：一些可下载内容（例如，准备好的 PDF 报告）前面的用户界面允许在创建内容时使用一些选项和输入。现在，就像所有允许用户规定应用程序如何做某事的表单一样，输入可能是错误的。不总是，但有时。

因此存在两难境地。如果客户端试图做一些花哨的事情，比如运行一个 AJAX 事务让服务器检查表单内容，然后重新提交以获取下载，IE 不会喜欢这样。它不会喜欢它，因为带回附件的实际 HTTP 事务不会发生在原始用户操作事件处理程序中，而是发生在 AJAX 完成回调中。更糟糕的是，由于 IE 安全栏似乎认为解决所有问题的方法是简单地从其原始 URL 重新加载外部页面，它对用户继续下载可疑内容的邀请甚至都不起作用。

另一种选择是让表单消失。服务器检查参数，如果有任何错误，它会响应表单容器页面，并适当地添加错误消息。如果表单内容正常，它会生成内容并将其作为附件发送回 HTTP 响应中。在这种情况下（我认为），IE 很高兴，因为内容显然是由用户直接请求的（顺便说一句，这是区分好内容和坏内容的一种可笑的脆弱方式）。这很好，但现在的问题是客户端环境（即我页面上的代码）无法判断下载是否有效，因此表单仍然只是坐在那里。如果我的表单在某种对话框中，那么我真的需要在操作完成后关闭它——真的，这就是以 AJAX 方式进行操作的动机之一。

在我看来，唯一要做的就是为表单对话框配备类似“下载开始时关闭”的消息。这对我来说真的很糟糕，因为它是“请为我按下此按钮”界面的示例：理想情况下，我自己的代码应该能够在适当的时候按下按钮。我不知道的关键是客户端代码是否有任何方法可以检测表单提交导致附件下载。我从来没有听说过一种检测方法，但这对我来说会打破僵局。

【问题讨论】：

标签： javascript jquery internet-explorer

【解决方案1】：

我认为您正在使用不同的目标窗口提交表单；因此表格留在原地。

有多种选择。

保持提交按钮处于禁用状态，并在后台进行持续验证，轮询表单以查找字段更改，然后在字段更改时触发验证请求。当表单处于有效状态时，启用按钮；如果不是，请禁用该按钮。这并不完美，因为可能会有延迟，但对于您正在做的任何事情来说，它可能已经足够了。
在表单的submit 事件的处理程序中执行不需要往返服务器的基本验证，然后提交表单并将其删除（或者可能只是隐藏它）。如果服务器上的进一步验证检测到问题，它可以返回一个使用 JavaScript 告诉原始窗口重新显示表单的页面。
使用会话cookie和唯一的表单ID（new Date().getTime()的当前时间就可以了）；提交表单时，禁用其提交按钮但保持可见，直到响应返回。使响应设置一个会话 cookie，其 ID 指示成功/失败。每隔一秒左右让包含表单的窗口轮询 cookie，并在看到结果时对结果采取行动。（我从来没有做过最后一个；没有立即明白为什么它不起作用。）

我预计还有十几种其他方法可以给这只猫剥皮，但我想到了这三种。

（编辑） 如果您不提交到不同的目标，您可能希望继续执行此操作 - 到同一页面上的隐藏 iframe。这（可能与上述或其他答案相结合）可能会帮助您获得所需的用户体验。

【讨论】：

不，当您提交表单并且响应是附件（即要下载的文件）时，浏览器不会重新绘制页面。
最后一个看起来真是个好主意！我想知道如果下载失败，cookie 是否会成功设置。好主意，不管它是否有效！
@Pointy：啊，好吧，看起来确实有点奇怪。我认为这些基本想法可以适应您正在做的事情，但无需深入了解它......@Graza：这很好。如果它不起作用，我认为我不会称它为“出色”，但谢谢。 :-)
饼干的想法真的很棒，现在我已经让它穿透了我头部周围的停滞脂肪层。该技术应称为 Crowder Cookie Trick。
@Grae：我想出了这个答案——并立即转身在一个项目中使用它。工作一种享受。就我而言，当用户从服务器请求自定义 PDF 时，我使用此技术显示“正在构建...”模式对话框 (div)。表单提交到隐藏的 iframe，然后我的代码轮询 cookie。一切正常，回复Content-Disposition: attachment，弹出下载框；我的代码看到了 cookie 并关闭了模式。如果出现错误，我的代码会在 cookie 中看到错误并将其显示给用户。我真的必须用演示来写这篇博客。 :-)

【解决方案2】：

有很多非常好的理由 IE 这样做，我相信这不是任何人都会争论的事情 - 所以主要目标是以某种方式绕过它以使事情变得更好您的用户。

有时值得重新思考事情是如何完成的。也许禁用该按钮，使用 javascript 检查所有字段何时填写，并在填写完毕后触发 ajax 请求。如果 ajax 成功，则启用该按钮。这只是一个建议，我相信还会有更多......

编辑：更多...

进行简单的提交（非 AJAX），如果检查失败，返回一个页面而不是一个附件。发回的页面可能包含最初提交的所有信息（以及给用户的任何错误消息），因此用户无需再次填写整个表单。而且我也相信会有更多的想法......

编辑：更多...

我相信你以前见过这种类型的东西 - 是的，它是一个额外的点击（不理想，但不难）......“如果你的下载失败, 点击这里” -> 在这种情况下，随心所欲，但在 AJAX 返回时向页面添加一个新的链接/按钮，因此如果下载失败，他们可以从“直接用户操作”。而且我敢肯定我会想到更多（或者其他人会）.....

【讨论】：

嗯，我同意 IE 这样做是出于“好”的原因，但在很大程度上这些原因涉及其他系统软件不是很聪明。请注意，Firefox、Safari 和 Chrome 不存在此问题，据我所知，这不被视为重大安全漏洞。

【解决方案3】：

我一直在与类似的问题作斗争。就我而言，如果我的网络应用程序嵌入到另一个网站的 iframe 中（第三方 cookie 问题），则发布到隐藏的 iframe 不起作用，除非我们的网站被添加到受信任的站点列表中。

我发现我可以将下载分解为 POST 和 GET 序列。该帖子返回一个短暂的 GUID，可用于 GET 请求以启动下载。 POST 可以进行表单验证以及在成功响应中返回 GUID。客户端获得 GUID 后，您可以将隐藏 iframe 元素的 src 属性设置为下载 URL。浏览器看到 'Content-Disposition': 'attachment' 标头并为用户提供下载功能区以下载文件。

到目前为止，它似乎适用于所有最新的浏览器。不幸的是，它需要您修改服务器端 API 以下载文件。

【讨论】：

这很好用，但说真的，“cookie 技巧”是一种安全可靠的交互方式。
@Pointy 我真的很喜欢 cookie 技巧，我相信它对你很有用。我试过了，但就像我说的，当网络应用程序在第三方托管的 iframe 中运行时，我需要下载才能在 IE11 中运行。 cookie 部分有效，但如果我尝试将表单发布到隐藏的 iframe，IE 会吃掉下载功能区。 -- 我只是添加了我的答案，以防有人发现它有用。
是的，这可能会产生很大的不同。我的网站很普通。