Pourquoi est Flash exigeant une crossdomain.xml fichier lors de l' .swf et http cible sont tous les deux sur localhost?
J'ai un petit client/serveur application de test où j'ai un Flex application qui fait une requête HTTP à un serveur d'application. Le serveur d'application est un script qui s'exécute sur ma machine locale, à l'écoute sur le port 8001. Le client est un swf que je suis en cours d'exécution en local, et utilise mx.rpc.http.HTTPService pour faire la demande de page.
La HTTPService est configuré comme ci-dessous:
_HttpService = new HTTPService();
_HttpService.url = "http://localhost:8001";
_HttpService.contentType = "text/xml";Quand je faire une demande de page, le serveur d'application est d'abord recevoir un "GET /crossdomain.xml HTTP/1.1" demande, qui est un échec car je n'ai pas de crossdomain.xml fichier en place. La raison pour laquelle je n'en ai pas en place c'est parce que ce est tout se passe sur ma machine locale (pour l'instant) et je ne devrais pas besoin (je ne pense pas).
J'ai vraiment eu ce code de travail avant sans crossdomain.xml quand j'étais à l'aide de Flex 3.x. J'ai pensé que je l'ai eu à travailler avec Flex 4. Maintenant, je suis à l'aide de Flex 4.5. Est-il question ici, peut-être due à des modifications de stratégie de sécurité?
Avec tous ce qui se passe sur localhost, pourquoi le Flash player demandant un crossdomain.xml fichier?
Au cas où il permet, à la faute de mes AsyncResponder est le retour est:
[FaultEvent fault=[RPC Fault faultString="Security error accessing url" faultCode="Channel.Security.Error" faultDetail="Destination: DefaultHTTP"] messageId="F43DCBFF-E99A-99CC-57D8-535C13C7CD48" type="fault" bubbles=false cancelable=true eventPhase=2]OriginalL'auteur Russ | 2011-06-03
Vous devez vous connecter pour publier un commentaire.
Il peut être bien que vous avez le même hôte et le protocole entre la page du client et du serveur, le port différent causes Flash à l'échec de la même origine test et la demande de la crossdomain.xml pour voir ce qu'il est autorisé à le faire. Je suis en supposant que la page de l'hébergement de votre contenu Flash est en cours d'exécution sur le port 80? Si c'est le cas, consultez l'article de Wikipedia sur la même origine (http://en.wikipedia.org/wiki/Same_origin_policy) pour les détails.
L'crossdomain.xml ne semble pas être trop lourd pour les tests locaux et est assez bien documentée sur help.adobe.com. Vous pouvez créer un crossdomain.xml dans la racine de votre site comme celui-ci, qui permettra à tous les accès:
Je ne voudrais pas utiliser ce qui précède pour autre chose que le développement local comme vous êtes essentiellement en permettant à n'importe quel domaine à la demande de contenu.
Espérons que cette aide!
Rouler votre propre serveur xmlrpc semble amusant, même si vous avez de soutien supplémentaire nuances Flash jette à vous... comme le OBTENIR pour crossdomain.xml. Je ne suis pas sûr de votre mise en œuvre, mais il pourrait être la peine de regarder en misant sur un site web existant de la pile, puis la construction d'un service web simple au lieu d'utiliser xmlrpc. Si vous êtes à l'aide de C#/MS pile, découvrez WCF REST avec de simples données xml - voir: lien
+1. le crdm est droit. Le domaine et port doit être le même pour ignorer crossdomain politiques. Si le port est différent que les serveurs web, puis il va chercher crossdomain.xml. Le plus simple pour obtenir ce travail si votre serveur dans un conteneur de l'application (comme glassfish ou si vous utilisez tomcat Java/.Net) ou utiliser n'importe quel serveur web pour servir de langage de script côté serveur (php, asp, etc). Beaucoup plus facile à tous de l'avoir fait avec un seul serveur.
Je ne suis pas sûr de ce qu'il faut faire, mais quand je l'ai mis à utiliser une version autonome de flash player versus le chargement du flash via le code html dans un navigateur, le crossdomain problème disparaît complètement. c'est à dire: il fonctionne très bien maintenant (et maintenant que cela s'est passé, je pense que c'est la façon dont je l'ai couru avec succès dans le passé). Je ne sais pas si cela correspond aux ports-doit-match de la théorie... n'est ce pas?
À l'aide de Flash player (fp) évite le crossdomain question que la pf n'a pas hébergé contexte. Lorsque le Flash est hébergé sur une page web, la demande va quelque chose comme: [Utilisateur] -> [Page web (localhost:someport)] -> [Service Web (localhost:someotherport)] et échoue de la même origine que le test entre la Page web et des Services Web. Lors de l'utilisation de la pf vous n'avez [w/Flash player (pas hébergé contexte)] -> [Service Web] Le service web est le seul hébergé contexte que la même origine est testé contre. Et, puisqu'il n'y a qu'un contexte, il ne vérifie pas si la croix de domaine de les problèmes. Espérons que cette aide!
OriginalL'auteur mrdc
À l'aide de la policyfile.txt j'ai compris que la politique de fichier a été refusé parce qu'il n'y a pas de Type de Contenu spécifié par le serveur. C'est ce qui explique pourquoi il a été impossible de trouver quelque chose blogué à ce sujet.
Espère que cela aide quelqu'un.
En Flex 4.5 Mac
/Utilisateurs/[YOUR_USER_NAME]/Bibliothèque/Préférences/Macromedia/Flash Player/Logs>tail-f policyfiles.txt
Bonne question, je pense que la réponse est oui. C'est un fichier local, autant que je me souvienne, c'est juste un journal de politique de l'activité des fichiers sur votre ordinateur local. Si vous l'effacer et il n'y a plus d'activité, il doit juste se régénérer? Voir help.adobe.com/en_US/flex/using/... pour plus d'informations sur la façon de le configurer.
J'ai posté une question similaire, après cela, et ils ont confirmé que c'était ok pour effacer ainsi. Merci!
np, content d'avoir pu aider.
OriginalL'auteur Shanimal