Thanks. That sounds like a "no" for supporting my two use cases, unless the customer adds a trusted location or opens the SWF in the standalone player.
On Tue, May 25, 2010 at 12:45 PM, Oleg Sivokon <[email protected]>wrote: > > > OK, it's like this: > SWF launched in standalone player can interact with the system AND load > remote content, just like the browser can do the same thing. > SWF launched in browser plugin can only access permitted folders on your > hard disc. To allow access to the folder you should either use the web > interface (see my previous link), or read from the link Ami posted and try > to figure out how to do that on Mac (you are not required to use web > interface to establish local trust relationships between SWF and specific > locations in file system, it's just that, I simply don't know how to do that > on Mac...) > There's yet another option for launching a SWF - that's how I usually do > that - from the local HTTP server, in such case it acts more like as if it > was deployed to the actual server and all the following rules apply. I would > definitely recommend the later way of debugging as it is the most similar to > the live situation. > The loading of content other than SWF into another SWF is governed by > policy files aka crossdomain.xml. You need these files if you are loading > content from domains other than SWF origin. > The loading of other SWFs by SWF is governed by two things: > ApplicationDomain provided to the Loader when loading SWF with > LoaderContext - by default it won't allow crosscripting. > Security.allowDomain() doesn't define how classes are loaded into > application domain, however, should prevent security errors related to > crosscripting. > > Well, yes, it is complicated... > >
