Voici une liste exhaustive des méthodes concernées : - loadVariables, loadVariablesNum, MovieClip.loadVariables, LoadVars.load, LoadVars.sendAndLoad - XML.load, XML.sendAndLoad - XMLSocket.connect - Symboles importés d’une librairie partagée - Flash Remoting (NetServices.createGatewayConnection)
Dans ce billet, je vais aborder l’obstacle du chargement interdomaine et la manière officielle d’outrepasser cette limitation. Cette limitation entre en vigueur dès que vous ciblez avec une url absolue (mème sur votre propre serveur)
Pour la version non-officielle allez voir mon autre sujet: Charger un fichier distant avec php et sans Crossdomain.xml
Au programme
Preface
Flash et la securité
Pour certaines raisons, flash ne permet pas l’execution et le chargement de certains fichiers provenant d’un domaine different de celui qui l’appel. Certains d’entre vous ce sont surement déjà retrouver “coincés” en voulant charger un flux rss distant dans un swf. C’est parfois assez frustrant ! Car on peut tout à fait charger une image distante, mais rien d’autre .... pourtant selon moi charger un xml distant ne presente pas vraiment plus de risque que charger une image ...
Solution du fichier "crossdomain.xml"
Flash a penser à nous ! En permettant de creer des règles d’autorisation interdomaine.
En theorie celà signifie, que via un fichier de règle (”crossdomain.xml“) placé sur un domaine distant, on peut autoriser ou pas l’accès aux fichiers de ce domaine depuis le domaine où votre swf est hebergé ...
En pratique celà implique que vous devez posseder les “clés” du domaine distant pour pouvoir y deposer votre fichier “crossdomain.xml” !
Solution via l'intermediaire d'un script php
Je decris cette methode dans ce tuto. Elle permet de loader des fichiers provenant d’un serveur pour lequel nous n’avons pas les “clés”.
On evitera cette methode autant que possible, car elle demande des ressources niveau serveur, de plus elle atteind vite ces limites.
Le fichier crossdomain.xml
Ce fichier s’installe donc à la racine du serveur sur lequel se trouve les fichiers à charger.
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="domaine_a_autoriser" /> </cross-domain-policy>
Remplacer "domaine_a_autoriser" par le nom de domaine où se situe le swf.
Exemples
Cas 1 : Je veux autoriser tous les domaines à acceder à mes fichiers situé sur mon serveur.
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
Cas 2 : Je veux autoriser tous les domaines en .fr et .be à acceder à mes fichiers situé sur mon serveur.
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*.fr" /> <allow-access-from domain="*.be" /> </cross-domain-policy>
Cas 3 : Je veux autoriser tous les sous-domaines de google.fr à acceder à mes fichiers situé sur mon serveur.
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*.google.fr" /> </cross-domain-policy>
Donc vous avez saisi le principe, le * sert de joker. Vous pouvez cumuler autant de permissions que necessaire.







![[netvibes]](images/digglike/netvibes.gif)
![[technorati]](images/digglike/technorati.png)
![[blogmarks]](images/digglike/blogmarks.gif)
![[delicious]](images/digglike/delicious.gif)
![[digg]](images/digglike/digg.gif)
![[furl]](images/digglike/furl.gif)
![[google]](images/digglike/google.png)
![[newsburst]](images/digglike/newsburst.gif)
![[bloglines]](images/digglike/bloglines.gif)
![[yahoo]](images/digglike/yahoo.gif)
![[newsgator]](images/digglike/newsgator.gif)
![[aol]](images/digglike/aol.gif)
![[windows]](images/digglike/windows.gif)
![[msn]](images/digglike/msn.gif)
![[feedfeeds]](images/digglike/addfeedfeeds.gif)
![[pageflakes]](images/digglike/pageflakes.gif)
![[kinja]](images/digglike/addkinja.gif)
![[blogarithm]](images/digglike/blogarithm.gif)
![[rojo]](images/digglike/rojo.gif)
![[feedshow]](images/digglike/feedshow.gif)
Commentaires
Charger un flux XML n'est pas plus risqué que charger une image ...
Par contre, c'est bien plus couteux niveau ressources serveur !
Sinon, très bon tutos
je suis surpris qu'l n'y ait pas plus de commentaires à bvotre billet !
je suis étonné qu'il nr'y ait pas plus de commentaires à vote billet
charger un fichier xml est imensement plus dangereux niveau securité.
Imaginez qu'un utilisateur qui est sur un reseau d'entreprise, à l'interieur duquel est hébergé une intranet contenant des données confidentielles se connecte (pendant sa pause midi) sur un site contenant des jeux en flash.
L'intranet n'est pas accessible depuis le net, car derriere un routeur NAT.
Si on laisse Flash charger des fichiers librement (sans crossdomain.xml), il suffit au programmeur du jeu (mal intentionné) de d'aspirer le site depuis son application Flash, puis de renvoyer le tout à un serveur sur le net en fesant des requetes POST.
Un employé qui jouait simplement a un jeu Flash, se retrouverait donc a uploader à son insu les contenus de l'intranet de son entreprise.
Les meme regles de securité s'appliquent pour les sockets depuis flash:
il serait sinon possible de coder en as3 un driver cifs et d'acceder à tous les shares windows d'une entreprise (voir plus simplement, si on vise le particulier du localhost).
=> pas glop
Ben voilà c'est pile ce qu'il me fallait. Ca va bien m'arranger, merci pour l'article !
Merci pour ces bonnes explications!
:-)
Ajouter un commentaire