Silverlight clientaccesspolicy.xml bug? ou design?

Question

Dans le noeud de domaine d'un fichier clientaccesspolicy, vous pouvez spécifier un caractère générique pour un sous-domaine ou un protocole, mais pas pour un port.

Plus précisément lors du développement, si le service consommé est hébergé sur un tiers, puis accéder à partir d'une version de débogage locale d'une application silverlight en cours d'exécution sur le serveur de développement localhost asp.net fonctionne très bien avec les nœuds:

<domain uri="*"/> 
<domain uri="http://*"/> 
<domain uri="http://localhost:1234"/> 

(où 1234 est le numéro de port déterminé spécifique)

mais il semble ne pas fonctionner si elle est spécifiée sous la forme

<domain uri="http://localhost:*"/> 

ce qui est extrêmement ennuyeux si plusieurs développeurs/projets utilisent le service ou si vous ne spécifiez pas de port pour le serveur de développement asp.net

Est-ce que annyone sait si je reçois simplement le format incorrect ou est-ce soit un bug? ou un oubli dans la gestion de la politique d'accès client par silverlight?

Answer 1

Le comportement que vous décrivez est conforme à la documentation, qui stipule:

Il existe trois types de caractères génériques autorisés:

A autonome '*' joker. Cette option est utilisée pour autoriser l'accès à tous les domaines du même schéma. Un service HTTP autorisera tous les appelants HTTP. Un service HTTPS permettra à tous les appelants HTTPS.

Un caractère générique littéral "http: // *". Cette option autorise explicitement tous les appelants HTTP , même s'il s'agit d'un service HTTPS .

Un caractère générique de sous-domaine. Cette option utilise un caractère générique au premier segment du chemin ("http: // .contoso.com", pour l'exemple ) qui autorise tous les sous-domaines de le domaine spécifié. Donc, pour l'exemple . http://web.contoso.com et http://mail.contoso.com serait autorisé. Notez qu'un chemin uri où le caractère générique ne se produit pas en tant que préfixe (http://web. .com, par exemple) n'est pas autorisé.

http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx

Donc, il n'y a rien pour les ports wildcards, qui (vous avez raison) ne fait pas de sens quand vous permettez wildcards pour les hôtes et les domaines.

Answer 2

travail autour:

Sous Propriétés de votre site d'hébergement de l'application SL, accédez à l'onglet Web, et changer la fonction Auto-assigner Port à Port spécifique.De cette façon, vous pouvez définir votre port localhost: 1234 dans le fichier clientaccesspolicy comme vous l'avez déjà illustré, et vous attendre à ce qu'il ne nécessite pas de changement de port, peu importe ce que les développeurs utilisent ensuite.

Ce n'est pas une solution parfaite, car il est toujours plus agréable d'assigner automatiquement plutôt que de définir des ports durs dans les projets. Buts c'est une bonne option à essayer.