当 IIS 设置为“集成 Windows 身份验证”时，Flex 中的文件上传
我有一个 Flex 应用程序，允许用户上传文件。 Flex 端使用 FileReference.upload 方法，该方法转到处理上传的 .aspx 页面。当我将 IIS 设置为集成 Windows 身份验证时，它只能间歇性地工作。也就是说，出于测试目的，我编写了一个单独的 aspx 页面来执行文件上传，并且这始终有效......不过，我想在漂亮的 Flex 应用程序中利用文件导入，而不是启动一个新的用于文件上传的网页。
在查看 IIS 日志时，我对正在发生的情况有一个假设，并且想知道是否有人完全理解为什么它只能间歇性地工作，并且可以确认或否认这一点：
- Flex 的 FileReference 上传功能会执行它在然后客户端向我的 .aspx 页面发起 POST 请求。当失败时，IIS 日志指出 IE 未传递凭据，因此拒绝请求，然后发送 401 响应。
- 即使我正在侦听 HTTP 状态代码（Flash bug？），我也没有在 Flex 端收到此 401 响应。
- 以某种方式立即发出新请求以再次执行上传（这不是我的代码）。我通过查看 IIS lgos 来推断这一点，它在上一个 POST 之后显示了第二个 POST，只是这次发送了用户凭据，但更关键的是，这次用户上传的文件没有上传。我通过以下事实推断这一点：IIS 日志显示已发布 0 个字节，而之前的 401 请求显示已发布大量字节。
当它确实工作时，发生的情况是 FileReference 发出的第一个 HTTP POST 请求恰好发送了 Windows 凭据，因此客户端不会受到质疑。
任何机构都可以提供有关如何在 IIS 中使用集成身份验证时使 FileReference.upload 持续工作的想法吗？
克里斯
I have a flex app that allows the user to upload a file. The flex side uses the FileReference.upload method that goes to an .aspx page that handles the upload. It works only intermittently when I have IIS set to integrated windows authentication. That said, for testing purposes,I wrote a separate aspx page that does a file upload and this always works....I'd like to leverage the file import,though, within the nice looking flex app and not kick off a new webpage for a file upload.
In looking at the IIS logs I have a hypothesis as to what's happening, and want to know if someone has full understanding as to why it may only intermittently work and can confirm or deny this:
- Flex' FileReference upload guts does whatever it does on the client then initiates a POST request to my .aspx page. On the times it failes, the IIS logs state that IE didn't pass the credentials so denies the request then sends a 401 response.
- I don't get this 401 response on the flex side even though I'm listening for HTTP status codes (flash bug?).
- A new request is somehow immediately made to perform the upload again (it's not my code). I'm inferring this by looking at the IIS lgos which shows a second POST right after the previous one, only this time the user credentials are sent through, but the kicker is that the file the user uploaded is not uploaded this time. I infer this by the fact that the IIS logs show 0 bytes are posted, whereas the previous 401 request show a lot of bytes are POSTed.
On the times it does work, what happens is that the first request for the HTTP POST the FileReference makes so happens to send the windows credentials along, so the client is not challenged.
Can any body give any ideas on how to get the FileReference.upload to consistently work when integrated authentication is being used in IIS?
Chris
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以通过始终将 FileReference.upload 上传到不安全的 aspx 页面来解决该问题。在上传之前在 remoting/http/webservice 中使用单独的调用来向服务器表明您要上传文件。让服务器将随机令牌传回客户端（并将令牌缓存在内存中）。然后将令牌作为 GET 变量与上传 URL 一起发送。您可以在服务器上验证令牌并通过令牌应用安全性。
这是一个很麻烦的解决方法，但是有效。当我们遇到 QuickTime 未使用相同会话凭据发出请求的类似问题时，我们已经这样做过。
You can workaround the problems with FileReference.upload by having it always upload to a non-secured aspx page. Use a separate call in remoting/http/webservice prior to the upload to indicate to the server that you want to upload a file. Have the server pass back a random token to the client (and cache the token in memory). Then send the token as a GET variable along with the upload url. You can validate the token on the server and apply security through the token.
It's a hacky workaround, but works. We've done this before when we had a similar problem with QuickTime not making requests with the same session credentials.