Bug? LoaderInfo getLoaderInfoByDefinition security sandbox violation in AIR

Question

This question is specific to Adobe AIR ActionScript/Flash applications. I've spend quite some time researching this and kept finding discussions about either the Flash Player security model when running in the browser, where issues with SWF loading can be mitigated in various ways (loading from the same domain, using a crossdomain.xml file, etc.) or for AIR HTML applications, where the JavaScript security model is discussed with it's per-frame sandboxes and the sandbox bridge approach. My problem is different, I believe.

First some code. To demonstrate, I created a very simple Flex application (LoaderInfoTest.mxml):

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication
    xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="absolute"
    creationComplete="onCreationComplete(event)">
    <mx:Script>
        <![CDATA[
            import flash.display.LoaderInfo;
            import flash.system.ApplicationDomain;
            import flash.utils.getQualifiedClassName;

            import mx.events.FlexEvent;

            public function onCreationComplete(event:FlexEvent):void
            {
                // the following line of code throws an exception
                var info:LoaderInfo = LoaderInfo.getLoaderInfoByDefinition(this);
            }
        ]]>
    </mx:Script>
</mx:WindowedApplication>

... and an application.xml descriptor file (LoaderInfoTest-app.xml):

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<application xmlns="http://ns.adobe.com/air/application/1.5.2"&gt;
    <id>LoaderInfoTest</id>
    <filename>LoaderInfoTest</filename>
    <name>LoaderInfoTest</name>
    <version>v1</version>
    <initialWindow>
        <content>LoaderInfoTest.swf</content>
    </initialWindow>
</application>

I build this using Flash Builder 4 Beta, but I presume the issue remains the same when using the SDK command line tools. When executing this either from within Flash Builder or from the command line via:

> adl LoaderInfoTest-app.xml . 

I get a popup with this exception:

Security sandbox violation: caller app:/LoaderInfoTest.swf cannot access LoaderInfo.applicationDomain owned by app:/LoaderInfoTest.swf. at flash.display::LoaderInfo$/getLoaderInfoByDefinition() ...

I don't understand why the SWF cannot access the LoaderInfo.applicationDomain property (presumably a protected or internal property) owned by itself. The documentation for LoaderInfo.getLoaderInfoByDefinition states that it's possible for a SecurityError to be thrown, if "[t]he caller is not running in the local trusted sandbox". Unless I really have a gross misunderstanding of the AIR security model, a local SWF runs with full trust (application sandbox). So, why is this not working? Is it a bug in the AIR runtime?.

I should note that in a different scenario, when running this code as a pure Flash (not AIR) application in the Flash player, it does work.

The best answer would be some sort of configuration or setting I can change to make this work (maybe in the application descriptor?) ... or pointing out where I am making a mistake. The second-best answer would be a definite source of explanation of why this will never work.

1st Edit - Before anyone points it out: I know that inside the onCreationComplete method, this.loaderInfo gives me access to the current LoaderInfo instance. My example here is the simplest I could come up with to demonstrate the "problem." The context in which I want to use LoaderInfo.getLoaderInfoByDefinition(this) is not a DisplayObject instance.

2nd Edit - I am considering even accepting a link to where I can post a bug to Adobe AIR's issue tracker as an answer. The public Flex issue tracker doesn't count, because this is not a Flex problem.

3rd Edit - It is apparent that there are differences between the "local trusted sandbox" and the "AIR application sandbox," but (some of) these differences seem non-sensical and I now consider them a bug, at least in the context of this question and especially because it works in Flash Player.

Answer 1

You can file bugs against AIR (as well as make feature requests) at www.adobe.com/go/wish

I suspect the security error may be a red herring. It doesn't look like there should be one here.

Answer 2

The documentation is correct that getLoaderInfoByDefinition is available only to content in the localTrusted sandbox. Although AIR application content has many privileges, it is not in localTrusted and therefore cannot use the API.

It's certainly a reasonable request, however, to add access for application content.

As a workaround, you can use this API (and Sampler APIs) in AIR by loading another SWF in localTrusted sandbox. To do this, you need to add the file to one of the trusted lists, and load the file with a file:// URL (not app:/). There are then a number of ways for the localTrusted and application content to communicated.

Answer 3

This issue is also showing up in a regular flash application. Basically, I have a helper class called UrlInfo.

It's constructor looks like this

import flash.display.LoaderInfo;
public class UrlInfo
{
private var _loaderInfo:LoaderInfo;

    public function UrlInfo():void
    {
        _loaderInfo = LoaderInfo.getLoaderInfoByDefinition(this);
    }
}

In a fla file, I have this:

import my.namespace.UrlInfo;
var ui:UrlInfo = new UrlInfo();

---

I get the same error:

SecurityError: Error #2119: Security sandbox violation: caller file **SAMEFILE.swf** cannot access LoaderInfo.applicationDomain owned by **SAMEFILE.swf**.
    at flash.display::LoaderInfo$/getLoaderInfoByDefinition()
    at com.honda.ttd.content.as3.util::UrlInfo()
    at urlinfo_fla::MainTimeline/frame1()

---

Launching the .html that calls the swf does not trigger this. Launching the .swf does trigger this.

I know that I can fix it by going to the flash settings and adding the location of the swf into the Flash Security Settings Tab.

For instance, if the SAMEFILE.swf is on my Desktop, I can add C:/ to the list of trusted locations.

---

I AGREE THAT THIS IS ODD because the file is accessing itself, yet it is violating some security. I would like to know if there is any fix for this or if this is actually expected behavior.