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.
Maybe Zinc is actually running the swf in a window that uses a plugin. This could be the way they get the extra window functionality. Here where I work we use IE as the container for our installed apps. You wouldn’t know it just be looking at it. We have apps that driven by dhtml and some that are in flash using fscommand to talk to the container window.
Kenny Bunch just told me that it’s using the ActiveX control, and since the ActiveX control respects the security sandbox, that’s why.
If I’m not mistaken Zinc is an exe wrapper for the ActiveX plugin which may be the reason you’re getting the behavior. Anyway, I’ve found the forums at multidmedia.com generally pretty helpful in the past.
Brentholio
Hello Jesse,
yes, security restriction are still valid even if target movie is an .exe. It restricts if and how loaded movie can access parent movie functions and variables. Today we found that it also restrict how loaded movie can access local content with methods of XML/LoadVars objects (for loading eg. local text data from user machine),
It’s very easy to make loaded movie to follow current security restriction avaiable within .v7 of plugin and separate shell .exe from active content loaded from server,
That is a good news because you can build beatuful things that way (eg. modular application) and also bad ones: there is probably no easy way to disallow such things,
There are two related threads on ZINC PC users forum where remote content within desktop application was discussed,
I wonder if Mealstrom new I/O api will bring something new to that,
regards,
peter