Looks like you are not using ModuleManager. If you were, I would expect
SWFs from the internet are insecure as far as AIR is concerned so they will
be loaded into separate security sandboxes.
You can get the SWF as a bytearray via URLLoader and use loadBytes to get
around that, but then the SWF is not in the internet context.
Correct, I'm not using ModuleManager. Would using that allow me to place the loaded SWFs into the same security sandbox as the AIR app?
As tempting as loadBytes sounds, it opens up the AIR app to code injection, so it's not an option.
Here's what I'm trying to accomplish:
1) The AIR app needs to run on a client device (PC, Mac, Tablet, etc.)
2) The app needs the ability to load modules (external SWFs) that may be developed by a thrid party. This means that the modules must be able to be loaded into the AIR app without needing to recompile or repackage the app. Third-party developers would interact with the app using an API of sorts, while the AIR app's code remains proprietary.
3) The SWF modules must reside on a web server
4) The SWF modules must be able to access singletons used by the AIR app.
If anyone can recommend a good solution for this, I will buy you lunch
Flash/AIR security is all-or-nothing. If you allow an untrusted SWF to
access a Singleton, the untrusted SWF can scan the public properties and
call public methods in the Singleton, access other sub-objects referenced by
the Singleton, examine their public properties and methods, and potentially
mess with the app or steal important data.
So, if you have plans to trust the SWFs that much, loadBytes is not that
much further along the danger path.
Because of your requirement #3, the SWFs will be untrusted and therefore
cannot share class definitions so a Singleton in the main App will not be
the same Singleton in the SWF. The loadbytes trick is essentially copying
the SWF into the main app's memory. By doing so the SWF is no longer
considered to be from the domain it was served from and may have issues
accessing the server it came from which can be both a good thing and a bad
ModuleManager will not help. I was just making sure you weren't using
Modules as we know them in Flex.
The recommended way of dealing with your situation is to use the "Marshall
Plan". You can pass references to Singletons across the boundary and make
some assumptions and watch for changes and marshall those changes to the
Singleton on the other side. Basically, keeping two Singletons in sync by
sending messages across the sharedEvents dispatcher.
There are more details on the Marshall Plan on my blog and on the Adobe
Flex SDK Team
Adobe System, Inc.