1. Problem
You need your Silverlight client to access resources or services in a domain different from the one from which it originated.
2. Solution
Create an appropriate cross-domain policy on the target domain.
3. How It Works
Attacks where malicious code
may make unauthorized calls to a remote services domain or flood the
network with a large number of calls to effect denial of service are
common threats on the Internet. To prevent this, Silverlight requires an
explicit opt-in for a target remote domain to allow a Silverlight
application to access network resources in that domain. The domain from
which the Silverlight application is served is also called the site of origin, and a remote domain is any network location other than the site of origin.
This opt-in is implemented by
way of a policy file that is downloaded by the Silverlight runtime and
evaluated for access permissions. The policy file is defined in an XML
syntax and must be named clientaccesspolicy.xml.
For HTTP-based
communication (which includes the WebClient and the other HTTP
communication classes, as well as the Silverlight WCF client proxy
implementation), the owner of the target domain needs to place such a
policy file at the root of the target site. When your Silverlight
application makes the first HTTP request to the target domain in
question, the Silverlight runtime tries to download the policy file from
the site's root. If the download is successful, the runtime then
evaluates the policy settings in the file to determine whether
appropriate access has been granted to the resources being requested by
the client application. On successful evaluation and the presence of
appropriate permissions, the application is allowed to continue with the
network call. Otherwise, the network call fails. Figure 1 shows the sequence of calls for cross-domain access over HTTP.
Also note that Silverlight supports the Flash cross-domain access policy format as well. In the previous scenario, if a clientaccesspolicy.xml is not found, the runtime tries to download a Flash policy file named crossdomain.xml and base resource access on the policy specified there.
For sockets-based
communication, a similar policy file is used, but there are a few more
details. For Silverlight applications using sockets, the cross-domain
policy requirements apply to cross-domain calls as well as those back to
the site of origin. On the first attempt to open a connection to a TCP
endpoint from a Silverlight application, the runtime attempts to open
another TCP connection to the target server (cross-domain or site of
origin) at port 943. If this connection succeeds, the runtime then tries
to download the policy file over this connection. If the download
succeeds, the connection is closed and the downloaded policy file is
used for the rest of the session. Figure 2 shows the sequence of calls for cross-domain access over TCP sockets.
All of this happens behind
the scenes as far as your Silverlight code is concerned, so no specific
design or code consideration is necessary on the client side for either
your HTTP or sockets-based code. However, if you are also implementing
the sockets-based server, you need to implement a listener on port 943
and be prepared to serve the policy file when the request comes in. The
request is in the form of a special string constant of the value <policy-file-request/>.
4. The Code
Listing 1 shows a sample policy file for HTTP resource access.
Listing 1. Sample clientaccesspolicy.xml for HTTP Access
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="MyHeader, X-API-*">
<domain uri="http://subdomain1.mydomain.com"/>
<domain uri="http://subdomain2.mydomain.com"/>
<domain uri="http://mydomain.com:8181"/>
</allow-from>
<grant-to>
<resource path="/images "/>
<resource path="/services" include-subpaths="True"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
|
Multiple domain entries
can be used to specify specific subdomains on a root domain or
nonstandard HTTP ports that are allowed to be accessed. If your domain
does not have subdomains or nonstandard ports, or if you want to grant
access to the entire domain regardless, include one domain entry, as shown here:
<allow-from>
<domain uri="*"/>
</allow-from>
Each resource entry specifies a resource for which access permission is granted, with the path property containing the root relative path to the resource. The optional include-subpaths defaults to False and can be left out. If you want to grant access to subpaths for a specific path as well, set include-subpaths to True, as shown in Listing 1. Specifying one resource entry with the path value set to / and include-subpaths set to True allows full access to all resources in the site, as shown here:
<grant-to>
<resource path="/" include-subpaths="True"/>
</grant-to>
The optional http-request-headers attribute on the allow-from element can be a comma-separated list of allowed HTTP request headers, where you can use an asterisk (*) as a part of a header name to indicate a wildcard. You can also replace the entire list and use the * wildcard to allow all possible headers. If the attribute is left out, no HTTP headers are allowed.
Listing 2 shows a clientaccesspolicy.xml file for sockets-based access.
Listing 2. Sample clientaccesspolicy.xml for sockets-based access
<?xml version="1.0" encoding ="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="*" />
</allow-from>
<grant-to>
<socket-resource port="4502-4534" protocol="tcp" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
|
The difference here is in the use of the socket-resource element. The socket-resource element has two attributes. The port attribute can be used to specify the range of ports allowed, where the range has to be within 4502–4534. The protocol attribute allows tcp as the only possible value in this version of Silverlight. They are both required attributes. 
