Cycle de vie d’une demande Silverlight à une application Web

Dernière modification : mercredi 7 avril 2010

S’applique à : SharePoint Foundation 2010

Dans cet article
Exemple de scénario
Séquence des événements
Illustration graphique du cycle de vie d’une demande

Cette rubrique donne une vue d’ensemble des actions et événements majeurs qui se produisent lorsqu’une application Silverlight, située dans un autre domaine que l’application Web SharePoint Foundation mais exposée aux utilisateurs SharePoint Foundation dans un composant WebPart, accède à des données de l’application Web. Comme l’application Silverlight est une application externe, cette rubrique contient également un exemple des utilisations de l’accès aux données entre domaines Silverlight.

Exemple de scénario

Le cycle de vie d’une demande Silverlight à SharePoint Foundation est abordé dans l’exemple concret qui suit.

Une batterie de serveurs SharePoint Foundation est située à l’adresse //www.contoso.com/Internal/Sites/. Dans la batterie de serveurs, /Personnel/default.aspx est la page d’accueil du service Personnel. Cette page contient un composant WebPart Silverlight (SilverlightWebPart). Un fournisseur d’applications externes a été activé pour le service Web qui contient l’application Web. Ainsi, le composant WebPart Silverlight a pu s’inscrire après du Code XML d’application externe. Ce code XML spécifie, entre autre, que l’application Silverlight correspond au fichier http://www.fabrikam.com/Applications/PeopleBrowser.xap, ce qui signifie qu’elle est située dans un autre domaine que l’application Web SharePoint Foundation. Les utilisateurs peuvent avoir recours à l’application Silverlight pour rechercher des informations sur les employés et les afficher à partir de listes SharePoint Foundation sur des sites Web contenus dans l’application Web. Le code de l’application Silverlight interroge les données SharePoint Foundation en effectuant des appels à une version Silverlight spéciale du Modèle objet client managé. (Voir aussi Utilisation du modèle objet Silverlight.)

Dans la mesure où le fichier .xap se trouve sur un serveur en dehors du domaine de l’application Web dont les données sont interrogées, ce scénario devrait en temps normal donner au serveur Fabrikam externe un accès total au serveur SharePoint Foundation Contoso. Toutefois, l’accès aux données entre domaines Silverlight (Silverlight CDA) permet de transformer ces appels en appels contraints aux autorisations au modèle objet serveur SharePoint Foundation.

Séquence des événements

Voici les événements majeurs dans le cycle de vie du composant WebPart et une demande de données Silverlight :

1. Un utilisateur accède à la page //www.contoso.com/Internal/Sites/Personnel/default.aspx et celle-ci s’ouvre dans le navigateur.

2. Le composant WebPart Silverlight est chargé. Il lit sa propriété ApplicationXml pour déterminer l’URL de l’application Silverlight et il effectue une demande auprès de http://www.fabrikam.com/Applications/PeopleBrowser.xap. Il s’agit d’une demande directe de l’ordinateur de l’utilisateur au serveur www.fabrikam.com. La demande ne passe pas par le biais du serveur Web frontal SharePoint Foundation.

3. Certaines informations du code XML de l’application externe sont passées à l’application Silverlight à partir du composant WebPart. Les informations les plus importantes sont les suivantes :

   • Nom d’utilisateur du principal d’application. Dans l’application Web SharePoint Foundation, un principal d’application est un objet SPUser avec certaines propriétés définies de sorte qu’il puisse représenter une application au lieu d’une personne réelle. Tout comme un utilisateur, le principal d’application s’est vu accorder un ensemble d’autorisations. L’application Silverlight pourra uniquement accéder aux données et exécuter les actions qui sont autorisées pour l’utilisateur réel qui a accédé à la page et le principal d’application. Pour plus d’informations sur le principal d’application, voir Procédure : créer un utilisateur principal d’application .

   • URL, sur le domaine www.fabrikam.com, d’un type spécial de gestionnaire de requêtes appelé redirecteur de demande. Pour plus d’informations sur la création de ce type de gestionnaire, voir Procédure : créer un redirecteur de demande HTTP pour des applications externes.

   • Un jeton de demande. Une copie de ce jeton sera incluse par l’application Silverlight dans toutes ses demandes à l’application Web SharePoint Foundation. Ce jeton contient des informations, telles que l’ID de l’utilisateur réel qui a accédé à la page contenant le composant WebPart, qui permettent à l’application Web de déterminer quelles autorisations effectives doivent être accordées à l’application Silverlight. Pour empêcher toute falsification, le jeton contient une valeur de hachage serveur créée lors de l’exécution de la méthode CreateChildControls du composant WebPart. Le code de hachage est composé de deux entrées ; le préfixe du jeton qui contient toutes les informations du jeton avant la valeur de hachage et un tableau d’octets interne et secret servant de « sel » pour l’algorithme de hachage. Le sel est créé lorsque l’objet SPWebService représentant le service Web est créé pour la première fois et il est recréé dès que cet objet est mis à jour.

     Notes

     Si le serveur sur lequel réside l’application Silverlight doit également s’assurer que les résultats qu’il reçoit de l’application Web SharePoint Foundation ne sont pas falsifiées, il est possible d’inclure un code de hachage client dans le jeton de demande qui est passé. Pour plus d’informations, voir Procédure : créer un fournisseur d’applications externes personnalisées.

4. L’application Silverlight est chargée et son gestionnaire d’événements Startup appelle Init(IDictionary<String, String>) et lui passe des informations d’initialisation, notamment :

   • l’URL du redirecteur de la demande ;

   • le jeton de demande qui sera ajouté à l’en-tête de chaque demande effectuée par l’application Silverlight.

5. Lorsque l’utilisateur exécute une action dans l’interface utilisateur de Silverlight qui initie une demande pour les données SharePoint Foundation, du code de construction de demande de l’application Silverlight effectue des appels à une version Silverlight spéciale du modèle objet client managé. Ce code doit référencer les assemblys clients Silverlight spéciaux Microsoft.SharePoint.Client.Silverlight.dll et Microsoft.SharePoint.Client.Silverlight.Runtime.dll. Pour plus d’informations sur le modèle objet client Silverlight, voir Utilisation du modèle objet Silverlight et Déploiement Silverlight.

6. Un appel à la méthode ExecuteQuery() se trouve à la fin du code de la demande. En règle générale, cette méthode passe la demande au serveur Web frontal SharePoint Foundation, mais Silverlight n’effectue pas de demande directe entre domaines. Comme l’application Silverlight a été initialisée au démarrage avec l’URL du redirecteur de demande, elle envoie la demande au redirecteur avec l’URL de l’application Web SharePoint Foundation.

7. Le redirecteur envoie ensuite la demande, sous la forme de code serveur, au serveur Web frontal avec les informations d’identification utilisateur du principal d’application et le jeton de demande, qui comprend le code de hachage serveur.

8. Le serveur Web frontal SharePoint Foundation vérifie le code de hachage serveur et s’assure que le principal d’application et l’utilisateur réel ayant accédé à la page du composant WebPart sont autorisés à exécuter toutes les actions pour lesquelles a été écrit le code de demande.

9. Dans l’hypothèse que que le code de hachage serveur et les autorisations ont été vérifiées, le serveur Web frontal exécute le code et retourne les données à l’application Silverlight.

Illustration graphique du cycle de vie d’une demande

La figure 1 montre les événements majeurs du cycle de vie d’une demande à partir d’une application Silverlight.

Figure 1 : cycle de vie d’une demande Silverlight