Network Access from Silverlight and Cross Domain Access Guidelines
Silverlight framework provides two kinds of APIs to access network
resources from Silverlight clients:
1. WebClient and other HTTP classes in System.Net namespace
like HttpWebRequest and
HttpWebResponse classes. This is for
http based communication.
2. Socket classes in the System.Net.Sockets namespace -
mainly TCP based communication.
Some of the important features of HTTP/HTTPS based communication from
Silverlight are:
* Same domain calls are always allowed and cross domain calls
require appropriate policy file and
permissions on web server hosting web
service.
* Only asynchronous communication is allowed.
* Only GET and POST verbs are supported
To avoid issues like Cross-Site Scripting (XSS), Silverlight runtime inherently
puts some restrictions in the framework APIs. Any HTTP or TCP based access which
makes cross domain requests requires that the server has explicitly granted
permissions to access its resources from Silverlight client. Cross domain access
means the Silverlight client is making network calls to domain which is not same
as the domain from which the client itself has been downloaded. These
restrictions are same as what Flash based clients also experience.
To allow flash based clients to access its resources, servers need to place a
policy file at the root of the domain called crossdomain.xml and all access
permission in that file. Its a xml format file with published format.
Silverlight uses the same logic to allow the APIs to access cross domain
resources. It support flash based policy file. It also supports a file specific
to Silverlight clients named as clientaccesspolicy.xml. This is also a xml based
file with published format but different from flash format.
Silverlight runtime first tries to download the clientaccesspolicy.xml file and
if found, all access permissions are granted using this file. If this file is
not available, it tries to download flash based policy file. If none is found,
access is denied. These files are not downloaded in case of same domain access.
Here is the format of Silverlight policy file :
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- A DTD for the Silverlight Policy File -->
<!ELEMENT access-policy (cross-domain-access)>
<!ELEMENT cross-domain-access (policy+)>
<!ELEMENT policy (allow-from)>
<!ELEMENT policy (grant-to)>
<!ELEMENT allow-from (domain+)>
<!ATTLIST allow-from http-request-headers CDATA>
<!ELEMENT domain EMPTY >
<!ATTLIST domain uri CDATA #REQUIRED>
<!ELEMENT grant-to (resource+)>
<!ELEMENT grant-to (socket-resource+)>
<!ELEMENT grant-to EMPTY>
<!ATTLIST resource path CDATA #REQUIRED>
<!ATTLIST resource include-subpaths (true|false) "false">
<!ATTLIST socket-resource port CDATA #REQUIRED protocol #REQUIRED>
Cross domain access issues can come into picture in various scenarios right from
development to deployment.
When using Visual Studio's in-built web server to test your client and web
service, make sure both are hosted in same solution or host them in IIS. Even
the port number is part of the domain.
If you are trying to create a client for an external RSS feed which doesn't have
policy files, you can try burning that feed using services like feedburner which
allows access to Silverlight clients.
|
|
|