2010-01-15 8 views
0

J'ai un contrôle Silverlight 3 qui effectue une requête HTTP inter-domaine vers http: // somedomain /. J'utilise la pile HTTP du navigateur pour faire cette demande. Un clientaccesspolicy.xml approprié sur somedomain est en place.Silverlight n'envoie pas de cookies dans les requêtes de navigateur inter-domaines

Mon navigateur a un ensemble de cookies pour somedomain et je veux que ceux-ci soient utilisés lorsque ladite requête HTTP est faite. Lorsque mon contrôle Silverlight est chargé depuis http: // localhost /, aucun de mes cookies ne semble être transmis (j'utilise Fiddler pour tracer le trafic HTTP)! Lorsque je télécharge le xap sur http: // quelquechose/alors et que je le charge à partir de là (pour que la requête HTTP ne soit pas interdomaine), je vois que tous les cookies de mon navigateur/IE pour somedomain sont transmis et tout va bien.

Est-ce un comportement prévu? J'ai vérifié MSDN et il dit que les cookies de navigateur sont toujours transmis, indépendamment du fait que la demande est inter-domaine ou non.

Merci d'avance!

+0

Est-ce que "somedomain" a vraiment la forme "somedomain" ou est-ce de la forme "somedomain.com"? – AnthonyWJones

Répondre

0

En fait, lorsque vous utilisez la pile HTTP du navigateur Silverlight n'a pas beaucoup de contrôle sur la façon dont les cookies sont gérés. Il laisse les paramètres configurés par l'utilisateur dans le navigateur.

Il peut être utile de modifier votre fichier HOSTS et de placer votre adresse IP à un nom comme "myhost.mydomain.com" (oui, vous pouvez simplement choisir ce que vous voulez). Maintenant, visitez votre site local en utilisant ce nom d'hôte. Sous IE localhost est placé dans une zone différente de celle de l'Internet plus large et vous pouvez trébucher sur certaines limitations wierd lors de la traversée d'une zone à une autre. L'utilisation d'un FQDN comme ci-dessus devrait placer votre site dans la zone internet. Cela permettra au moins d'éliminer les problèmes de zone en tant que source de ce problème.

Un autre test serait d'utiliser Firefox à la place.

+0

Merci, il semble que les différentes zones étaient en effet la raison de cela. Avec un FQDN factice, tout fonctionne bien. –

1

Heures passées avec un problème similaire. Il s'avère que le site n'était pas dans les sites de confiance. Cela semblait empêcher le Browser WebRequest que Silverlight SharePoint ClientContext utilise pour envoyer les cookies requis (FedAuth dans mon cas).