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

    sandbox violations with app-storage swf's

    ZoD-
      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()
      loader.load("somesection.swf");

      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.

          -Ethan
          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.

                  -Ethan
                  Adobe AIR Team