5 Replies Latest reply on Apr 26, 2008 9:34 AM by

    sandbox violations with app-storage swf's

      So here's my goal:
      Im using AIR to build a kiosk application that will run on the desktop. The only thing AIR actually does is download files from a web server and save them in the app-storage directory. It then loads a default swf file from the app-storage directory.

      The problem im running into is when that default swf tries to load other swf files from the same app-storage directory. It throws a sandbox violation.

      Heres a psudo example:
      AIR document class:
      loader = new Loader();
      loader.load( "app-storage:/Default.swf" );

      application = loader.content;
      addChild( application );

      This works fine. It loads the default swf file. The problem comes when the Default.swf file tries to load another swf...

      Default.swf document class:
      loader = new Loader()

      section = loader.content;

      When trying to access loader.content is when the application throws a sandbox violation:
      SecurityError: Error #2121: Security sandbox violation: Loader.content: app-storage:/Default.swf cannot access app-storage:/Somesection.swf. This may be worked around by calling Security.allowDomain.
      at flash.display::Loader/get content()

      From what I can gather, this occurs because the main AIR file is running under the application security sandbox, while Default.swf is running under local-with-filesystem sandbox.

      It would be great if I could just do Security.allowDomain("app-storage:/") or something, but that doesnt seem to work.

      I dont want to package the Default.swf and section swf's into the .air file because then whenever a section changes, the entired air application needs to be redownloaded and installed.

      It would be nice if the swf files loaded from the app-storage folder was part of the application security sandbox, or if I could just write files to the app:/ directory instead of the app-storage:/ directory, that way they would be loaded into the application sandbox. AIR doesnt seem to allow either though.

      Any suggestions?!
        • 1. sandbox violations with app-storage swf's
          Which sandbox do you want the loaded SWFs to live in? Currently they're local, which isn't totally working out. It's hard to tell for sure, but I think they're in *different* local sandboxes, like one local-with-network and one local-with-filesystem, which would explain why the load works, but the content access throws an exception. I hope that's the issue; it'd be an easy fix.

          It seems like they'd be great in the app sandbox, but there's a lot of work to do making that safe. See my blog for some more info -- http://weblogs.macromedia.com/emalasky/archives/2008/04/remote_plugins.cfm

          If you'd rather that the file be local, but *act* as if they're still on the server, it's possible to put locally cached files in a remote sandbox. For HTML, it's really easy, see http://livedocs.adobe.com/air/1/devappshtml/help.html?content=AboutHTMLEnvironment_5.html . For SWF, it's still possible in AIR 1.0, but cross-sandbox communication (between your app and the cached, "remote" content) is a pain. You can do it by

          (1)creating an HTMLLoader that loads an app HTML page (index.html), which in turn
          (2)loads an HTML page (loader.html) which is
          (3)remapped to a remote domain using sandboxRoot and documentRoot attributes in IFRAME, and also loads your SWF.

          Three suggestions, depending on your desired sandbox and level of work desired. Hope that helps.

          Adobe AIR Team
          these docs these docs these docs
          • 2. Re: sandbox violations with app-storage swf's
            Well I too have run into these sandbox problems with AIR but am struggling to understand why ZoD's code would cause a security error.
            From all I knew, any SWF loaded into an AIR app from app-storage would by default be in the "application" sandbox/domain. It appears this holds true for his first load.
            So why is the Default.swf loading somesection.swf causing a security error? Default.swf is in application sandbox as is somesection!
            Can anybody explain why this error is occurring or is it a bug?
            • 3. Re: sandbox violations with app-storage swf's
              ZoD- Level 1
              Thanks for the responses...

              The Default.swf is loaded into the localWithFile security sandbox, not the application sandbox, since it resides in the app-storage directory and not the app directory. When Default.swf loads Content.swf (also in app-storage), it also gets loaded into localWithFile sandbox (shown from trace(Secuirty.sandboxtype)).

              The Content.swf file gets loaded fine. I can even do an addChild(loader), and the swf gets added to Default.swf.

              The problem is if I try to do a addChild( loader.content ), for example. Thats when it throws the exception. This only happens if Main AIR file loaded Default.swf in the first place.

              The "workaround" I have used is to first load Content.swf using URLStream, then reading the bytes into a byteArray. Then useing that ByteArray and doing a loader.loadBytes( ba, loaderContext ), passing in a loaderContext object that has the property allowLoadBytesCodeExecution = true. I feel this is too much of a hack though.

              So, from my understanding...although Default.swf and Content.swf are in the same sandbox, they are running under the AIR application sandbox, which is why cross-scripting between Default and Content is not working....I think.

              The Default.swf and Content.swf do not need access to the AIR API, but do need to communicate with each-other.

              I'll give Ethan's suggestion a try (when his blog comes back online), and take a look at the HTML iframe extensions to see if thats what I need.

              • 4. Re: sandbox violations with app-storage swf's
                Well the only way I can see to let Default.swf and Content.swf communicate is to make use of LoaderInfo.[child|parent]SandboxBridge.
                • 5. Re: sandbox violations with app-storage swf's
                  Please do read my blog when the server's back up. The loadBytes() "workaround" is exceedingly dangerous. To make it safe, there's a whole lot of extra work you'll need to do.

                  The fact that accessing Loader.content fails when both parent and child are in the same domain might be a bug. Can you file it?

                  If you don't need AIR APIs, and don't need those SWFs to even communicate back the AIR app (except maybe through LocalConnection), consider the domain-remapping option (3) I describe above. The local sandboxes are confusing in general, so putting files in the appropriate remote sandbox simplifies things.

                  For now, it's a weird dance to do the remapping for SWF, but I hope that'll be made simpler in a future release.

                  Adobe AIR Team