2009-04-20 5 views
2

Je passe mon temps à appeler un service RESTful depuis Silverlight. Je rencontre cette erreur:Utilisation de client Web dans Silverlight

{System.Security.SecurityException ---> System.Security.SecurityException: Security error. 
    at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult) 
    at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState) 
    at System.Net.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState) 
    --- End of inner exception stack trace --- 
    at System.Net.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state) 
    at System.Net.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult) 
    at System.Net.WebClient.GetWebResponse(WebRequest request, IAsyncResult result) 
    at System.Net.WebClient.OpenReadAsyncCallback(IAsyncResult result)} 

Ce qui semble être une erreur courante lors de l'utilisation du client Web. Je l'ai mis en place un clientaccesspolicy.xml

<?xml version="1.0" encoding="utf-8" ?> 
    <access-policy> 
    <cross-domain-access> 
     <policy> 
     <allow-from http-request-headers="*"> 
      <domain uri="*" /> 
     </allow-from> 
     <grant-to> 
      <resource path="/" include-subpaths="true" /> 
     </grant-to> 
    </policy> 
    </cross-domain-access> 
    </access-policy> 

et je l'ai regardé le silverlight dans Fiddler et il fait une demande sur le site Web et fait obtenir un statut 200 arrière.

public void login(string userName, string password) 
     { 
      WebClient client = new WebClient(); 
      Uri uri = new Uri(serverURI + "/clientaccesspolicy.xml"); 
      client.OpenReadCompleted += new OpenReadCompletedEventHandler(login_Complete); 
      client.OpenReadAsync(uri); 
     } 

     private void login_Complete(object sender, OpenReadCompletedEventArgs e) 
     { 
      byte[] buffer = new byte[e.Result.Length]; //crashes here with exception 
      ... 
     } 

Je suis plus ou moins à court d'idées. Quelqu'un sait ce que je fais mal? Y at-il un problème avec l'exécution de Silverlight directement à partir d'un fichier: // uri? J'ai supprimé le fichier clientaccesspolicy.xml et conservé uniquement le fichier crossdomain.xml en place et tout bingo a fonctionné. Cela me fait croire que l'erreur est dans le fichier clientaccesspolicy mais j'ai copié cela directement à partir de microsoft. Ce qui donne?

Répondre

3

Vous ne pouvez pas demander de contenu à partir d'un site Web si votre application Silverlight s'exécute à partir d'un fichier: // URL.

Pour plus d'informations, voir URL Access Restrictions in Silverlight.

+0

Cela semble logique mais cela n'explique pas vraiment pourquoi la suppression du fichier clientaccesspolicy.xml l'a corrigé. – stimms

0

Mmm ...

Essayez avec ce fichier de domaine croix

<?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 include-subpaths="true" path="/"/> 
      </grant-to> 
     </policy> 
    </cross-domain-access> 
</access-policy> 
5

Je viens de passer 3 heures à regarder dans cette question. La politique d'accès inter-domaine et les fichiers de stratégie d'accès client étaient une impasse pour moi. Rien ne marcherait. Puis finalement, j'ai rencontré un post sur les forums Silverlight.net par un employé de Microsoft qui m'a aidé à résoudre le problème. La réponse, au moins dans mon cas, était la page Web de test générée par Visual Studio lors de la création d'une nouvelle application SilverLight.

Fondamentalement, vous obtenez deux options lorsque vous démarrez un projet Silverlight. La première option génère dynamiquement une page html lorsque vous exécutez votre application. La deuxième option créera un projet ASP.NET distinct qui hébergera votre application Silverlight. Si vous choisissez la première option (page de test dynamique), vous ne serez pas en mesure de faire des demandes interdomaines, même si vos deux projets sont sur la même case, cela sera considéré comme un appel interdomaine et échouera (je ne sais pas pourquoi

Créez un autre projet Silverlight, choisissez la seconde option et déplacez vos fichiers XAML. Cela devrait résoudre votre problème.

0

X-Cubed est correct, vous ne pouvez pas faire de requêtes inter-domaines depuis le fichier: //, comme l'a souligné Adam Berent, cela signifie que si vous utilisez le TestPage généré par Visual Studio, vos requêtes réseau échoueront. Une solution de contournement consiste à lancer TestPage en utilisant Chiron (généralement utilisé pour les langages dynamiques) pour le servir (parce que l'accès est sur http: //) ou sur un serveur Web de développement. La capture est que vous devez réellement attacher le débogueur manuellement au navigateur afin de déboguer avec le réseautage (vous ne pouvez pas simplement appuyer sur F5.

Questions connexes