SRAY » Blog Archive » How to Use Apache mod_proxy to Work Around crossdomain.xml Constraints

How to Use Apache mod_proxy to Work Around crossdomain.xml Constraints

I was recently given the task to load xml from a Flex app hosted on our web site. Easy task I thought, especially with the mx.rpc.http.mxml.HTTPService flex object.

Until I ran into this error:


faultCode: Channel.Security.Error

faultString: ‘Security error accessing url’

faultDetail: ‘Destination: DefaultHTTP’
The problem was that the flex swf was to run on our web site, but the xml data was provided by another site.  ( e.g.  ourWebSite.com/flex.swf —> anotherWebSite.com/data.xml )
Specifically the problem is the security built into flash player.  It will not allow flex.swf hosted on ourWebSite.com to use the xml data from anotherWebSite.com (unless anotherWebSite.com publishes a crossdomain.xml file in the root of their web server granting access to ourWebSite.com).  So, the company providing us the data doesn’t currently have anyone consuming the xml data from a flash swf loaded on a web site.  (It seems we are always pushing the boundaries of new technologies.)  Anyways, it could take forever to request they add a relevant crossdomain.xml to their site that grants us access to their data and get have the file put on their web server.  And, they may not want the headache of keeping track of all the thousands of clients that have a legitimate right to the xml data in a crossdomain.xml file.

So, I decided to circumnavigate (work around or hack a solution) to the problem. Basically what I did was use the Apache mod_proxy module to pass requests for the xml through ourWebSite.com. (e.g. ourWebSite.com/data.xml — mod_proxy –> anotherWebSite.com/data.xml) So, to the flash player, it looks like the data.xml is actually hosted on ourWebSite.com. In fact, the url for the xml is now ourWebSite.com/data.xml instead of anotherWebSite.com/data.xml. So it meets all of the flash player crossdomain security restrictions.

Here is a step-by-step guide of how to get around the crossdomain.xml restriction security constraints:

Install Apache 2. (I used apache_2.2.6-win32-x86-openssl-0.9.8e.msi)
Edit httpd.conf and configure mod_proxy to pass requests through it
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so ProxyRequests Off ProxyPass /data.xml http://anotherWebSite.com/data.xml ProxyPassReverse /data.xml http://anotherWebSite.com/data.xml
As needed, add an appropriate crossdomain.xml file to the root of this server (if the flex.swf and the proxy-passed data.xml are on the same apache server, you don’t even need this).
Restart/start Apache 2.

One more caveat I had to work around is enabling Apache 2 to ProxyPass requests to a secure httpS url. (the true url for our data.xml was httpS://anotherWebSite.com/data.xml) So, I was getting the following error message in Apache’s error.log file:


proxy: No protocol handler was valid for the URL https

If you are using a DSO version of mod_proxy, make sure the proxy submodules

are included in the configuration using LoadModule.

The problem was that I did not have the openssl version of Apache 2. You have to have an SSL version of Apache 2 in order to ProxyPass requests to a secure httpS url:

Make sure you have installed the openssl version of Apache 2 (I used apache_2.2.6-win32-x86-openssl-0.9.8e.msi)
Edit http.conf and configure for SSL Proxy support
LoadModule ssl_module modules/mod_ssl.so SSLProxyEngine On

12.20.07 by Steve Gudmundson
Flex