什么是绕过IE文件下载安全规则的技术？ [英] What are techniques to get around the IE file download security rules?

问题描述

Internet Explorer（默认设置，我通常认为它将在Great Unwashed的桌面上生效）似乎不喜欢在HTTP响应中接受附件内容的想法，如果相应的请求不是直接来自用户操作（如单击处理程序或本机表单提交）。可能有更多的细节和细微差别，但这是让我感到沮丧的基本行为。

Internet Explorer (with default settings, which I generally assume will be in effect on the desktops of the Great Unwashed) seems to dislike the idea of accepting attachment content in an HTTP response if the corresponding request wasn't made directly from a user action (like a "click" handler, or a native form submit). There are probably more details and nuances, but that's the basic behavior that's frustrating me.

在我看来，这种情况很常见：一些可下载的用户界面内容—比如，准备好的PDF报告—允许在创建内容时使用一些选项和输入。现在，与允许用户规定应用程序如何执行某些操作的所有表单一样，输入可能是错误的。并非总是如此，但有时候。

It seems to me that this situation is common: the user interface in front of some downloadable content — say, a prepared PDF report — allows for some options and inputs to be used in the creation of the content. Now, as with all forms that allow the user to stipulate how an application does something, it's possible that the input will be erroneous. Not always, but sometimes.

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

Thus there's a dilemma. If the client tries to do something fancy, like run an AJAX transaction to let the server vet the form contents, and then resubmit to get the download, IE won't like that. It won't like it because the actual HTTP transaction that carries the attachment back will happen not in the original user-action event handler, but in the AJAX completion callback. Worse, since the IE security bar seems to think that the solution to all one's problems is to simply reload the outer page from its original URL, its invitation to the user to go ahead and download the suspicious content won't even work.

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

The other option is to just have the form fire away. The server checks the parameters, and if there's anything wrong it responds with the form-container page, peppered appropriately with error messages. If the form contents are OK, it generates the content and ships it back in the HTTP response as an attached file. In this case (I think), IE is happy because the content was apparently directly requested by the user (which is, by the way, a ridiculously flimsy way to tell good content from bad content). This is great, but the problem now is that the client environment (that is, the code on my page) can't tell that the download worked, so the form is still just sitting there. If my form is in some sort of dialog, then I really need to close that up when the operation is complete — really, that's one of the motivations for doing it the AJAX way.

在我看来，唯一要做的就是在表单对话框中添加类似于，下载开始时关闭此项。这对我来说真的很蹩脚，因为它是请按下我的按钮界面的一个例子：理想情况下，我自己的代码应该能够在适当的时候推动buutton。我不知道的一个关键问题是客户端代码是否有任何方法可以检测到表单提交导致附件下载。我从来没有听说过如何发现这种情况，但那会打破我的僵局。

It seems to me that the only thing to do is equip the form dialogs with messaging that says something like, "Close this when your download begins." That really seems lame to me because it's an example of a "please push this button for me" interface: ideally, my own code should be able to push the buutton when it's appropriate. A key thing that I don't know is whether there's any way for client code to detect that form submission has resulted in an attachment download. I've never heard of a way to detect that, but that'd break the impasse for me.

推荐答案

我接受它你提交的表格有不同的目标窗口;因此表格保持不变。

I take it you're submitting the form with a different target window; hence the form staying in place.

有几种选择。

1. Keep禁用提交按钮并在后台进行持续验证，轮询表单以更改字段，然后在字段更改时触发字段的验证请求。当表单处于有效状态时，启用该按钮;如果不是，请禁用该按钮。这并不完美，因为会有延迟，但对于你正在做的事情来说它可能已经足够了。


2. 做基本的验证，不需要往返到表单的提交事件的处理程序中的服务器，然后提交表单并将其删除（或者可能只是隐藏它）。如果服务器上的进一步验证检测到问题，它可以返回一个使用JavaScript的页面来告诉原始窗口重新显示表单。


3. 使用会话cookie和唯一表单ID（当前时间来自 new Date（）。getTime（）会这样做）;提交表单时，禁用其提交按钮，但保持可见，直到响应返回。使响应设置为具有指示成功/失败的ID的会话cookie。每隔一秒左右让窗口包含cookie的表单轮询，并在看到它时对结果进行操作。 （我从来没有做过最后一次;不是立即看到为什么它不起作用。）

1. Keep the submit button disabled and do ongoing validation in the background, polling the form for changes to fields and then firing off the validation request for a field as it changes. When the form is in a valid state, enable the button; when it isn't, disable the button. This isn't perfect, as there will tend to be a delay, but it may be good enough for whatever you're doing.
2. Do basic validation that doesn't require round-trips to the server in a handler for the form's submit event, then submit the form and remove it (or possibly just hide it). If the further validation on the server detects a problem, it can return a page that uses JavaScript to tell the original window to re-display the form.
3. Use a session cookie and a unique form ID (the current time from new Date().getTime() would do); when the form is submitted, disable its submit button but keep it visible until the response comes back. Make the response set a session cookie with that ID indicating success/failure. Have the window containing the form poll for the cookie every second or so and act on the result when it sees it. (I've never done this last one; not immediately seeing why it wouldn't work.)

我希望有大约十几种其他方法可以给这只猫留下光彩，但是有三种可以想到它。

I expect there are about a dozen other ways to skin this cat, but those are three that came to mind.

（编辑）如果你没有提交给不同的目标，你可能希望继续这样做 - 在同一页面上隐藏 iframe 。 （可能与上述或其他答案相结合）可能有助于您获得所需的用户体验。

(Edit) If you're not submitting to a different target, you might want to go ahead and do that -- to a hidden iframe on the same page. That (possibly combined with the above or other answers) might help you get the user experience you're looking for.

这篇关于什么是绕过IE文件下载安全规则的技术？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！