Part 1 of this series gave you a brief introduction to cross-domain policies, and showed you where to correctly place your policy files. In this post we want to show you some basic troubleshooting techniques for both Adobe Flex and Microsoft Silverlight. If you are having problems such as maps not displaying, or you are getting security sandbox errors then you may be having cross-domain policy problems. Here are some basic guidelines to follow:
- Make sure the policy file is downloading
- Make sure you are using the latest policy file
- Check your policy file settings
- Examine the error messages
- Set your project to run on local web server
Note, in this post we are focusing on resources within your domain and sub-domains; for example http://www.yourwebsite.com/ and http://maps.yourwebsite.com/. The cross-domain file needs to be on the machine with the data or service, and not necessarily the machine hosting the Flex (SWC) or Silverlight app (XAP). Also, if you are having problems accessing third party resources, then you'll need to work with the third party directly to figure out their cross-domain policies and procedures.
Make Sure the Policy File is Downloading
There are a number of easy ways to verify if the policy file is being downloaded to the client. In Firefox click on the “Net” tab in Firebug. Or, if you are using Internet Explorer then Fiddler is a good choice. If you want more details on Firebug and Fiddler there's a short write up in a previous ArcGIS Developer blog post. Silverlight developers should also look at using Silverlight Spy. Silverlight Spy gets the extra bonus points for having a cross-domain access policy validator.
If the client app can find and download the policy file, you should see a "200 OK" message. Another trick is to try and load the URL from a browser window, for example: http://tasks.arcgisonline.com/crossdomain.xml if that's the server you are trying to access content from.
Make Sure You Are Using the Latest Policy File
When you make changes to the cross-domain file, be sure to refresh/reload the page to make sure the browser "sees" the latest version. If you have tried multiple web page reloads and still see "304 Not Modified", then you have a few options:
You can clear your entire cache, although this often isn't very desirable if you have a lot of useful links stored. In Firefox 3.5.x they recognized this problem and implemented a very nice, new feature that lets you remove everything from the last hour called Clear Recent History.
You can bypass the cache and force the whole page to reload even if there is a cached copy. Here's a page that explains how to do this: http://en.wikipedia.org/wiki/Bypass_your_cache.
Check the Policy File Settings
Do a little digging into what settings are appropriate for your domain security. A typical default file is completely open and allows access to all your sub-domains from any external domain. This may not meet your organizations security requirements. Adobe's Cross-domain Policy File Specification article has a good discussion on the different configuration options for crossdomain.xml. For Silverlight developers, there is an MSDN article on Network Security and Access Restrictions that talks about the various configuration options in clientaccesspolicy.xml.
Examine the Errors
Most of the time, reading the error carefully will offer some important hints on how to resolve the problem. The really important information will be in the very first line or two of the error message dump. Just as an FYI, Flex has over twenty different errors related to Security sandbox violations. Silverlight 3 has only a handful related specifically to security sandbox violations.
Here are a few of some of the most common problems with hints and suggestions on how you might be able to resolve them:
Cross-domain policy file is missing, or incorrectly configured to allow access. Check to see if policy file is downloading, and check its settings.
Cross-domain policy file is missing, or incorrectly configured to allow access. Check to see if policy file is downloading, and check its settings.
File is missing, or in the wrong directory. See Part 1 for suggestions on how to locate the root directory.
A few things could be wrong here. Check your policy file pathname carefully. Copy the URL into a browser to see if it loads the policy file. Check your firewall logs to make sure the request isn't being blocked, especially if its on a non-standard port number, for example: http://subdomain.yourwebsite.com:8001/map.aspx.
The URL is blocked or the policy file wasn't found by URLLoader() or URLRequest(). It can also show up when using HTTPS and HTTPService(). Re-check that your URL is correctly spelled and is loadable. Try to run the app in a browser while using Firebug or Fiddler.
The policy file loaded okay, but domain access is not allowed. Check the policy file settings.
Problem is with the server not the client app. Check directory permissions and other configuration files for your server. On a Windows Server check the Event Viewer log since it will contain all the details for the error.
Set Project to Run on Local Web Server
If you are running into cross-domain problems on your dev box while making calls to external web services, or if you want to more accurately represent a production environment, try setting your Flex Builder or Visual Studio project to run on your local web server (e.g. IIS or Apache).
Here's an example for Visual Studio 2008 and IIS 7. For Flex, see the example screenshot below. Also don't forget to move your cross-domain policy files to your local web server root.
Additional Resources
