了解 Flash Player 10 文件上传安全模型
我一直在阅读有关 Flash Player 10 中文件上传的安全限制的信息。根据 关于 upload() 的 FileReference 文档，上传不必由用户启动的操作触发（browse() 可以，但那是另一个故事了）。如果确实如此，这将给多文件上传带来尴尬的用户体验，因为一次只能进行一个上传 - 因此用户必须为每个文件单击（或按下按钮）一次才能启动上传，但仅当上一个文件完成上传时。
在 Flash Player 10 及更高版本中，如果您使用多部分内容类型（例如 例如“multipart/form-data”），其中包含上传（由 POST 中“content-disposition”标头中的“filename”参数 body），POST 操作受应用于的安全规则约束 上传：
必须执行 POST 操作以响应用户启动的 操作，例如鼠标单击或按键。
这篇 Flash 安全文章证实了这一点URLLoader 文档（请参阅“POST API”部分）。
然而，原始白皮书没有说明这一点 - 只是 FileReference 浏览 必须响应用户启动的操作，而不是（可能由 URLLoader 驱动的）上传本身：
当 SWF 文件使用 FileReference.browse() 且 FileReference.upload() 方法将文件上传到服务器、Flash 玩家强制执行两条安全规则：
- FileReference.browse() 必须从用户事件处理程序（鼠标或键盘事件）中调用。
[...]
Flash Player 随时执行这些相同的规则 调用网络 API 来执行向服务器显示的 POST 包含上传。
据我从实际使用 URLLoader API 上传文件的情况来看，上传确实不需要来自用户启动的操作；但是，这是因为我使用的是播放器的调试版本，还是因为文档错误？ （或者其他什么？）
TL;DR：文档包含相互冲突的信息，并且我不相信我的现场测试（面对说它们不应该工作的文档）。 是否可以使用 URLLoader 在没有用户交互的情况下上传文件？还是仅使用 FileReference？ （这会杀死大多数文件预处理的可能性，这正是我感兴趣的事情！）
I've been reading about the security restrictions for file uploads in Flash Player 10. According to the FileReference docs for upload(), the upload does not have to be triggered by a user-initiated action (the browse() does, but that's another story). If it did, that would force an awkward user experience for multi-file uploads, since only one upload can occur at once -- so the user would have to click (or press a button) once per file to initiate the upload, but only when the previous file had finished uploading.
The documentation for URLLoader.load(), on the other hand, states:
In Flash Player 10 and later, if you use a multipart Content-Type (for
example "multipart/form-data") that contains an upload (indicated by a
"filename" parameter in a "content-disposition" header within the POST
body), the POST operation is subject to the security rules applied to
uploads:The POST operation must be performed in response to a user-initiated
action, such as a mouse click or key press.
This Flash Security article corroborates the URLLoader documentation (see the "POST APIs" section).
The original whitepaper, however, does not state this -- only that a FileReference browse must be in response to a user-initiated action, not the (potentially URLLoader-driven) upload itself:
When a SWF file uses the FileReference.browse() and
FileReference.upload() methods to upload a file to a server, Flash
Player enforces two security rules:
- FileReference.browse() must be called from within a user-event handler (mouse or keyboard event).
[...]
Flash Player enforces these same rules any time a
networking API is called to perform a POST that appears to the server
to contain an upload.
As far as I can tell from actual use of the URLLoader API to upload a file, the uploads indeed don't need to come from a user-initiated action; but, is this because I'm using a debug version of the player, or because the documentation is wrong? (Or something else?)
TL;DR: The documentation contains conflicting information, and I don't trust my field tests (in the face of docs that say they shouldn't work). Can URLLoader be used to upload a file without user interaction? Or only FileReference? (That would kill most file pre-processing possibilities, which is what I happen to be interested in doing!)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不会收到错误，因为您正在调试中运行。在进行我的速度测试项目时遇到了同样的问题。
因此，对于以下问题：
FileReference在没有用户交互的情况下无法上传文件。URLLoader如果您使用POST、multipart/form-data和文件名属性。如果您使用诸如
application/octet-stream之类的内容类型并将文件正文编码（例如采用 base64），则可以使用URLLoader上传文件发布请求。这意味着，如果您使用 PHP，那么您将不会使用$_FILES，而是使用$_POST数组来获取文件。在本地计算机上以调试模式工作，不会触发
URLLoader限制错误。You doesn't got errors, because you are running in debug. Got the same problem while working on my speedtest project.
So for the questions:
FileReferencecan't upload files without user interaction.URLLoadercan't upload files without user interaction if you are usingPOST,multipart/form-dataandfilenameproperties.You can upload files with
URLLoaderif you are using content-type likeapplication/octet-streamand putting the file body encoded (for example in base64) in you post request. That means, if you are using PHP, so you will work not with the$_FILES, but with the$_POSTarray, to get your file.Working in debug mode on local machine, won't trigger the
URLLoaderrestriction error.我相信 Adobe 希望拥有它，以便您不能使用 URLLoader 在没有交互的情况下上传文件。我只是认为他们碰巧没有以最好的方式做到这一点，你可以根据你使用 URLLoader 上传文件的精确程度来绕过它（如果你在 URLLoader 的 POST 中输入文件名，它应该会出错，但您可以通过 Base64 对文件进行编码并使用 URLLoader 将其发送到 php 来解决这个问题）。
请查看这篇文章。也阅读那里的评论，他们似乎解决了这个问题。希望这会有所帮助。
I believe that Adobe wants to have it so that you can NOT use URLLoader to upload a file without interaction. I just think that they happened to not do it in the best way and you can get around it depending on how exactly you are using the URLLoader to upload the file (if you put a filename in the POST for the URLLoader it should error out, but you can get around that by Base64 encoding the file and sending that with the URLLoader to php).
Take a look at this post. Read through the comments in there too they seem to address the issue. Hopefully this helps a little bit.