Le modèle de sécurité utilisé par les moteurs d’exécution de Flash Player et d’AIR est en grande partie basé sur le domaine d’origine des fichiers SWF, des contenus HTML, des éléments multimédias et autres actifs chargés. Le code exécutable d’un fichier issu d’un domaine Internet particulier, tel www.exemple.com, peut systématiquement accéder à l’ensemble des données de ce domaine. Ces actifs sont placés dans le même groupe de sécurité, appelé
sandbox de sécurité
(pour plus d’informations, voir
Sandbox de sécurité
).
Par exemple, le code ActionScript d’un fichier SWF peut charger des fichiers SWF, bitmap, audio, texte et tout autre actif appartenant au même domaine. En outre, l’intercodage entre deux fichiers SWF d’un même domaine est systématiquement autorisé, sous réserve qu’ils soient tous deux écrits en ActionScript 3.0. L’
intercodage
est la capacité du code d’un fichier à accéder aux propriétés, méthodes et objets définis par le code d’un autre fichier.
Elle n’est pas prise en charge si les fichiers sont écrits en ActionScript 3.0 pour certains et dans des versions antérieures d’ActionScript pour d’autres. La communication entre ces fichiers sera toutefois possible grâce à la classe LocalConnection. Par ailleurs, un fichier SWF ne peut pas, par défaut, accéder par programmation croisée à des fichiers SWF écrits en ActionScript 3.0 appartenant à d’autres domaines ni charger des données à partir d’autres domaines. Ce type d’accès est néanmoins autorisé par le biais d’un appel à la méthode
Security.allowDomain()
dans le fichier SWF chargé. Pour plus de détails sur la programmation croisée, voir
Programmation croisée
.
Les règles de sécurité élémentaires présentées ci-après s’appliquent toujours par défaut :
Les moteurs d’exécution de Flash Player et d’AIR considèrent les éléments suivants comme des domaines distincts et configurent un sandbox de sécurité pour chacun d’eux :
-
http://example.com
-
http://www.example.com
-
http://store.example.com
-
https://www.example.com
-
http://192.0.34.166
Même si un domaine nommé, tel http://example.com, est associé à une adresse IP particulière, telle http://192.0.34.166, les moteurs d’exécution définissent un sandbox distinct pour chacun d’eux.
Le développeur dispose de deux méthodes de base pour permettre à un fichier SWF d’accéder à des actifs issus de sandbox différents du sien.
Les modèles de sécurité utilisés par les moteurs d’exécution de Flash Player et d’AIR établissent une distinction entre le chargement de contenu et l’accès à des données ou leur extraction. On entend par
contenu
des fichiers multimédias, notamment les éléments visuels que les moteurs d’exécution peuvent afficher, des fichiers audio et vidéo ou un fichier SWF ou HTML contenant des éléments multimédias affichés. Les
données
sont des éléments auxquels seul le code peut accéder. Le contenu et les données ne sont pas chargés de la même façon.
-
Chargement de contenu : vous pouvez charger un contenu par le biais de classes telles que Loader, Sound et NetStream, à l’aide de balises MXML si vous utilisez Flex ou à l’aide de balises HTML dans une application AIR.
-
Extraction de données : vous pouvez extraire des données de contenus multimédias chargés à l’aide d’objets Bitmap, des méthodes
BitmapData.draw()
et
BitmapData.drawWithQuality()
, de la propriété
Sound.id3
ou de la méthode
SoundMixer.computeSpectrum()
La méthode
drawWithQuality
est disponible dans Flash Player 11.3 et les versions ultérieures et dans AIR 3.3 et les versions ultérieures.
-
Accès aux données : vous pouvez accéder directement aux données en les chargeant à partir d’un fichier externe (un fichier XML, par exemple) par le biais de classes telles que URLStream, URLLoader, FileReference, Socket et XMLSocket. AIR propose d’autres classes de chargement de données, telles que FileStream et XMLHttpRequest.
Le modèle de sécurité Flash Player définit différentes règles concernant le chargement de contenu et l’accès aux données. En général, les restrictions sont moindres sur le chargement de contenu que sur l’accès aux données.
En règle générale, le contenu (fichiers SWF, bitmap, mp3 et vidéo) peut être chargé de n’importe quelle source, mais s’il provient d’un domaine autre que celui du code ou du contenu à l’origine du chargement, il est placé dans un sandbox de sécurité distinct.
Certains obstacles s’appliquent au chargement de contenu :
-
Par défaut, les fichiers SWF locaux (ceux chargés à partir d’une adresse ne se trouvant pas sur un réseau, par exemple le disque dur de l’utilisateur) sont classés dans le sandbox local avec système de fichiers. Ces fichiers ne peuvent pas charger de contenu provenant d’un réseau. Pour plus d’informations, voir
Sandbox locaux
.
-
Les serveurs RTMP (Real-Time Messaging Protocol) peuvent limiter l’accès au contenu. Pour plus d’informations, voir
Contenu diffusé à l’aide de serveurs RTMP
.
Si le média chargé est une image, un fichier audio ou une vidéo, ses données (par exemple données de pixels ou sons) sont accessibles pour un fichier SWF situé en dehors de son sandbox de sécurité, à condition que le domaine de ce fichier SWF ait été inclus dans un fichier de régulation d’URL dans le domaine d’origine du média. Pour plus d’informations, voir
Accès aux médias chargés comme s’il s’agissait de données
.
Les données chargées peuvent également provenir de fichiers texte ou XML chargés avec l’objet URLLoader. Là encore, l’accès à des données situées dans un autre sandbox de sécurité nécessite l’attribution des autorisations suffisantes par le biais d’un fichier de régulation d’URL placé dans le domaine d’origine. Pour plus d’informations, voir
Utilisation de URLLoader et URLStream
.
Remarque :
il n’est jamais nécessaire de faire appel à des fichiers de régulation pour permettre au code qui s’exécute dans le sandbox de l’application AIR de charger du contenu ou des données distants.
