When making cross-domain requests from Silverlight applications you need a clientaccesspolicy.xml file to allow the communication between the service and the Silverlight application. And while it seems pretty straight-forward at first, things become quite inconvenient when you start working with Host Named Site Collections.
Client Access Policies
A while ago building rich Silverlight applications gained popularity. More and more .NET developers started building rich web solutions using their existing skills and not having to worry about things such as cross-browser compatibility. Silverlight solutions can not only be rich user interfaces but also offer the ability of communicating with external systems allowing you to build solutions that can help solve business problems.
Similarly to Flash communicating with external systems from within Silverlight solutions is not without risks. Because a Silverlight application is encapsulated, malicious code could connect to an external system, outside the user’s domain, without the user’s knowledge. Some of the threats are described in the Making a Service Available Across Domain Boundaries article on MSDN.
To allow Silverlight components to communicate with systems in other domains, and to protects web applications from being exploited, those systems must explicitly allow communication from the domain where the Silverlight component is executed on. Such “contract” is known as a client access policy.
Silverlight components support two types of client access policies: crossdomain.xml, originally designed for Flash applications, and clientaccesspolicy.xml which is designed specifically for Silverlight. Both files must be defined in the root of the site that is hosting the service used by the Silverlight application, eg. http://contoso.com/clientaccesspolicy.xml.
Host Named Site Collections – it’s for scale
SharePoint is platform used in many enterprises across the globe for building web solutions. In many scenarios enterprise means scale: for example hosting multiple applications on a shared platform. Although there are some restrictions with regard to how many Application Pools and Web Applications you can host on a single SharePoint Farm those numbers increase a lot when you start talking about Site Collections.
The downside of scaling out at the level of Site Collection seemed for a while the lack of support for vanity URLs. You could have only one Site Collection located at the root of the domain, eg. http://contoso.com but all other Site Collections created within the contoso.com Web Application had to be located either on a managed path, eg. http://contoso.com/sites/site1 or as explicitly included URL, eg. http://contoso.com/site1. But what if you wanted to have a Site Collection in the contoso.com Web Application but then using its own domain, like http://site1.contoso.com? And so the concept of Host Named Site Collections (HNSC) was introduced in SharePoint 2007.
Host Named Site Collections are regular Site Collections, living just as all other Site Collections within Web Applications. The only difference is that an HNSC has a host header mapped to it. And although from the outside there is no difference between accessing an HNSC and a root Site Collection of a Web Application there are some things that you should take into account, one of which are client access policies.
Host Named Site Collections give you the fake idea of creating another root besides the Web Application. After all they are bound to a specific host name and all of the assets can be accessed using server-relative URLs to that particular host name. As you know Site Collections have no physical footprint on the server and exist fully within Content Databases. As a result all of the files belonging to a particular Site Collection, whether it’s host named or not, are located in a Content Database. All except for one.
Inconvenient Client Access Policies and Host Named Site Collections
If you try to create a clientaccesspolicy.xml file in the root of your Host Named Site Collection hosting a service used by some Silverlight components, you will notice that that particular client access policy will not be loaded by the Silverlight application. In fact, if you take a closer look, you will see that it’s actually SharePoint that refuses to serve your clientaccesspolicy.xml file from the Site Collection’s Content Database!
It turns out that there are some files which must be located on the file system one of which is clientaccesspolicy.xml. As soon as you create the clientaccesspolicy.xml file on the file system in the root folder of your Web Application everything will work as expected.
Host Named Site Collections are a great way for scaling out if you need your sites to have multiple sites each with its own host header. If those sites are hosting services used by Silverlight components you will need a crossaccesspolicy.xml file to allow the communication between the service and the Siverlight components. Event though all of the Site Collection’s content is stored in its Content Database, the clientaccesspolicy.xml file has to be located on the file system in the root folder of the Web Application hosting all Site Collections. Planning for managing the contents of the clientaccesspolicy.xml file for all Host Named Site Collection is something that you should take into account when designing your solution.