Lifecycle of a Silverlight Request to a Web Application

Applies to: SharePoint Foundation 2010

This topic provides an overview of the major events and actions that occur when a Silverlight application, which is located in a different domain from SharePoint Foundation Web application but is exposed to SharePoint Foundation users in a Web Part, accesses data from the Web application. Since the Silverlight application is an external application, this topic also provides an example of the workings of Silverlight Cross-Domain Data Access.

Example Scenario

The lifecycle of a Silverlight request to SharePoint Foundation will be discussed in terms of the following concrete example.

A SharePoint Foundation server farm is located at //www.contoso.com/Internal/Sites/. Within the server farm, /Personnel/default.aspx is the home page of the Personnel department. This page contains a Silverlight Web Part (SilverlightWebPart). An external application provider (EAP) has been enabled for the Web service that contains the Web application. This made it possible for the Silverlight Web Part to be registered with External Application XML. Among other things, this XML specifies that the Silverlight application is the file http://www.fabrikam.com/Applications/PeopleBrowser.xap, which means that it is located in a different domain from the SharePoint Foundation Web application. Users can use the Silverlight application to lookup and display employee information from SharePoint Foundation lists on Web sites that are contained in the Web application. The code within the Silverlight application queries the SharePoint Foundation data by making calls to a special Silverlight version of the SharePoint 2010 Client Object Model. (See also, Using the Silverlight Object Model.)

Since the .xap file is located on a server outside the domain of the Web application whose data is being queried, this scenario would ordinarily require giving the external Fabrikam server full access to the Contoso SharePoint Foundation server. However, Silverlight Cross-Domain Data Access (Silverlight CDA) provides a way of turning these calls into permission-constrained calls to the SharePoint Foundation server object model.

Sequence of Events

These are the major events in the lifecycle of the Web Part and a Silverlight request for data.

1. A user navigates to //www.contoso.com/Internal/Sites/Personnel/default.aspx and the page opens in the browser.

2. The Silverlight Web Part loads, reads its ApplicationXml property to find the URL of the Silverlight application and makes a request to http://www.fabrikam.com/Applications/PeopleBrowser.xap. This is a request from the user’s computer directly to the www.fabrikam.com server. The request does not pass through the SharePoint Foundation front-end Web server.

3. Certain information from the External Application XML is passed to the Silverlight application from the Web Part. The most critical items of information are the following:

   • The user name of an application principal. Within the SharePoint Foundation Web application, an application principal is an SPUser object with certain properties set so that it can represent an application instead of a real person. Like any other user, the application principal has been given a set of permissions. The Silverlight application will only be able to access data and perform actions that are within the permissions of both the real user who has navigated to the page and the application principal. For more information about the application principal, see How to: Create an Application Principal User .

   • The URL, on the www.fabrikam.com domain, of a special kind of HTTP Request Handler called a request forwarder. For more information about creating this kind of handler, see How to: Create an HTTP Request Forwarder for External Applications.

   • A request token. A copy of this token will be included by the Silverlight application in all its requests to the SharePoint Foundation Web application. It contains information, such as the ID of the real user who navigated to the page containing the Web Part, which will enable the Web application to determine what effective permissions the Silverlight application should be allowed. To prevent tampering, the token will include a server hash value that is created when the Web Part’s CreateChildControls method runs. The hash is made from two inputs; the token prefix, which includes everything in the token before the hash value, and a secret internal byte array that is used as "salt" for the hash algorithm. The salt is created when the SPWebService object that represents the Web service is first created and the salt is recreated whenever that object is updated.

     Note

     If the server where the Silverlight application resides also needs to be sure that results it receives from the SharePoint Foundation Web application are not tampered with, a client hash can also be included in the request token that is being passed back and forth. For more information, see How to: Create a Custom External Application Provider.

4. The Silverlight application loads and its Startup event handler calls Init(IDictionary<String, String>) and passes it some initialization information including the following:

   • The URL of the request forwarder.

   • The request token, which will be added to the header of each request made by the Silverlight application.

5. When the user takes action in the Silverlight UI that initiates a request for SharePoint Foundation data, query-constructing code in the Silverlight application makes calls to a special Silverlight version of the managed client object model. This code must reference the special Silverlight client assemblies Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll. For more information on the Silverlight client object model, see Using the Silverlight Object Model and Silverlight Deployment.

6. At the end of the query code there is a call to the ExecuteQuery() method. Generally, this method passes the query to the SharePoint Foundation front-end Web server, but Silverlight will not make a direct cross-domain request. Because the Silverlight application was initialized at startup with the URL of the request forwarder, it submits the query to the request forwarder along with the URL of the SharePoint Foundation Web application.

7. The request forwarder then sends the query, as server code, to the front-end Web server, along with the user credentials of the application principal and the request token, which includes the server hash.

8. The SharePoint Foundation front-end Web server verifies the server hash and verifies that both the application principal and the real user who has navigated to the Web Part page have permission to do everything that the query code is written to do.

9. Assuming the server hash and the permissions are verified, the front-end Web server executes the code and returns data to the Silverlight application.

Graphic Look at the Request Lifecycle

Figure 1 shows the major events in the lifecycle of a request from a Silverlight application.

Figure 1: Lifecycle of Silverlight Request