Flex：加载用户无法访问的 XML 文件
我们有一个 Flex 应用程序，当前正在加载包含多项选择题数据的 XML 文件。我不希望用户能够通过 http 访问此文件，但如果我使用 HTTPService 加载该文件（我们当前正在做的事情），似乎我必须将 XML 文件放在 public_html 文件夹中我们的服务器。
是否有更好的方法来加载 XML 文件，以便用户无法在其活动查看器中看到它/通过 http:// 访问它
谢谢！
We have a Flex app that is currently loading an XML file that contains Multiple Choice Question data. I don't want a user to be able to access this file via http, but if I use HTTPService to load the file (what we're doing currently) it seems as though I have to place the XML file within the public_html folder on our server.
Is there a better way to load the XML file so that users wouldn't be able to see it in their activity viewer/access it via http://
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用服务和 Flex 应用程序之间的密钥来加密 XML 文件。
我不熟悉反汇编 Flex 应用程序有多么容易，但要小心，因为有人可能能够在解密后找到密钥字符串或 XML 数据（通过观察内存地址等）
如果您只是想阻止访问“appsite.com/data.xml”并抓取它，那么这会起作用。
我可能会推荐 Blowfish 作为首选加密算法。
谷歌搜索“flex blowfish”返回了这个网站，看起来它为 flex 提供了一个加密库。
http://www.insideria.com/2008/ 04/encryption-in-flex-application-1.html
其他一些建议（根据您需要的安全级别，加密可能甚至不值得）
您可以比较以下代理字符串请求者。让您的 Http 请求使用自定义用户代理。
提供一个简单的 POST 变量，除非设置它，否则会在 Web 服务上引发 403 错误。
提供
最后两个建议很容易解决，但如果您只是想拒绝临时用户，那应该足够了。正如我所说，这完全取决于您想要的安全级别。
You could encrypt the XML file using a secret key between your service and the flex application.
I'm not familiar with how easy it is to disassemble a flex application, but be careful, because someone probably will be able to find either the key string or the XML data after it has been decrypted (by watching memory addresses, etc.)
If you just wanted a deterrent from being able to go to "appsite.com/data.xml" and snagging it, this would work.
I might recommend Blowfish as the encryption algorithm of choice.
Googling for "flex blowfish" returned this site which looks like it provides an encryption library for flex.
http://www.insideria.com/2008/04/encryption-in-flex-application-1.html
A couple of other suggestions (depending on the level of security you need, encryption might not even be worth it)
you could compare the Agent strings of the requester. Make your Http request use a custom user agent.
Supply a simple POST variable that unless it's set, you raise a 403 Error on the web service.
These last two suggestions are EASY to get around, but if you're just trying to deny the casual user, that should be enough. Like I said, it's all about the level of security you want.