views:

1132

answers:

2

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.

+1  A: 

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

fenomas
Technically speaking, no: an AIR app can't modify its own application directory. AIR apps have a local storage folder for saving data, but again, that's a separate security domain.
aaaidan
But yeah, I totally agree about the bad karma thing. The flash security model has been devised by very smart people to enforce a collection of best practices so it is a bit silly to swim against the tide. In my defense, the external domain is "trusted" (w. airquotes) but that's not really the point.
aaaidan
Ahh... I know there are restrictions to an app modifying its app directory contents but I thought they were overridable. Given that, I don't know if your original aim is possible or not.
fenomas
Mmm. I have decided that it is not possible, since I can't find anyone/anything to tell me otherwise. If it is possible, I don't know how, so it's the same outcome either way! Thanks for the answer, fenomas.
aaaidan
Even if you are able to do it, modifying the app's folder can break other things ... one is the encrypted store, as soon as u touch one of the application files you don't get failures accessing the store.
eglasius
+1  A: 

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.

aaaidan