> Essentially, this trick makes remote content local. It can make remote > calls, but the headers will be the same as if you coded URLLoader in the > main AIR app not as if it was a web-app served by the domain's server.
If it means the loaded swf is perceived as or is in the local application sandbox / security context, I guess it can do the trick moving the rest of the code in a module downloaded by the loaded swf, thought ? Frédéric THOMAS > From: [email protected] > To: [email protected] > Subject: Re: [AIR - loadForCompatibility] > Date: Tue, 23 Sep 2014 20:46:11 +0000 > > > > On 9/23/14 1:20 PM, "Frédéric THOMAS" <[email protected]> wrote: > > >Hi Alex, > > > >Thanks for the trick but indeed I need to do remote calls, I hadn't got > >the use case with AIR before and wonder why the security is so strict > >relative to FP. > Yeah, I agree that AIR should allow whitelisting of remote domains, but I > think there is still fear of allowing "open" domains like FaceBook and > MySpace. > > Essentially, this trick makes remote content local. It can make remote > calls, but the headers will be the same as if you coded URLLoader in the > main AIR app not as if it was a web-app served by the domain's server. > > > > >IIRC, from a sandboxed untrusted child app, there's no way to use the > >main AIR app API, I can only send and receive simple data and events, am > >I wrong ? > Well, the communication mechanisms between sandboxes are things like > sockets and the shared event dispatcher. Only flash.*.* classes are > shared across the boundary. Flex SDK classes and your classes are not. > You can set up some fancy ways of transcoding data via those mechanisms, > but beware that the more general you make it, the more you expose yourself > to security issues. > > -Alex >
