Recently, the Flash Player update (9,0,124,0) crippled one of our clients’ sites by stopping the Flash-based application from making Soap calls to a web server other than the one that served the SWF.

Despite consulting various internet resources, we were unable to find any solution that worked. Wade Arnold’s blog entry came the closest, but unfortunately included a tag that stopped even previous versions of the Flash Player from working.

The following crossdomain.xml file is the working solution that we came up with. In production, you should restrict the ‘domain=’ fields to the domains that serve your SWFs.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
  <allow-http-request-headers-from domain="*" headers="*" />
</cross-domain-policy>

With the release of Flash player 9 Update 3, many Flash applications are beginning to break due to Flash’s new socket policy rules.

The executive summary is that a server that allows Flash Player to connect to its sockets must now provide a socket policy file on either port 843 or the port that the player is connecting to.

There are several scripts available for setting up a socket policy file server on port 843 on linux to solve this problem, but how do you test if your socket server is running correctly before opening the port up to the world through your firewall?

The following java source and class file is one way to check that the socket server is responding correctly. Download the class file (or source, if you know how to build it for your environment) and upload to your server:

• Flash843.java
• Flash843.class (built for Java 1.4.2)

For information on using the utility:

/path-to-java/bin/java Flash843 -h