HTTP Communication and Security with Silverlight

If you are communicating with a SOAP, WCF, or ASP.NET AJAX Web service, you can create a proxy class from the Web service metadata and use the proxy to communicate with the Web service. Silverlight uses Windows Communication Foundation (WCF) capabilities to create proxies and send SOAP 1.1 messages over HTTP. If you are using Visual Studio, you can right-click your Silverlight project and select Add Service Reference to have the proxy automatically created for you. The proxy creates the messages and handles the network communication for you. For more information about how to create Web services to interact with Silverlight and how to generate proxies to use with existing Web services, see Building and Accessing Services using Generated Proxies.

You can also use the Add Service Reference dialog box in Visual Studio to add a reference to any service that exposes an Open Data Protocol (OData) feed. Silverlight is able to consume OData feeds by using the WCF Data Services client library for Silverlight. For more information about working with OData feeds in a Silverlight-based application, see WCF Data Services (Silverlight).

If you want to make HTTP calls yourself, you can use the following classes found in the System.Net namespace.

• WebClient

• HttpWebRequest and HttpWebResponse

These classes enable you to make GET and POST requests and allow request headers in some cases. In addition, you can configure these classes to enable progressive downloads on GET requests.

WebClient Class

    ' Create the web client. 
    Private client As New WebClient()
    Public Sub New()
        InitializeComponent()

        ' Associate the web client with a handler for its 
        ' UploadStringCompleted event. 
        AddHandler client.UploadStringCompleted, AddressOf client_UploadStringCompleted
    End Sub



    Private Sub Button_Click(ByVal sender As Object, ByVal e As RoutedEventArgs)
        ' Create the request. 
        Dim postRequest As String = "<entry xmlns='http://www.w3.org/2005/Atom'>" + _
            "<title type='text'>New Restaurant</title>" + _
             "<content type='xhtml'>" + _
             " <div xmlns='http://www.w3.org/1999/xhtml'>" + _
             " <p>There is a new Thai restaurant in town!</p>" + _
             " <p>I ate there last night and it was <b>fabulous</b>.</p>" + _
             " <p>Make sure and check it out!</p>" + _
             " </div>" + " </content>" + _
             " <author>" + _
             " <name>Pilar Ackerman</name>" + _
             " <email>packerman@contoso.com</email>" + _
             " </author>" + _
             "</entry>"

        ' Sent the request to the specified URL. 
        client.UploadStringAsync(New Uri("http://blogs.contoso.com/post-create?blogID=1234", _
            UriKind.Absolute), postRequest)
    End Sub

    ' Event handler for the UploadStringCompleted event. 
    Private Sub client_UploadStringCompleted(ByVal sender As Object, _
         ByVal e As UploadStringCompletedEventArgs)
        ' Output the response. 
        If e.[Error] IsNot Nothing Then
            tb1.Text = e.[Error].Message
            If tb1.Text = "" Then
                tb1.Text = e.Error.InnerException.Message
            End If


        Else
            tb1.Text = e.Result
        End If
    End Sub

    // Create the web client.
        WebClient client = new WebClient();
        public Page()
        {
            InitializeComponent();

       // Associate the web client with a handler for its
       // UploadStringCompleted event.
            client.UploadStringCompleted += 
                new UploadStringCompletedEventHandler(client_UploadStringCompleted);
        }



        private void Button_Click(object sender, RoutedEventArgs e)
        {
       // Create the request. 
            string postRequest = "<entry xmlns='http://www.w3.org/2005/Atom'>"
            + "<title type='text'>New Restaurant</title>"
            + "<content type='xhtml'>"
            + "  <div xmlns='http://www.w3.org/1999/xhtml'>"
            + "   <p>There is a new Thai restaurant in town!</p>"
            + "   <p>I ate there last night and it was <b>fabulous</b>.</p>"
            + "   <p>Make sure and check it out!</p>"
            + "  </div>"
            + " </content>"
            + " <author>"
            + "   <name>Pilar Ackerman</name>"
            + "  <email>packerman@contoso.com</email>"
            + " </author>"
            + "</entry>";

        // Sent the request to the specified URL.
            client.UploadStringAsync(new                 Uri("http://blogs.contoso.com/post-create?blogID=1234",
                UriKind.Absolute), postRequest); 
        }

        // Event handler for the UploadStringCompleted event.
        void client_UploadStringCompleted(object sender, 
           UploadStringCompletedEventArgs e)
        {
        // Output the response. 
            if (e.Error != null)
                tb1.Text = e.Error.Message;
            else
                tb1.Text = e.Result;
        }

HttpWebRequest and HttpWebResponse Classes

    Private syncContext As SynchronizationContext

    Private Sub Button_Click(ByVal sender As Object, ByVal e As RoutedEventArgs)
        ' Grab SynchronizationContext while on UI Thread 
        syncContext = SynchronizationContext.Current

        ' Create request 
        Dim request As HttpWebRequest = _
            TryCast(WebRequest.Create(New Uri("http://blogs.contoso.com/post-create?blogID=1234", _
            UriKind.Absolute)), HttpWebRequest)
        request.Method = "POST"


        ' Make async call for request stream.
        ' Callback will be called on a background thread. 
        Dim asyncResult As IAsyncResult = _
            request.BeginGetRequestStream(New AsyncCallback(AddressOf RequestStreamCallback), _
            request)

    End Sub

    Private statusString As String

    Private Sub RequestStreamCallback(ByVal ar As IAsyncResult)
        Dim request As HttpWebRequest = TryCast(ar.AsyncState, HttpWebRequest)
        request.ContentType = "application/atom+xml"
        Dim requestStream As Stream = request.EndGetRequestStream(ar)
        Dim streamWriter As New StreamWriter(requestStream)

        streamWriter.Write("<entry xmlns='http://www.w3.org/2005/Atom'>" + _
            "<title type='text'>New Restaurant</title>" + "<content type='xhtml'>" + _
            " <div xmlns='http://www.w3.org/1999/xhtml'>" + _
            " <p>There is a new Thai restaurant in town!</p>" + _
            " <p>I ate there last night and it was <b>fabulous</b>.</p>" + _
            " <p>Make sure and check it out!</p>" + _
            " </div>" + _
            " </content>" + _
            "<author>" + _
            " <name>Pilar Ackerman</name>" + _
            " <email>packerman@contoso.com</email>" + _
            " </author>" + _
            "</entry>")
    
    ' Close the stream.
        streamWriter.Close()

        ' Make async call for response. Callback will be called on a background thread. 
        request.BeginGetResponse(New AsyncCallback(AddressOf ResponseCallback), _
            request)

    End Sub
    Private Sub ResponseCallback(ByVal ar As IAsyncResult)
        Dim request As HttpWebRequest = TryCast(ar.AsyncState, HttpWebRequest)
        Dim response As WebResponse = Nothing
        Try
            response = request.EndGetResponse(ar)
        Catch we As WebException
            statusString = we.Status.ToString()
        Catch se As SecurityException
            statusString = se.Message
            If statusString = "" Then
                statusString = se.InnerException.Message
            End If
        End Try

        ' Invoke onto UI thread 
        syncContext.Post(AddressOf ExtractResponse, response)
    End Sub

    Private Sub ExtractResponse(ByVal state As Object)
        Dim response As HttpWebResponse = TryCast(state, HttpWebResponse)

        If response IsNot Nothing AndAlso response.StatusCode = HttpStatusCode.OK Then
            Dim responseReader As New StreamReader(response.GetResponseStream())

            tb1.Text = response.StatusCode.ToString() + " Response: " _
            + responseReader.ReadToEnd()
        Else
            tb1.Text = "Post failed: " + statusString
        End If
    End Sub

SynchronizationContext syncContext;
private void Button_Click(object sender, RoutedEventArgs e)
{
    // Grab SynchronizationContext while on UI Thread   
    syncContext = SynchronizationContext.Current;

    // Create request   
    HttpWebRequest request =
        WebRequest.Create(new Uri("http://blogs.contoso.com/post-create?blogID=1234", 
            UriKind.Absolute))
            as HttpWebRequest;
    request.Method = "POST";


    // Make async call for request stream.  Callback will be called on a background thread.  
    IAsyncResult asyncResult =
        request.BeginGetRequestStream(new AsyncCallback(RequestStreamCallback), request);

}
string statusString;
private void RequestStreamCallback(IAsyncResult ar)
{
    HttpWebRequest request = ar.AsyncState as HttpWebRequest;
    request.ContentType = "application/atom+xml";
    Stream requestStream = request.EndGetRequestStream(ar);
    StreamWriter streamWriter = new StreamWriter(requestStream);

    streamWriter.Write("<entry xmlns='http://www.w3.org/2005/Atom'>"
    + "<title type='text'>New Restaurant</title>"
    + "<content type='xhtml'>"
    + "  <div xmlns='http://www.w3.org/1999/xhtml'>"
    + "   <p>There is a new Thai restaurant in town!</p>"
    + "   <p>I ate there last night and it was <b>fabulous</b>.</p>"
    + "   <p>Make sure and check it out!</p>"
    + "  </div>"
    + " </content>"
    + "<author>"
    + "   <name>Pilar Ackerman</name>"
    + "  <email>packerman@contoso.com</email>"
    + " </author>"
    + "</entry>");


    // Close the stream.
    streamWriter.Close();

    // Make async call for response.  Callback will be called on a background thread.
    request.BeginGetResponse(new AsyncCallback(ResponseCallback), request);

} 
private void ResponseCallback(IAsyncResult ar)  
{  
    HttpWebRequest request = ar.AsyncState as HttpWebRequest;
    WebResponse response = null;
    try
    {
        response = request.EndGetResponse(ar);
    }
    catch (WebException we)
    {
        statusString = we.Status.ToString();
    }
    catch (SecurityException se)
    {
        statusString = se.Message;
        if (statusString == "")
            statusString = se.InnerException.Message;
    }

    // Invoke onto UI thread  
    syncContext.Post(ExtractResponse, response);  
} 

private void ExtractResponse(object state)  
{  
    HttpWebResponse response = state as HttpWebResponse;

    if (response != null && response.StatusCode == HttpStatusCode.OK) 
    {
        StreamReader responseReader = new StreamReader(response.GetResponseStream());


        tb1.Text = response.StatusCode.ToString() + 
            " Response: "  + responseReader.ReadToEnd();
    }
    else
        tb1.Text = "Post failed: " + statusString;
}

You can enable Web services to be called by a Silverlight application in another domain by deploying a Web service that uses the correct cross-domain policy file at the root of the domain. Silverlight supports two types of cross-domain policy files.

• Silverlight client access policy file (clientaccesspolicy.xml)

• A subset of the Adobe Flash cross-domain policy file (crossdomain.xml)

The following illustration shows an example of cross-domain communication by using a client access policy file.

In general, when a Silverlight application detects that its request is a cross-domain request, it will first look for the Silverlight client access policy file (clientaccesspolicy.xml) at the application root of the Web service. If this request causes a 404 Not Found or other error, the application will then look for the Adobe Flash cross-domain policy file (crossdomain.xml) at the application root. Redirects for the cross-domain policy file are not allowed. In addition, the cross-domain policy file is requested only once per application session.

The following table lists example request Uniform Resource Identifiers (URIs) and where the Silverlight application will look for the cross-domain policy file.

As mentioned previously, redirects on cross-domain policy files are not allowed. However, a Silverlight application will follow a redirect for a target resource. The resource can be retrieved only if access is granted by the following:

• The cross-domain policy file at the domain indicated by the original URI before redirection.

• The cross-domain policy file at the domain indicated by the final URI after all redirections.

There are important security considerations before you allow Silverlight clients to access Web services in a cross-domain situation. Whenever you put a client access policy file in place, you should configure your Web server hosting the Web services to disable browser caching. This enables you to easily update the file or restrict access to your Web services if necessary. Once the client access policy file is checked, it remains in effect for the browser session so the impact of non-caching to the end-user is minimal. 

If you provide HTTP and HTTPS sites for your domain, you should provide a client access policy specific to each protocol for the domain. In the client access policy file, you should only enable calls from the same protocol as the hosting domain. For example, if your domain is https://contoso.com, your policy file should only enable Silverlight clients using the HTTPS protocol like the following example.

<allow-from http-request-headers="*">
        <domain uri="https://fabrikam.com"/>
        <domain uri="https://www.adatum.com"/>
      </allow-from>

To prevent malicious attacks, you should never provide one client access policy file for HTTP and HTTPS versions of your domain that enable calls from both HTTP and HTTPS clients. For example, you should never do the following in a single client access policy file.

<!--DO NOT DO THIS-->
<allow-from http-request-headers="*">
        <domain uri="https://fabrikam.com"/> 
        <domain uri="https://fabrikam.com"/>
      </allow-from>

In addition, all Silverlight requests are sent with cookies and authentication. This means that if you have Web services that allow users to access private information, you should host these in a different domain than the Web services exposed to third-party callers. For example, consider that you have a Web store hosted at http://www.tailspintoys.com. Your site allows customers to store billing information that includes credit card numbers. You should not expose a Web service that returns product inventory to third-party Silverlight clients at the same domain. Because cookies and authentication are sent with each message, if you host these Web services on the same domain, you have effectively given the third-party callers access to your customer's private billing information. In this example, your publicly exposed Web services could safely be hosted at http://services.tailspintoys.com, because this is a different domain. You must carefully consider who you have exposed Web services to, and what other Web services are located at that domain. Also, you should always keep your client access policy file as restrictive as possible. For more information about exposing secure Web services, see Security Considerations for Service Access and Making a Service Available Across Domain Boundaries.

The Silverlight client access policy file is an XML file that has a simple format. The following example shows a Silverlight client access policy file. This example has two policy entries.

The first policy enables:

• GET and POST requests from all callers to the services path of the domain.

• SOAPAction Content-Type headers for all callers.

The second policy enables:

• All method requests from the www.contoso.com domain to the services path. These callers must be using Silverlight 3 or later and must be client HTTP handling to make method calls other than GET and POST.

• Does not allow headers on any calls

<?xml version="1.0" encoding="utf-8"?>
  <access-policy>
    <cross-domain-access>
      <policy>
        <allow-from http-request-headers="SOAPAction">
          <domain uri="*"/>
        </allow-from>
        <grant-to>
          <resource path="/services/" include-subpaths="true"/>
        </grant-to>
     </policy>
      <policy >
        <allow-from http-methods="*">
          <domain uri="https://www.contoso.com"/>
        </allow-from>
        <grant-to>
          <resource path="/services/" include-subpaths="true"/>
        </grant-to>
     </policy>
    </cross-domain-access>
  </access-policy>

A file may contain as many policy entries as necessary for a particular application root. Calls are allowed per a union of all the policy entries in the file. In this example, if a POST request including a SOAPAction header came from www.contoso.com, it would be allowed per the first policy. For more information on the format of the client access policy file, see Network Security Access Restrictions in Silverlight.

The Silverlight client access policy file (clientaccesspolicy.xml) can contain a wildcard character (*). The wildcard character can be used to give all domains access to your services, but in general you should limit cross-domain access to a minimal set of domains that you know will require access. In addition, how you use the wildcard character affects communication between HTTP and HTTPS, or cross-scheme, callers, and services.

The following table lists the possible values for the domain node and the effect each value has during cross-scheme access.

In addition, you can use the wildcard character to enable callers from specific sub-domains in the <AllowFrom> section of the client access policy file. The following example shows an excerpt of Silverlight client access policy file that uses the wildcard character to enable requests from a sub domain.

<?xml version="1.0" encoding="utf-8"?>
  <access-policy>
    <cross-domain-access>
      <policy >
        <allow-from http-request-headers="SOAPAction">
          <domain uri="http://*.tailspintoys.com"/>
        </allow-from>
...

You can enable additional HTTP methods for Silverlight applications by using client HTTP handling. You do this by setting the http-methods attribute to the wildcard character (*). If a Silverlight application is using browser HTTP handling, only GET and POST are enabled, regardless of the setting in the client access policy file. Some methods are restricted for security reasons.

<?xml version="1.0" encoding="utf-8"?>
  <access-policy>
    <cross-domain-access>
      <policy >
        <allow-from http-methods="*">
          <domain uri="http://*.tailspintoys.com"/>
        </allow-from>
...

With browser HTTP handling, request headers are permitted on cross-domain POST requests only when explicitly permitted in the client access policy file. Client HTTP handling enables request headers on all HTTP methods when permitted in the client access policy file. An exception to this rule is Content-Type headers. Content-Type headers are always allowed on cross-domain POST requests and do not need to be explicitly called in the client access policy file. You can also enable additional headers by setting http-request-headers to one of the following:

• A single header type (SOAPAction)

• A comma separated list of headers (SOAPAction, x-custom-header)

• The wildcard character to enable all headers (*)

Note:
For security reasons, Silverlight blocks SOAPAction headers that contain Universal Plug and Play (UPnP) instructions.

The following table summarizes the header support for client access requests.

Note:
The Mozilla Firefox browser does not currently set the Referer header on HTTP GET requests. As a result, a Silverlight application hosted in Firefox does not support the Referer header being set on any GET requests.

In addition to requiring a client access policy file, there are restrictions on the characters allowed in the path section of a cross-domain URI that is callable by a Silverlight application, if all paths and sub paths are not allowed. The following illustration shows the path portion of a URI.

The following characters are never allowed in a cross-domain request path when paths are restricted by the client access policy file.

• Consecutive dot characters (..)

• Dot followed by a forward slash (./)

• Percent sign (%)

For more information about the format of client access policy files and scenarios they enable, see Network Security Access Restrictions in Silverlight and Making a Service Available Across Domain Boundaries.

Silverlight supports a subset of the Adobe Flash cross-domain policy file (named crossdomain.xml). Silverlight supports the <allow-access-from> tag with the following attributes.

• The domain attribute. The only value that is permitted for this attribute is "*", which means that the entire domain is exposed to all callers.

• The secure attribute. This attribute is relevant only when the target domain is HTTPS. This attribute accepts a value of true or false, which indicates whether HTTP callers are allowed to access resources within this domain.

• The headers attribute. This attribute lists accepted headers.

The following is an example of an Adobe Flash cross-domain policy file (crossdomain.xml) supported by Silverlight.

<?xml version="1.0"?>
    <!DOCTYPE cross-domain-policy SYSTEM
     "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
    <cross-domain-policy>
       <allow-access-from domain="*"/ headers="SOAPAction" 
         secure="true">
    </cross-domain-policy>