This issue is happening because the SWF in the Air application runs in a different sandbox than Wildfire.

Currently the only way around this is to setup the Air application as a simple HTML file that loads the SWF from the network. In that case both Wildfire and the SWF will be in the network sandbox and will be able to communicate with each other. This method will prevent the SWF from accessing any local resources on the computer.

So far we haven't seen a lot of demand for that, since it's not very common for someone to want to grab a desktop application and install it in a web destination. Usually the direction is grabbing an application from a web location to the desktop.

If we see demand for this kind of implementations we'll implement better support fo it.

Because of the way security sandboxes work in Air there is a problem passing configuration data between an Air application, which is running in the local sandbox, and Wildfire, which is running in the Internet sandbox.

If I understand correctly your goal is to create and configure a widget from an Air application then distribute it using Wildfire - you can still do that. You can open a popup window, pass to it the required widget configuration (as values in the query string) and load Wildfire on that page while passing the configuration you want.

I am sorry but I see no technical reason for a SecurityContext to be necessary at first place: I know that FlashVars can't be used for parameter transfer but its possible. Using GET/POST for it doesn't make any sense as well. But it would be no problem to offer a version which (without violating any security concern) just offers a init method. I put together a small example to illustrate what I mean: The .swf provided by you could look like this:

package 
{
    import flash.text.TextField;
    import flash.display.Sprite;
   
    public class Gigya extends Sprite
    {
        public function init( text: String ): void
        {
            var tF: TextField = new TextField();
            tF.text = text;
            addChild( tF );
        }
    }
}

And to tell your widget that we have information (configuration/embedcodes/whatever) the code at our place could look like this:

 package  
{
    import flash.events.Event;
    import flash.net.URLRequest;
    import flash.display.Loader;
    import flash.display.Sprite;
    
    public class AirTest extends Sprite
    {
        private var _loader: Loader;

        public function AirTest()
        {
            addChild( _loader = new Loader() );
            _loader.load( new URLRequest("http://yourdomain/gigya.swf") );
            addEventListener( Event.ENTER_FRAME, onEnterFrame );
        }

        private function onEnterFrame(event: Event): void
        {
            if( _loader.content )
            {
                _loader.content["init"]( "hi" );
                removeEventListener( Event.ENTER_FRAME, onEnterFrame );
            }
        }
    }
}

This will work perfectly without the need for Security.allowDomain. I know that this solution would violate your current API but this would allow users within AIR to use it as is and will safe a lot of people from a lot of hazzle.

yours
Martin Heidegger