Même si je ne vois pas souvent de posts concernant ActionScript dans ce
newsgroup, je tente ma chance néanmoins ...
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez
moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048:
Violation de la sécurité Sandbox :
http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut
pas charger de données à partir de world3d.virgal.org:6667.
Il s'agit d'un chat IRC se connectant à un serveur IRC sur son hôte
d'origine. Le message d'erreur me parait contradictoire : Flash avoue
lui même que l'hôte d'origine et l'hôte auquel on tente de se connecter
sont identiques (world3d.virgal.org), et pourtant il déclenche quand
même une SecurityErrorEvent ...
Il a le plugin Flash v9,0,115,0
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Laurent vilday
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048: Violation de la sécurité Sandbox : http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non plus :p
Dans le .fla : System.security.allowInsecureDomain("wold3d.virgal.org"); System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Et le fichier crossdomain.xml (à adapter évidemment) à la racine : <?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
-- laurent
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez
moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048:
Violation de la sécurité Sandbox :
http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut
pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué
suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non
plus :p
Dans le .fla :
System.security.allowInsecureDomain("wold3d.virgal.org");
System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Et le fichier crossdomain.xml (à adapter évidemment) à la racine :
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048: Violation de la sécurité Sandbox : http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non plus :p
Dans le .fla : System.security.allowInsecureDomain("wold3d.virgal.org"); System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Et le fichier crossdomain.xml (à adapter évidemment) à la racine : <?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
-- laurent
davel_x
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048: Violation de la sécurité Sandbox : http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non plus :p J'ai la même impression et sur cet article que je viens de trouver :
http://blog.je2050.de/2005/10/26/how-to-use-sockets-in-actionscript3/ où l'application est similaire à celle de O.L., il y a bien un mention à la classe "system.security" (même si dans son cas il utilise visiblement un proxy pour palier les changements de serveur, de port, etc.)
Dans le .fla : System.security.allowInsecureDomain("wold3d.virgal.org"); System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Je crois qu'il vaut mieux utiliser du allowDomain plus que du
allowInsecureDomain et spécifier le port utilisé pour la connexion justement. Non ?
-- **davel** http://www.davel.fr/blog/
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui,
chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error
#2048: Violation de la sécurité Sandbox :
http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne
peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué
suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien
non plus :p
J'ai la même impression et sur cet article que je viens de trouver :
http://blog.je2050.de/2005/10/26/how-to-use-sockets-in-actionscript3/
où l'application est similaire à celle de O.L., il y a bien un mention
à la classe "system.security" (même si dans son cas il utilise
visiblement un proxy pour palier les changements de serveur, de port, etc.)
Dans le .fla :
System.security.allowInsecureDomain("wold3d.virgal.org");
System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Je crois qu'il vaut mieux utiliser du allowDomain plus que du
allowInsecureDomain et spécifier le port utilisé pour la connexion
justement.
Non ?
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048: Violation de la sécurité Sandbox : http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non plus :p J'ai la même impression et sur cet article que je viens de trouver :
http://blog.je2050.de/2005/10/26/how-to-use-sockets-in-actionscript3/ où l'application est similaire à celle de O.L., il y a bien un mention à la classe "system.security" (même si dans son cas il utilise visiblement un proxy pour palier les changements de serveur, de port, etc.)
Dans le .fla : System.security.allowInsecureDomain("wold3d.virgal.org"); System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Je crois qu'il vaut mieux utiliser du allowDomain plus que du
allowInsecureDomain et spécifier le port utilisé pour la connexion justement. Non ?
-- **davel** http://www.davel.fr/blog/
O.L.
Laurent vilday wrote:
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048: Violation de la sécurité Sandbox : http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non plus :p
Dans le .fla : System.security.allowInsecureDomain("wold3d.virgal.org"); System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Et le fichier crossdomain.xml (à adapter évidemment) à la racine : <?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
Salut,
Je crois que tu as raison, c'est bien un problème venant d'Adobe. Visiblement à partir de Flash v9.0.115 une anim Flash n'a plus le droit de se connecter à son hôte d'origine ... il faut mettre en place un "socket policy file", mais leur doc est pas très explicite là dessus.
Perso j'avais déjà essayé de mettre un crossdomain.xml à la racine de mon site (http://world3d.virgal.org/crossdomain.xml), mais en fait comme c'est une connexion par socket le fameux crossdomain.xml ne doit pas être servi par HTTP, mais sur une socket (port 843 choisi arbitrairement par Adobe) ! Infos trouvées sur : http://ammonlauritzen.com/blog/category/security/ Je suis en train de tester sa solution avec un mini serveur qui écoute sur le port 843 et envoie le xml, visiblement ça a de l'effet puisque j'ai des connexions qui arrivent dessus sans avoir rien changé à mon .fla, je vous tiens au courant ;)
Merci et @+
Laurent vilday wrote:
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui,
chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048:
Violation de la sécurité Sandbox :
http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne
peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué
suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non
plus :p
Dans le .fla :
System.security.allowInsecureDomain("wold3d.virgal.org");
System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Et le fichier crossdomain.xml (à adapter évidemment) à la racine :
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Salut,
Je crois que tu as raison, c'est bien un problème venant d'Adobe.
Visiblement à partir de Flash v9.0.115 une anim Flash n'a plus le droit
de se connecter à son hôte d'origine ... il faut mettre en place un
"socket policy file", mais leur doc est pas très explicite là dessus.
Perso j'avais déjà essayé de mettre un crossdomain.xml à la racine de
mon site (http://world3d.virgal.org/crossdomain.xml), mais en fait comme
c'est une connexion par socket le fameux crossdomain.xml ne doit pas
être servi par HTTP, mais sur une socket (port 843 choisi arbitrairement
par Adobe) !
Infos trouvées sur : http://ammonlauritzen.com/blog/category/security/
Je suis en train de tester sa solution avec un mini serveur qui écoute
sur le port 843 et envoie le xml, visiblement ça a de l'effet puisque
j'ai des connexions qui arrivent dessus sans avoir rien changé à mon
.fla, je vous tiens au courant ;)
Un ami rencontre cette erreur sur un SWF que j'ai développé et qui, chez moi, fonctionne parfaitement :
Error #2044: SecurityErrorEvent non pris en charge : text=Error #2048: Violation de la sécurité Sandbox : http://world3d.virgal.org/flash/fcr_1204113110/flashchatirc.swf ne peut pas charger de données à partir de world3d.virgal.org:6667.
Euh, c'est pas l'histoire du "cross-domain-policy" qui serait appliqué suite au changement de port (80 -> 6667) ? Je dis ça, j'en sais rien non plus :p
Dans le .fla : System.security.allowInsecureDomain("wold3d.virgal.org"); System.security.loadPolicyFile("http://wold3d.virgal.org/crossdomain.xml");
Et le fichier crossdomain.xml (à adapter évidemment) à la racine : <?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
Salut,
Je crois que tu as raison, c'est bien un problème venant d'Adobe. Visiblement à partir de Flash v9.0.115 une anim Flash n'a plus le droit de se connecter à son hôte d'origine ... il faut mettre en place un "socket policy file", mais leur doc est pas très explicite là dessus.
Perso j'avais déjà essayé de mettre un crossdomain.xml à la racine de mon site (http://world3d.virgal.org/crossdomain.xml), mais en fait comme c'est une connexion par socket le fameux crossdomain.xml ne doit pas être servi par HTTP, mais sur une socket (port 843 choisi arbitrairement par Adobe) ! Infos trouvées sur : http://ammonlauritzen.com/blog/category/security/ Je suis en train de tester sa solution avec un mini serveur qui écoute sur le port 843 et envoie le xml, visiblement ça a de l'effet puisque j'ai des connexions qui arrivent dessus sans avoir rien changé à mon .fla, je vous tiens au courant ;)
Merci et @+
thomasdecaux
Ouai t'as tout compris, depuis la version 9.0.123.0, Adobe a changé sa politique de sécurité sur les Sockets, du coup, tu ne peux pas te connecter à ton propre host! En fait Adobe a été autorisé à utilis er le port 843 (qui à présent dédié à cet usage) pour envoyer le fich ier XML. Du coup, il te faut sur ton server un petit daemon qui tourne sur le port 843 et qui balance des cross-domain, apparement tu peux aussi utiliser le port de connection, en fait Flash tente d'abord sur 843 puis sur le port de ton socket, ensuite il ferme la connection puis la rouvre si il a le droit! Bref hyper hyper loud! Vive Flash 1 lol ;-)
Ouai t'as tout compris, depuis la version 9.0.123.0, Adobe a changé sa
politique de sécurité sur les Sockets, du coup, tu ne peux pas te
connecter à ton propre host! En fait Adobe a été autorisé à utilis er
le port 843 (qui à présent dédié à cet usage) pour envoyer le fich ier
XML. Du coup, il te faut sur ton server un petit daemon qui tourne sur
le port 843 et qui balance des cross-domain, apparement tu peux aussi
utiliser le port de connection, en fait Flash tente d'abord sur 843
puis sur le port de ton socket, ensuite il ferme la connection puis la
rouvre si il a le droit! Bref hyper hyper loud! Vive Flash 1 lol ;-)
Ouai t'as tout compris, depuis la version 9.0.123.0, Adobe a changé sa politique de sécurité sur les Sockets, du coup, tu ne peux pas te connecter à ton propre host! En fait Adobe a été autorisé à utilis er le port 843 (qui à présent dédié à cet usage) pour envoyer le fich ier XML. Du coup, il te faut sur ton server un petit daemon qui tourne sur le port 843 et qui balance des cross-domain, apparement tu peux aussi utiliser le port de connection, en fait Flash tente d'abord sur 843 puis sur le port de ton socket, ensuite il ferme la connection puis la rouvre si il a le droit! Bref hyper hyper loud! Vive Flash 1 lol ;-)
Olivier Miakinen
Bonjour,
Ouai t'as tout compris, [...]
Le dernier article de ce fil étant vieux de plus d'un mois, j'espère que la personne a qui tu réponds (mais que tu ne cites pas) avait effectivement compris...
Bonjour,
Ouai t'as tout compris, [...]
Le dernier article de ce fil étant vieux de plus d'un mois, j'espère
que la personne a qui tu réponds (mais que tu ne cites pas) avait
effectivement compris...
Le dernier article de ce fil étant vieux de plus d'un mois, j'espère que la personne a qui tu réponds (mais que tu ne cites pas) avait effectivement compris...
