Silverlight: Comment ignorer (l'absence de) crossdomain.xml avec System.Net.WebClient?
-
10-07-2019 - |
Question
Je reçois une exception de sécurité lors de l'utilisation de System.Net.WebClient
pour effectuer des requêtes HTTP, ce qui est dû au fait que crossdomain.xml
ou clientaccesspolicy.xml
sur le serveur cible sont manquants ou trop restrictifs. Je sais qu’il ya une bonne raison à cela (cookies et falsification de requêtes intersites), mais cela ne s’applique pas à mon cas, car j’ai seulement besoin de faire des requêtes HTTP GET simples vers des URL arbitraires sans utiliser de cookies ou de choses fantaisistes .
Je pensais déjà à l'idée d'un proxy qui récupérerait les URL, mais qui ressemble davantage à une solution de contournement moche, sans parler du gaspillage de bande passante.
Quel est le moyen (s’il en existe un) de le faire dans Silverlight? Est-ce que j'utilise la bonne classe?
La solution
Je pense que ce n’est vraiment pas possible, du moins avec WebClient. L’idée est de restreindre (protéger ...) les clients des requêtes non désirées à d’autres serveurs.
Pour contourner ce problème, vous pouvez utiliser un service Web proxy qui appellera les "URL arbitraires". à partir de votre serveur Web et transmettez les résultats au client Silverlight. Ainsi, les clients resteront protégés pendant que vous réaliserez la fonctionnalité souhaitée.
Autres conseils
Pourquoi voulez-vous vous en débarrasser?
Si vous profilez des demandes Silverlight ... dans un scénario interdomaine, elles appellent toujours le fichier clientaccesspolicy.xml. Vous ne pouvez pas modifier ce comportement (interne au runtime Silverlight). De plus, s'il ne trouve pas le fichier clientaccessolicy.xml, il appelle l'équivelant Flash / Flex (crossdomain.xml). Si les deux n'existent pas ou ne permettent pas les demandes de ce domaine, vos demandes échoueront simplement.
J'ai écrit un article sur l'utilisation de HttpHandlers afin de ne pas avoir à placer ces fichiers XML sur votre serveur Web local et vous pouvez les rendre dynamiques. L'article se trouve ici: