First off, wanted to report the sad news my blower’s dead; wrong mixture of gas & oil, piston’s busted or something.
Anyway, deploying a project yesterday and doing the unthinkable, loadMovie. A parent SWF loads a child SWF after a successful login. These child SWF’s are basically applications and the shell that loads them is just a security mechinism. We’re using Zinc, and we originally we’re just compiling this “shell” natively; so the EXE would be a small exe the user’s download to their computer, but the SWF’s remain on the server that the shell actually downloads, making it easier to keep up to date without having to distribute a new EXE since the shell just logs in and downloads SWF’s.
Anyway, during testing we kept getting security sandbox violations. I was extremely confused since Flash as a projector or SWF running on the desktop has free reign and can do anything it wants, when it wants. I figured maybe because the new Flashout (0.2.1.2) now hosts the Flash Player in a browser window, it’s bound by domain restrictions (even localhost).
…but a Zinc projector? It’s an exe right? Guess not. Even using the option of Zinc to merely load the SWF from a remote URL instead of compiling the SWF in didn’t work; same issue.
So, reading the docs found 2 good examples of when to use System.security.allowDomain for SWF’s loading SWF’s. Our’s was the 2nd, where a shell SWF loads other SWF’s into it, and wants to be able to interact with them; like set variables on it when it’s loaded, call methods, etc. So, we did:
System.security.allowDomain(_parent._url);
in the children SWF’s. You can be sure _parent’s already loaded (because the _parent loaded you), and the _url of the parent could change, but this is the exact way without hardcoding it. Works like a charm.
Still, I’m confused what Zinc is doing, making the SWF’s act like they are in a browser. As an exe, I am not held to the security sandbox.