Salut
La valeur par défaut du Lecteur Flash est de rechercher avant toute chose un fichier de régulation : crossdomain.xml
Le fichier est ainsi - le signe « * » veut dire permission à tous les domaines.
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>
Si tu cible un domaine en particulier »
<cross-domain-policy>
<allow-access-from domain="www.fileden.com"/>
</cross-domain-policy>
La sécurité concerne surtout la possibilité d'avoir accès à toutes les propriétés et méthodes de la classe, donc de pouvoir communiquer et modifier l'objet charger.
Dans ton cas tu n'auras pas à communiquer ou modifier la cible mp3. Tu ne le pourrais pas de toute façon car tu n'as pas le fichier .fla, par le fait même tu ne peut scripter en AS. Mais tu pourras quand même essayé de placer ce fichier de régulation au même niveau que ton mp3 sur le lecteur D:
Essais le tout simplement si ça marche tant mieux. Mais ça me surprendrait il est mieux d'utilisé les ~http:// Autrement dit de localhost à un serveur distant genre fileden.com.
Dans le cas d'une image charger sur un autre domaine par exemple nous ne pouvons pas changer la dimension de l'image sauf si nous utilisons un objet : contentLoaderInfo. Ainsi nous pouvons modifier l'image voire même charger toutes les informations sur l'image : sa dimension, son url, sa taille etc. La classe LoaderInfo est aussi utile. Quoiqu'il en soit c'est surtout pour les développeurs que ces objets sont définis. Non pas pour l'utilisateur.
De même avec un objet audio avec SoundLoaderContext. Considérons ici que les exemples sont de AS3 et non pas AS2. Mais les principes de bases sont les mêmes.
Ce qu'il faut retenir c'est la valeur par défaut du Lecteur Flash. Celui-ci recherche toujours un fichier de régulation « crossdomain.xml » dès que le sandbox de sécurité est différent entre l'objet chargeur et l'objet charger.
Voici une petite liste de fichier de regulation utilisés par des grands noms »
http://www.facebook.com/crossdomain.xml
http://www.adobe.com/crossdomain.xml
http://www.youtube.com/crossdomain.xml
http://static.flickr.com/crossdomain.xml
Tu as un pack gratuit ici sur
fileden.com : (USA) où tu pourras cibler tes fichiers mp3.
Tu upload tes fichiers, et tu prend les url's. Tu n'auras pas besoin de fichier de régulation quoique d'en avoir un ne fait pas de tort.
Essais un test avec ce fichier si tu veut »
-http://www.fileden.com/files/2009/8/24/2553584/PGpiste_02.mp3 : PG veut dire Philip Glass
++
PS : Quand nous parlons de sécurité en Flash nous ne parlons pas de vol ou de piratage. Nous parlons tout simplement d'une relation de confiance, qui permet ou non d'interroger l'objet et de le modifier. Il est faux de croire que nous ne pouvons pas visualiser une image ou écouter un son mp3 sans fichier xml de régulation. Le relation de confiance entre un domaine à un autre ne concerne que le développement en Flash. Dont le but est de modifier l'objet charger. Alors là seulement un fichier de régulation est nécessaire. Sauf évidemment quelques exceptions.
Dans l'exemple suivant »
<cross-domain-policy>
<allow-access-from domain="*.youtube.com"/>
<allow-access-from domain="*.google.com"/>
</cross-domain-policy>
Nous indiquons que seuls les fichiers SWF hébergés dans des sous-domaines de youtube.com ou google.com peuvent scripter les images hébergées sur youtube.com. Nous pouvons donc tout modifier sur l'image, car nous avons accès à toutes les propriétés et méthodes de classe, et de plusieurs classes. Si et seulement si, le SWF est hébergé dans les sous-domaines de youtube.
Flickr est beaucoup plus permissif »
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>
Tous les domaines peuvent interroger et modifier (scripter) les images hébergés sur flickr.com
Cependant une autre instruction existe dans le réel fichier de régulation de Flickr »
. . .
<site-control permitted-cross-domain-policies="master-only" />
. . .
C'est quand même grâce à cette relation de confiance et de certaines propriétés et méthodes de classes prédéfinies que certains développeurs font des
Widgetbox via flickr où des interrogations et des modifications, ajout de fonctionnalités, deviennent possibles. Dans l'exemple du lien sur widgetbox, les images ont pu être miniaturisées pour en faire une navigation de type showcase. Si donc nous parlons de sécurité, c'est sur la possibilité de pouvoir modifier, ou pas, un objet Flash charger depuis l'externe et placer sur un sandbox de sécurité différent. Voilà.
Certains propos proviennent du livre (PDF Gratuit) pratique d'actionscript 3 de
Thibault Imbert
Ingénieur Système chez Adobe France. 1100 pages en fr.
. . .
Modifié par zardoz (29 Dec 2010 - 01:31)