This content has been marked as final. Show 5 replies
Which sandbox do you want the loaded SWFs to live in? Currently they're local, which isn't totally working out. It's hard to tell for sure, but I think they're in *different* local sandboxes, like one local-with-network and one local-with-filesystem, which would explain why the load works, but the content access throws an exception. I hope that's the issue; it'd be an easy fix.
It seems like they'd be great in the app sandbox, but there's a lot of work to do making that safe. See my blog for some more info -- http://weblogs.macromedia.com/emalasky/archives/2008/04/remote_plugins.cfm
If you'd rather that the file be local, but *act* as if they're still on the server, it's possible to put locally cached files in a remote sandbox. For HTML, it's really easy, see http://livedocs.adobe.com/air/1/devappshtml/help.html?content=AboutHTMLEnvironment_5.html . For SWF, it's still possible in AIR 1.0, but cross-sandbox communication (between your app and the cached, "remote" content) is a pain. You can do it by
(1)creating an HTMLLoader that loads an app HTML page (index.html), which in turn
(2)loads an HTML page (loader.html) which is
(3)remapped to a remote domain using sandboxRoot and documentRoot attributes in IFRAME, and also loads your SWF.
Three suggestions, depending on your desired sandbox and level of work desired. Hope that helps.
Adobe AIR Team
these docs these docs these docs
Well I too have run into these sandbox problems with AIR but am struggling to understand why ZoD's code would cause a security error.
From all I knew, any SWF loaded into an AIR app from app-storage would by default be in the "application" sandbox/domain. It appears this holds true for his first load.
So why is the Default.swf loading somesection.swf causing a security error? Default.swf is in application sandbox as is somesection!
Can anybody explain why this error is occurring or is it a bug?
Thanks for the responses...
The Default.swf is loaded into the localWithFile security sandbox, not the application sandbox, since it resides in the app-storage directory and not the app directory. When Default.swf loads Content.swf (also in app-storage), it also gets loaded into localWithFile sandbox (shown from trace(Secuirty.sandboxtype)).
The Content.swf file gets loaded fine. I can even do an addChild(loader), and the swf gets added to Default.swf.
The problem is if I try to do a addChild( loader.content ), for example. Thats when it throws the exception. This only happens if Main AIR file loaded Default.swf in the first place.
The "workaround" I have used is to first load Content.swf using URLStream, then reading the bytes into a byteArray. Then useing that ByteArray and doing a loader.loadBytes( ba, loaderContext ), passing in a loaderContext object that has the property allowLoadBytesCodeExecution = true. I feel this is too much of a hack though.
So, from my understanding...although Default.swf and Content.swf are in the same sandbox, they are running under the AIR application sandbox, which is why cross-scripting between Default and Content is not working....I think.
The Default.swf and Content.swf do not need access to the AIR API, but do need to communicate with each-other.
I'll give Ethan's suggestion a try (when his blog comes back online), and take a look at the HTML iframe extensions to see if thats what I need.
Well the only way I can see to let Default.swf and Content.swf communicate is to make use of LoaderInfo.[child|parent]SandboxBridge.
Please do read my blog when the server's back up. The loadBytes() "workaround" is exceedingly dangerous. To make it safe, there's a whole lot of extra work you'll need to do.
The fact that accessing Loader.content fails when both parent and child are in the same domain might be a bug. Can you file it?
If you don't need AIR APIs, and don't need those SWFs to even communicate back the AIR app (except maybe through LocalConnection), consider the domain-remapping option (3) I describe above. The local sandboxes are confusing in general, so putting files in the appropriate remote sandbox simplifies things.
For now, it's a weird dance to do the remapping for SWF, but I hope that'll be made simpler in a future release.
Adobe AIR Team