Sorry :) That seems to happen a lot with my topics. Use case 1: Customer (a sales engineer) accesses a demo that is hosted on the web like any other Flex app. This demo makes no api calls, but does need to access an XML config file that lives in a data folder beside the SWF
Use case 2: Sales engineer has a copy of the entire directory (swf, wrapper html, config file) and runs it locally I think your second point confirms that to support both use cases with one version of the application, the customer would have to add a trusted location so that the app could get to the config. That may be fine, I would have to check. Since this is all read-only stuff, I would have hoped I could do it with one SWF and no user-intervention, but I imagine there are good reasons for these restrictions. On Tue, May 25, 2010 at 3:26 PM, Alex Harui <aha...@adobe.com> wrote: > > > I got lost trying to follow this topic. Whether it is browser or > standalone shouldn’t matter. What matters is the url of the SWF (file://or > http://), the trust file settings on the computer, the use-network flag, > and how you access the external resources. > > If you build a SWF to run locally then it cannot access the network. > If you build a SWF to access the network, it cannot access the local files > unless trusted. > Even if trusted, you may run into issues using certain file paths. Be sure > to use relative paths to subfolders of the trusted folder. > > > On 5/25/10 2:42 PM, "Richard Rodseth" <rrods...@gmail.com> wrote: > > > > > > > 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 <olegsivo...@gmail.com> > 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... > > > > > > > > > > > -- > Alex Harui > Flex SDK Team > Adobe System, Inc. > http://blogs.adobe.com/aharui > >
