Skip to main content
C
Cider123
Participant
September 3, 2012
Answered

Error #2048: Security sandbox violation

  • September 3, 2012
  • 1 reply
  • 16399 views

I've been working on this for almost 2 days solid now, with no luck.  Exhausted every article and suggestion I've run across, so I hope the community can help!  In my pursuit of an answer for this, I hope it can serve a dual purpose and become useful information for other developers going down this road.  For some, you may see the content and figure TL;DR, but I'm hoping to answer any questions that might otherwise span several messages.

The goal is to use a "binary socket" to communicate between a Flash App and a custom socket server I'm working on.  I soon discovered you need to have a "crossdomain.xml" file to allow the Flash Application to communicate over sockets.

I develop under Windows 7 64-bit, using Flash Professional CS6, Microsoft Visual Studio 2012 and hosting under IIS.

Eventually I plan on hosting the Flash Application and crossdomain.xml on a remote server, but for the purpose of developing this I wanted to try to keep everything on a single development workstation.

My Policy Socket Server module gets the Flash Application request and sends back the correct response. 

Incoming packet using Debug -> Debug Movie -> In Flash Professional:

GET /crossdomain.xml HTTP/1.1

Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, text/css, image/png, image/jpeg, image/gif;q=0.8, application/x-shockwave-flash, video/mp4;q=0.9, flv-application/octet-stream;q=0.8, video/x-flv;q=0.7, audio/mp4, application/futuresplash, */*;q=0.5

x-flash-version: 11,2,202,228

User-Agent: Shockwave Flash

Host: 127.0.0.1:843

Incoming packets using Control -> Test Movie -> In Browser:

Packet #1

<policy-file-request/>

Packet #2

GET /crossdomain.xml HTTP/1.1

Host: localhost:843

Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1

Accept: */*

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3


Response sent back:

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

  <allow-access-from to-ports="*" domain="*"/>

</cross-domain-policy>

At first I wasn't sure if this was working, until I fired up a copy of Fiddler and looked at the packets being requested and returned.  Originally I had more entries, but as I read more about the crossdomain.xml I discovered any excluded entries would be defaulted to the current values so I started to remove them for testing different crossdomain.xml configurations I ran across.

Sending back just the XML content through the socket connection didn't work, I later discovered I had to create an HTTP header and then append the XML content.

I was able to confirm the Flash Professional CS6 Application received the crossdomain.xml when I was running the Application in Debug Mode ( Debug -> Debug Movie -> In Flash Professional) and the Output generated the following warning:

Warning: Domain 127.0.0.1 does not specify a meta-policy.  Applying default meta-policy 'master-only'.  This configuration is deprecated.  See http://www.adobe.com/go/strict_policy_files to fix this problem.

I know this is easily fixed by simply using a crossdomain.xml file like:

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

  <site-control permitted-cross-domain-policies="master-only"/>

  <allow-access-from to-ports="*" domain="*"/>

</cross-domain-policy>

Actionscript source code:

private function EstablishConnection(): void {

  var sock:Socket;

  Security.allowDomain("*");

  Security.loadPolicyFile("http://127.0.0.1:843/crossdomain.xml");

  sock = new Socket();

  sock.addEventListener(Event.CLOSE, closeHandler);

  sock.addEventListener(Event.CONNECT, connectHandler);

  sock.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);

  sock.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);

  sock.addEventListener(ProgressEvent.SOCKET_DATA, socketDataHandler);

  sock.connect("http://127.0.0.1", 8080);

}

private function closeHandler(event:Event):void {

  trace("closeHandler: " + event);

}

private function connectHandler(event:Event):void {

  trace("connectHandler: " + event);

}

private function ioErrorHandler(event:IOErrorEvent):void {

  trace("ioErrorHandler: " + event);

}

private function securityErrorHandler(event:SecurityErrorEvent):void {

  trace("securityErrorHandler: " + event);

}

private function socketDataHandler(event:ProgressEvent):void {

  trace("socketDataHandler: " + event);

}

When I execute the Flash Application in Debug mode, the following content is displayed in the Output window:

ioErrorHandler: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2031: Socket Error. URL: http://127.0.0.1"]

Warning: Domain 127.0.0.1 does not specify a meta-policy.  Applying default meta-policy 'master-only'.  This configuration is deprecated.  See http://www.adobe.com/go/strict_policy_files to fix this problem.

securityErrorHandler: [SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2048: Security sandbox violation: file:///C|/Source/FlashCS6/AS101.swf cannot load data from http://127.0.0.1:8080."]

[UnloadSWF] C:\Source\FlashCS6\AS101.swf

Debug session terminated.

The "ioErrorHandler" is almost instant on output, whereas the "securityErrorHandler" takes maybe 10-15 seconds before it rolls out.  I understand this to be due to the async nature of the Flash engine.

When I step through the code in the debugger, I noticed the request for loading the policy file isn't executed until the Application actually tries to connect to the defined URL and port.  I'm thinking this might be the cause, but not sure.

In an effort to get this to work, I have:

  • Added the SWF and Project Folder to the Global Security Settings
  • Changed Publish Settings to "Access network only"
  • Added "http://127.0.0.1" to the Global Security Settings
  • Under Publish Settings, enabled "Permit debugging"
  • Added Inbound and Outbound Rules in Windows 7 Firewall for TCP 8080
  • Tried multiple crossdomain.xml configurations
  • Checked the "mms.cfg" to make sure there was no blocking rules
  • Created and enabled logging features in "mm.cfg", but the log files generated nothing more than what was already displayed in Flash Pro CS6 Output Window
  • Changed "127.0.0.1" to "localhost", get same results

On the note of Global Security Settings, I have discovered this exists in 2 separate places. 

  • If you press "Ctrl-Enter" and right click your Flash App, the "Global Security Settings" here loads up a windows dialog box with options you can configure
  • There is another which can be found at the following URL

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html#117502

Do you need to set both?  I did, in an effort to troubleshoot this.  I'm guessing one comes into play on your local workstation and the other is web-based only.

I did run across some references to the Sandbox Type, which could cause potential problems like this.  In the trace, before the socket connections are made, I traced out the current Sandbox Type and it was "localTrusted".

Another article talked about using your public IP from your ISP, instead of localhost or 127.0.0.1, but this defeats the purpose of local development.

I know the socket communication works on the local workstation, based on 2 events.  The first being the LoadPolicyFile is run over a socket request and the second being I tested the Socket Server communication with a non-Flash Client App.

I'm at a loss right now and stuck in the mud.  Any help appreciated, and I hope it sheds some light to others going down this same road.

Thanks.

This topic has been closed for replies.
Correct answer Cider123

Well, the system isn't perfect but it does work once you grease all the moving parts with the right oil. =)

I started by using a sample from Microsoft for Asynchronous Server Socket to build a Client and Server, confirming the system worked.

Link: http://msdn.microsoft.com/en-us/library/fx6588te.aspx

In an effort to resolve this, I discovered a policy + socket server written in java.  It isn't pretty, but they have a disclaimer on the page saying it's extremely badly written but it works.

Link: http://efreedom.com/Question/1-2951030/AS3-Java-Socket-Connection-Live-Flash-Local-Java

I had nothing to lose, so I created a restore point, installed the Java SDK and the Eclipse IDE for Java EE Developers.  Created a new project and hacked up the sample to match the ports I was using and hit "Play", fired up the Flash project and viewed it in a Browser.  For the first time, I witnessed events fire off for connect and close.  In shock now. LOL.

After a little trial and error with my Server, I discovered what needed to change.  The first had to do with how the "AddressFamily" was being identified.  The next item was changing the IPAddress for the IPEndPoint from a source of an AddressList (see Microsoft sample) to "IPAddress.Any".  The last item was somewhat odd, as the Server didn't seem to pick up any new connections until I defined the Listener with MaxConnections.

Below is a snip of the final C# code where changes were made.

IPHostEntry ipHostInfo = null;

IPEndPoint localEndPoint = null;

try

{

     ipHostInfo = Dns.GetHostEntry(Dns.GetHostName());

     localEndPoint = new IPEndPoint(IPAddress.Any, _Port); 

     _SocketListener = new Socket(localEndPoint.Address.AddressFamily, SocketType.Stream, ProtocolType.Tcp);

     _SocketListener.Bind(localEndPoint);

     _SocketListener.Listen((int)SocketOptionName.MaxConnections);

     ...

It seems relatively simple, but all it takes is 1 config parameter set wrong and the Server sails on a different level than where Flash operates.

I based the Policy Server off the same design.  What I don't understand is despite the initial design not acknowledging connections on the Policy Server from a Flash App, Flash still grabbed the crossdomain profile that was sent back across port 843.  The content is only available within the engine (an actual local file does not exist) and I was able to validate this based on changes I made on the crossdomain content being sent across and re-compiling and running the Server again for testing.

Error #2048 was the result of the Socket Server not accepting the connection or being available for connections.  Once I fixed the Policy Server I was still receiving Error #2048 until I fixed the Socket Server connections.  Initially I had set an HTTP header to the packet being sent with the crossdomain policy, but later I removed it and only send the XML content now.

The design I had in mind all works now.  Multiple connections and real-time communication over sockets.  I have no need for video or audio streaming, just data transmission.  I hope this info helps anyone else who may be facing the same challenges.

Cheers!

1 reply

C
Cider123AuthorCorrect answer
Participant
September 9, 2012

Well, the system isn't perfect but it does work once you grease all the moving parts with the right oil. =)

I started by using a sample from Microsoft for Asynchronous Server Socket to build a Client and Server, confirming the system worked.

Link: http://msdn.microsoft.com/en-us/library/fx6588te.aspx

In an effort to resolve this, I discovered a policy + socket server written in java.  It isn't pretty, but they have a disclaimer on the page saying it's extremely badly written but it works.

Link: http://efreedom.com/Question/1-2951030/AS3-Java-Socket-Connection-Live-Flash-Local-Java

I had nothing to lose, so I created a restore point, installed the Java SDK and the Eclipse IDE for Java EE Developers.  Created a new project and hacked up the sample to match the ports I was using and hit "Play", fired up the Flash project and viewed it in a Browser.  For the first time, I witnessed events fire off for connect and close.  In shock now. LOL.

After a little trial and error with my Server, I discovered what needed to change.  The first had to do with how the "AddressFamily" was being identified.  The next item was changing the IPAddress for the IPEndPoint from a source of an AddressList (see Microsoft sample) to "IPAddress.Any".  The last item was somewhat odd, as the Server didn't seem to pick up any new connections until I defined the Listener with MaxConnections.

Below is a snip of the final C# code where changes were made.

IPHostEntry ipHostInfo = null;

IPEndPoint localEndPoint = null;

try

{

     ipHostInfo = Dns.GetHostEntry(Dns.GetHostName());

     localEndPoint = new IPEndPoint(IPAddress.Any, _Port); 

     _SocketListener = new Socket(localEndPoint.Address.AddressFamily, SocketType.Stream, ProtocolType.Tcp);

     _SocketListener.Bind(localEndPoint);

     _SocketListener.Listen((int)SocketOptionName.MaxConnections);

     ...

It seems relatively simple, but all it takes is 1 config parameter set wrong and the Server sails on a different level than where Flash operates.

I based the Policy Server off the same design.  What I don't understand is despite the initial design not acknowledging connections on the Policy Server from a Flash App, Flash still grabbed the crossdomain profile that was sent back across port 843.  The content is only available within the engine (an actual local file does not exist) and I was able to validate this based on changes I made on the crossdomain content being sent across and re-compiling and running the Server again for testing.

Error #2048 was the result of the Socket Server not accepting the connection or being available for connections.  Once I fixed the Policy Server I was still receiving Error #2048 until I fixed the Socket Server connections.  Initially I had set an HTTP header to the packet being sent with the crossdomain policy, but later I removed it and only send the XML content now.

The design I had in mind all works now.  Multiple connections and real-time communication over sockets.  I have no need for video or audio streaming, just data transmission.  I hope this info helps anyone else who may be facing the same challenges.

Cheers!

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices