Question

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.

Was it helpful?

Solution 2

At the time of writing, I determined that you cannot load an ApplicationDomain into your own SecurityDomain if it is from another domain, even with AIR.

By design, I guess.

OTHER TIPS

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..?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top