“引导” 将远程 swf 放入应用程序 SecurityDomain (actionscript3)
我的 Flash (AS3/AIR) 应用程序当前使用稍微不寻常的架构（对于 Flash 应用程序）来为运行时加载的内容提供特定的基类。 外部内容是通过“存根”基类发布的，在加载时，这些基类在运行时会被“真实”基类所掩盖。 我听说 Adobe 将其称为 bootstrapping (pdf)，到目前为止，它对我来说一直运行良好。 我相信它与 DLL 架构没有什么不同，尽管我没有资格肯定地说。
到目前为止，我一直在加载的外部内容是从同一个 SecurityDomain（同一个沙箱）中加载的，这使我可以轻松地加载子 ApplicationDomain 中的内容。 不幸的是，据我所知，跨 SecurityDomain 的 ApplicationDomain 无法关联 - 也就是说，我无法将一个 SecurityDom 的 AppDom 设为 AppDom 的子级来自另一个 SecurityDom。
但现在我需要从应用程序沙箱外部加载此外部内容。 有很多方法可以实现跨 SecurityDomain 的通信 - 尽管大多数方法都非常有限，但 AIR 的 sandboxBridge API 可能是最强大的。 不幸的是，这些通信方法都不允许我实现这种引导架构。
我注意到 LoaderContext 对象具有 securityDomain 属性，但 Flash 安全性禁止“本地 swfs”接触它（它会抛出 SecurityError 或类似的错误） ）。
Flex 的 SWFLoader 有一个 trustContent 属性，看起来很有希望，但我倾向于假设它与在中设置 SecurityDomain 具有相同的限制。 Loader 的 LoaderContext。
我怀疑我必须重新设计（这并不容易），但我想我只是在这里检查一下我在研究中没有遗漏任何东西。
那么……有什么想法或智慧吗？ 如果来自 Adobe 从事安全模型工作的人能够给出明确的“是/否，它可以/不能完成”，我会特别喜欢它......
提前致谢！
附录：我决定重新设计架构，以便引导全部发生在外部域上。 然而，出于好奇，我的问题仍然存在。
My Flash (AS3/AIR) application is currently using a slightly unusual architecture (for a Flash app) to provide particular base classes for loaded content at runtime. The external content is published with 'stub' base classes, which are eclipsed by the 'real' base classes at runtime when it is loaded. I've heard this referred to by Adobe as bootstrapping (pdf), and it has been working very well for me until now. It's not unlike a DLL architecture I believe, although I'm not qualified to say for sure.
Until now, the external content I have been loading has been loaded from within the same SecurityDomain (same sandbox), which allows me to easily load the content in a child ApplicationDomain. Unfortunately, as far as I can tell, an ApplicationDomains that span SecurityDomains cannot be related - that is, I cannot make an AppDom of one SecurityDom the child of an AppDom from another SecurityDom.
But now I need to load this external content from outside my Application sandbox. There are plenty of ways to achieve communication across SecurityDomains - although most of them are very limited, AIR's sandboxBridge API is probably the most powerful. Unfortunately, none of these communication methods allow me to achieve this bootstrapping architecture.
I notice that the LoaderContext object has a securityDomain property, but Flash security prohibits 'local swfs' from touching it (it throws a SecurityError or similar).
Flex's SWFLoader has a trustContent property that looks promising, but I'm inclined to assume that it has the same restrictions as setting the SecurityDomain in the Loader's LoaderContext.
I suspect I'll have to redesign (which won't be easy), but I thought I'd just check here that I've not missed something in my research.
So ... any ideas or pearls of wisdom? I'd especially freaking love it if someone from Adobe who works on the Security model could gimme a definitive "yes/no it can/can't be done"...
Thanks in advance!
Addendum: I've since decided to re-design the architecture so that the bootstrapping all happens on the external domain. My question still stands, however, out of curiosity.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从技术上讲，您的 AIR 应用程序是否可以简单地将外部 SWF 保存在您的应用程序目录中，并从那里加载它们，以便它们位于同一个安全沙箱中？
然而，有一些非常明显的原因导致这会是 Bad Karma，因此似乎任何解决方案都必然会提出这样的问题：尝试将本地应用程序内容和远程不受信任的内容放入同一应用程序域是否是正确的架构方法......？
Technically speaking, wouldn't it be possible for your AIR application to simply save the external SWFs inside your application directory, and load them from there so that they live in the same security sandbox?
However, there are some really obvious reasons why this would be Bad Karma, so it seems like any solution necessarily raises the question of whether trying to put local application content and remote untrusted content into the same app domain is the right architecture approach..?
在撰写本文时，我确定您无法将来自其他域的
ApplicationDomain加载到您自己的SecurityDomain中，即使使用 AIR 也是如此。我猜是故意设计的。
At the time of writing, I determined that you cannot load an
ApplicationDomaininto your ownSecurityDomainif it is from another domain, even with AIR.By design, I guess.