scorbs

Last time, we discussed how Silverlight applications talk to their site of origin server.  In this post, we’ll dive into the high level concepts around Silverlight’s cross domain HTTP communication.  Then next time, we’ll go into details of how to set up a cross domain policy file. 

(I know - I lied!  But part 2 was just getting too long… so I converted this to a 3 part series.)

(Series Links:  Part 1, Part 2, Part 3)

What is Cross Domain Communication?

As mentioned last time, your Silverlight application by default can only talk back to its site of origin server.  This is in line with the general browser sandbox, and is designed to prevent cross site forgery.

The site of origin server is determined by the app’s deployment URI: the location of the XAP for managed applications, the address of the XAML page for javascript applications.

If a HTTP request matches the origin server’s domain, protocol, and port number, then it’s considered a site of origin request and is allowed.  Otherwise, it’s classified as a cross domain call.

Silverlight’s Cross Domain Policy Support

In order for a cross domain request to a particular web service to succeed, that web service needs to explicitly opt-in to 3rd party callers.

In Silverlight 2, the primary way of enabling cross domain calls is through a policy file placed at the root of the server.  We support two types of policy files:

1. Silverlight Cross Domain Policy File (clientaccesspolicy.xml)
2. (A subset of the) Flash Cross Domain Policy File (crossdomain.xml)

What Can You Say to a Cross Domain Server?

Basic Capabilities

So, you’ve got permission from the appropriate policy file to make a cross domain request .  What can you do with that request?

• Scheme:  HTTP only (HTTPS support expected for V2 RTM)
• Verb support:  GET & POST
• Status codes:  200 (OK) or 404 (NotFound) only

Request Headers

By default, no request headers are allowed to be sent.  A policy file can explicitly opt in to setting certain headers on POST only.  There are also a set of blacklist headers that can never be sent.

Cookies & Authentication

All the requests you send will have have cookies and authentication sent with them.  This is a significant point, and we’ll dig into it deeper in the part 3 of this post series.

The above capabilities are determined by the browser plugin’s networking APIs.  Please see Part 1 for a deeper discussion of networking stack implementation.

Path Character Restrictions

Silverlight has placed certain restrictions on the path portion of a cross domain URI. 

Specifically, a cross domain request path can ONLY contain:

• alpha numeric characters {a-z, A-Z, 0-9}
• certain punctuation { / - _ ~ = ;}
• "." but no consecutive ".."s

This restriction was done to prevent attacks around ".." and %-encoded ".."s, which malicious apps could use to try to escape out of an allowed path into a disallowed path.  For Beta1, we decided to start by being extra conservative in the characters we allowed and  then get feedback from you.

Does this character restriction prevent you from accomplishing your scenarios? What support do you need?

Where does Silverlight Look for the Cross Domain Policy File?

When a request is detected as a cross domain request, we look first for a Silverlight policy file at the root of the request’s server.

If such a clientaccesspolicy.xml file does not exist, we then look for a crossdomain.xml file at the same location.

Note:  Certain servers do not return a 404 for a missing clientaccesspolicy.xml but a custom error page.  Starting in Beta2, all malformed clientaccesspolicy.xml’s will trigger a fallback to the look for the crossdomain.xml

"Caching" Of Policy Files

Silverlight looks up the cross domain policy file for a particular server ONCE per application session.  (Where an application session is the lifetime of a particular xap or xaml page instance in memory.) 

Also, we use the browser networking stack to issue the request for the policy file, so the normal browser caching of the request happens under the covers.

Redirects

Redirects for the policy file itself are not allowed.

Request URIs redirects will only be successful if the original and final URIs are allowed via the appropriate cross domain policy.  (Note:  The browser handles handles the actual redirect logic itself and ensures it matches w3 spec.)

So that’s the high level cross domain behavior overview.  Next time, we’ll drill into how to set up a cross domain policy file.