Why is Flash demanding a crossdomain.xml file when the .swf and http target are both on localhost?

Question

I've got a small client/server test application where I have a Flex app that makes an HTTP request of a server app. The server app is a script running on my local machine, listening on port 8001. The client is a swf that I am running locally, and uses mx.rpc.http.HTTPService to make the page request.

The HTTPService is being set up as per below:

_HttpService = new HTTPService();
_HttpService.url = "http://localhost:8001";
_HttpService.contentType = "text/xml";

When I make a basic page request, my server app is first receiving a "GET /crossdomain.xml HTTP/1.1" request, which is failing since I don't have a crossdomain.xml file in place. The reason I don't have one in place is because this is all happening on my local machine (for now) and I shouldn't need one (I don't think).

I definitely had this code working before without a crossdomain.xml when I was using Flex 3.x. I thought I had it working with Flex 4 as well. Now I'm using Flex 4.5. Is there an issue here, possibly due to security policy changes?

With all of this happening on localhost, why is the Flash player requesting a crossdomain.xml file?

In case it helps, the specific fault my AsyncResponder is getting back is:

[FaultEvent fault=[RPC Fault faultString="Security error accessing url" faultCode="Channel.Security.Error" faultDetail="Destination: DefaultHTTP"] messageId="F43DCBFF-E99A-99CC-57D8-535C13C7CD48" type="fault" bubbles=false cancelable=true eventPhase=2]

Piteous

Answer 1

It may be that although you have the same host and protocol between the client page and server, the different port causes Flash to fail the same-origin test and request the crossdomain.xml to see what it's allowed to do. I'm assuming the page hosting your Flash content is running on port 80? If that's the case, check out Wikipedia's article on the same origin policy (http://en.wikipedia.org/wiki/Same_origin_policy) for the details.

The crossdomain.xml doesn't seem to be too cumbersome for local testing and is pretty well documented on help.adobe.com. You can create a crossdomain.xml in the root of your website like this, which will allow all access:

<?xml version="1.0"?> 
<!-- http://localhost/site/crossdomain.xml --> 
<cross-domain-policy> 
    <site-control permitted-cross-domain-policies="all"/> 
    <allow-access-from domain="*" to-ports="*"/> 
</cross-domain-policy>

I wouldn't use the above for anything other than local development as you're basically allowing any domain to request content.

Hope this helps!

Gatha

Thanks! I'll need to look into how Flash does it's same-origin testing. To be more specific, my "server" is an xmlrpc server that uses HTTP for transport. It does not handle GET requests at the moment, although I could certainly force it to. The source of the flash content is a local file generated by the IDE I'm using at the moment (Amethyst plugin for Visual Studio). – Piteous

Rolling your own xmlrpc server sounds like fun, although you do have to support any additional nuances Flash throws at you... like the GET for crossdomain.xml. I'm not sure of your implementation, but it might be worth it to look into leveraging an existing web stack and then building out a simple web service instead of using xmlrpc. If you're using C#/MS stack, check out WCF REST with plain old xml - see: link – Gatha

+1. mrdc is right. The domain and port needs to be the same to ignore crossdomain policies. If the port is different than the webservers, then it'll look for crossdomain.xml. Easiest way to get this working if to have your server in an application container (like glassfish or tomcat if using Java/.Net) or use whichever web server to serve up server side scripting language (php, asp, etc). Much easier to all have it done with just one server. – Stanleystanly

I'm not sure what to make of it, but when I switched it to use a standalone flash player versus loading up the flash via html in a browser, the crossdomain issue goes away completely. ie: it is working fine now (and now that this has happened I expect that this is how I ran it successfully in the past as well). I'm not sure if this matches the ports-must-match theory... does it? – Piteous

Using Flash player (fp) avoids the crossdomain issue as fp doesn't have a hosted context. When Flash is hosted on a web page, the request goes something like: [User] -> [Webpage (localhost:someport)] -> [Web Service (localhost:someotherport)] and fails the same origin test between the Webpage and Web Service. When using fp you only have [User w/Flash player (no hosted context)] -> [Web Service] The web service is the only hosted context that the same origin is tested against. And, since there's only one context, it doesn't check for cross domain issues. Hope this helps! – Gatha

Answer 2

Using the policyfile.txt I figured out that the policy file was denied because there was no Content-Type specified by the server. This explains why it was impossible to find anything blogged about it.

Hope this helps someone.

In Flex 4.5 Mac /Users/[YOUR_USER_NAME]/Library/Preferences/Macromedia/Flash Player/Logs>tail -f policyfiles.txt

Carpus

Can I erase the policyfiles.txt? – Unfamiliar

Good question, I think the answer is yes. This is a local file, iirc it's just a log of policy file activity on your local machine. If you erase it and there is more activity it should just regenerate? See help.adobe.com/en_US/flex/using/… for more information about how to configure it. – Carpus

I posted a similar question after this and they confirmed it was ok to erase as well. Thanks! – Unfamiliar

np, glad i could help. – Carpus