How to Make crossdomain.xml Work with SharePoint

Not long ago I worked on a web site which had all its content and media stored in SharePoint. At an early point in the project, Flash developers started to complain that none of their media played when served from SharePoint. The problem seemed obvious: the cross-domain policy file, crossdomain.xml, was missing. Here’s what it’s for (via Adobe):

A cross-domain policy file is an XML document that grants a web client—such as Adobe Flash Player (though not necessarily limited to it)—permission to handle data across multiple domains. When a client hosts content from a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain would need to host a cross-domain policy file that grants access to the source domain, allowing the client to continue with the transaction. Policy files grant read access to data as well as permit a client to include custom headers in cross-domain requests.

The most common location for a policy file on a server is in the root directory of a domain with the filename crossdomain.xml (e.g. http://example.com/crossdomain.xml)—the default location that clients check when a policy file is required.

There are two things to note here.

1. “though not necessarily limited to [Adobe Flash]”. Silverlight, being a Flash knock-off, works the same way. See HTTP Communication and Security with Silverlight. In other words, this discussion applies to Silverlight just as much.
2. A cross-domain policy file must be placed in the root of your web site.

The challenge became how to put crossdomain.xml in web root. SharePoint isn’t your typical web site; you don’t just hit pages—there’s a level of indirection for all resources.

Just about every blog post on the web recommended using the now free SharePoint Designer to upload the policy file. Others were suggesting to “drop” it in the physical root (normally C:\inetpub\wwwroot\wss\VirtualDirectories\80).

We followed just about every bit of advice. Nothing worked. Hitting crossdomain.xml would always yield a 404.

Several days into this nightmare, my stalwart co-worker Eric stumbled upon a solution:

1. Copy crossdomain.xml to SharePoint’s physical root.
2. Open web.config from the same folder and disable custom error pages:

   <customErrors mode="Off" />

Amazingly, that worked! Like all things SharePoint, it made no sense at all, but it worked.

I hope I can save someone several days of frustrating troubleshooting.