Détermine la façon dont Flash Player sélectionne le domaine à utiliser pour certains paramètres de Flash Player, ce qui couvre les autorisations relatives à la caméra et au microphone, les quotas de stockage et le stockage d'objets persistants partagés. Vous pouvez définir exactSettings sur false pour que le fichier SWF reprenne les paramètres de Flash Player 6.

Dans Flash Player 6, le domaine utilisé pour ces paramètres de lecteur était basé sur la partie finale du domaine du fichier SWF. Lorsque le domaine d'un fichier SWF inclut plus de deux segments, tels que www.exemple.com, le premier segment du domaine (« www ») est supprimé et la partie restante du domaine est utilisée : exemple.com. Ainsi, dans Flash Player 6, www.exemple.com et magasin.exemple.com ont en commun le domaine « example.com » pour ces paramètres. de même, www.exemple.co.fr et magasin.exemple.co.fr ont tous les deux recours au domaine exemple.co.fr pour ces paramètres. A compter de Flash Player 7, les paramètres du lecteur sont choisis par défaut en fonction d'un domaine exact de fichier SWF. Par exemple, le fichier SWF de www.exemple.com applique les paramètres du lecteur pour www.exemple.com, et le fichier SWF de magasin.exemple.com utiliserait des paramètres différents pour magasin.exemple.com.

Lorsque Security.exactSettings est défini sur true, Flash Player a recours à des domaines exacts pour les paramètres du lecteur. Lorsqu'il est défini sur false, Flash Player applique les paramètres de domaine de Flash Player 6. La valeur par défaut de exactSettings est false. Si vous modifiez la valeur par défaut de exactSettings, vous devez le faire avant que tout événement impliquant la sélection de paramètres du lecteur se produise, tel que l'utilisation d'une caméra ou d'un microphone, ou l'extraction d'un objet partagé persistant.

Si vous avez déjà publié un fichier SWF de version 6 et créé des objets persistants à partir de ce dernier, et si vous devez extraire ces objets partagés persistants à partir de ce fichier SWF après l'avoir porté vers la version 7 ou plus récente, ou à partir d'un autre fichier SWF de version 7 ou plus récente, vous devez définir Security.exactSettings sur false avant d'appeler SharedObject.getLocal().

Voir aussi

Indique le type de sandbox de sécurité dans lequel fonctionne le fichier SWF appelant.

Security.sandboxType a l'une des valeurs suivantes :

• remote (Security.REMOTE) : Ce fichier SWF provient d'une URL et fonctionne selon les règles basées sur le domaine du sandbox.
• localWithFile (Security.LOCAL_WITH_FILE) : Le fichier SWF est un fichier local qui n'a pas été approuvé par l'utilisateur, et n'a pas été publié avec la désignation de mise en réseau. Ce fichier SWF peut lire à partir de sources locales de données mais ne peut pas communiquer avec Internet.
• localWithNetwork (Security.LOCAL_WITH_NETWORK) : Le fichier SWF est un fichier local qui n'a pas été approuvé par l'utilisateur, et a été publié avec la désignation de mise en réseau. Le fichier SWF peut communiquer sur Internet mais ne peut pas lire les sources de données locales.
• localTrusted (Security.LOCAL_TRUSTED) : Ce fichier SWF est un fichier local qui a reçu la confiance de l'utilisateur en utilisant soit le gestionnaire de paramètres, soit un fichier de configuration FlashPlayerTrust. Ce fichier SWF peut aussi bien lire à partir de sources locales de données qu'il peut communiquer avec Internet.

Tout fichier SWF, quelle que soit sa version, peut utiliser cette propriété. Cette dernière est uniquement prise en charge à partir de Flash Player 8. Par conséquent, vous pouvez examiner cette propriété, par exemple, à l'aide d'un fichier SWF de version 7 lu par Flash Player 8. Cette prise en charge de toutes les versions signifie que si vous publiez une page pour une version de Flash antérieure à 8, vous ne pouvez pas déterminer à l'avance si cette propriété sera prise en charge lors de la lecture. Par conséquent, dans un fichier SWF de version 7 ou plus ancienne, cette propriété a la valeur undefined. Cette situation ne se produit que si la version du lecteur (indiquée par flash.system.Capabilities.version) est antérieure à 8. Dans ce cas, vous pouvez déterminer le type de sandbox selon que le fichier SWF est local ou non. S'il s'agit d'un fichier local, Flash Player classe le fichier SWF en tant que localTrusted. (Avant Flash Player 8, le contenu local était traité de cette façon.) S'il s'agit d'un fichier local, Flash Player classe le fichier SWF en tant que remote.

Pour plus d'informations, consultez les références suivantes :

• Le chapitre relatif à la sécurité du manuel Programmation d'ActionScript 3.0 et les derniers commentaires disponibles dans LiveDocs
• Le Livre blanc sur la sécurité de Flash Player 9

Voir aussi

Permet aux fichiers SWF et HTML figurant dans les domaines identifiés d'accéder aux objets et aux variables du fichier SWF qui contient l'appel à allowDomain().

Si deux fichiers SWF sont servis à partir du même domaine, par exemple, http://mysite.com/swfA.swf et http://mysite.com/swfB.swf, alors swfA.swf peut alors analyser et modifier les variables, les objets, les propriétés, les méthodes, etc. dans swfB.swf et swfB.swf peut faire la même chose pour swfA.swf. Ceci est appelé programmation entre plusieurs animations ou programmation croisée.

Si deux fichiers SWF sont servis à partir de domaines différents, par exemple, http://siteA.com/swfA.swf et http://siteB.com/siteB.swf, puis, par défaut, Flash Player n'autorise pas swfA.swf à créer un script pour swfB.swf, mais pas swfB.swf à créer un script pour swfA.swf. Un fichier SWF transmet des fichiers SWF provenant d'autres domaines en appelant Security.allowDomain(). Ceci s'appelle programmation de scripts interdomaines. En appelant Security.allowDomain("siteA.com"), siteB.swf autorise siteA.swf à créer un script le contrôlant.

Dans tout contexte interdomaines, il est important d'identifier clairement les parties impliquées. Dans le cadre de cette discussion, le côté procédant à la programmation croisée sera appelé partie procédant à l'accès (habituellement le fichier SWF procédant à l'accès), et l'autre côté sera appelé partie cible (généralement le fichier SWF cible). Lorsque siteA.swf crée un script contrôlant siteB.swf, siteA.swf est la partie qui procède à l'accès et siteB.swf la partie réceptrice.

Les autorisations interdomaines établies avec allowDomain() sont asymétriques. Dans l'exemple précédent, siteA.swf peut créer un script contrôlant siteB.swf, mais siteB.swf ne peut pas créer de script de contrôle de siteA.swf, car siteA.swf n'a pas appelé allowDomain() pour donner aux fichiers SWF de siteB.com l'autorisation de créer un script de contrôle. Vous pouvez définir des autorisations symétriques en faisant les deux fichiers SWF appeler allowDomain().

En dehors de la protection des fichiers SWF contre les scripts interdomaines provenant d'autres fichiers SWF, Flash Player protège également les fichiers SWF contre ce type de script provenant des fichiers HTML. La programmation HTML vers SWF peut se produire avec des fonctions anciennes du navigateur Flash telles que SetVariable ou en appelant des fonctions de rappel établies avec ExternalInterface.addCallback(). Lorsque la programmation HTML vers SWF franchit les domaines, le SWF cible doit également appeler allowDomain(), comme s'il avait été appelé par un fichier SWF, faute de quoi l'opération échouera.

La spécification de l'adresse IP en tant que paramètre pour allowDomain() n'autorise pas l'accès de toutes les parties provenant de l'adresse IP spécifiée. Par contre, elle autorise l'accès uniquement par une partie qui contient l'adresse IP spécifiée dans son URL, et non pas un nom de domaine qui renvoie à cette adresse IP.

Différences liées à la version

Les règles de sécurité interdomaines de Flash Player ont évolué de version en version. Le tableau suivant récapitule les différences.

Les versions qui contrôlent le comportement de Flash Player désignent les versions SWF (la version publiée d'un fichier SWF), non pas la version de Flash Player. Par exemple, lorsque Flash Player 8 lit un fichier SWF publié par la version 7, il applique un comportement compatible à la version 7. Cette pratique permet de garantir que les mises à jour du lecteur ne changent pas le comportement de Security.allowDomain() dans les fichiers SWF déployés.

La colonne Version du tableau précédent indique la version la plus récente des fichiers SWF lors des opérations de programmation croisée. Le comportement de Flash Player dépend de la version du fichier SWF procédant à l'accès ou du fichier SWF cible, en retenant la version supérieure.

Les paragraphes suivants fournissent de plus amples informations sur les modifications de sécurité de Flash Player impliquant Security.allowDomain().

Version 5. Il n'y a aucune restriction de programmation de scripts interdomaines.

Version 6. Des fonctions de sécurité contre la programmation interdomaines ont été introduites. Par défaut, Flash Player empêche la programmation interdomaines, tandis que Security.allowDomain() l'autorise. Pour déterminer si deux fichiers appartiennent au même domaine, Flash Player utilise le superdomaine de chaque fichier, qui correspond au nom d'hôte exact de l'URL du fichier, moins le premier segment, jusqu'à un minimum de deux segments. Par exemple, le superdomaine de www.mysite.com est mysite.com. Les fichiers SWF de www.mysite.com et store.mysite.com ne peuvent pas se contrôler mutuellement par script sans un appel à Security.allowDomain().

Version 7. Le filtrage de superdomaine est modifié pour obtenir la correspondance exacte des domaines. Deux fichiers ne peuvent se programmer que si les noms d'hôte figurant dans leurs URL sont identiques ; sinon vous devez effectuer un appel à Security.allowDomain(). Par défaut, les fichiers chargés à partir des URL qui ne sont pas de type HTTPS ne sont plus autorisés à programmer les fichiers chargés à partir des URL HTTPS, même si les fichiers sont chargés à partir d'un domaine rigoureusement identique. Cette restriction permet de protéger les fichiers HTTPS, car un fichier non HTTPS est susceptible d'être modifié sans téléchargement, et tout fichier non HTTPS modifié de façon illicite risque de corrompre un fichier HTTPS, qui serait normalement protégé contre ce type de modification. La méthode Security.allowInsecureDomain() a été introduite pour permettre aux fichiers SWF HTTPS en cours d'accès de désactiver de façon volontaire cette restriction. Néanmoins, l'utilisation de Security.allowInsecureDomain() est déconseillée.

Version 8. Il existe deux grands domaines de modification :

• L'appel de Security.allowDomain() autorise désormais uniquement les opérations de programmation croisée où le fichier SWF cible correspond au fichier SWF qui a appelé Security.allowDomain(). En d'autres termes, tout fichier SWF qui appelle désormais Security.allowDomain() n'autorise que l'accès à lui-même. Dans des versions précédentes, l'appel de Security.allowDomain() autorisait les opérations de programmation croisée lorsque le fichier SWF cible appartenait au même domaine que le fichier SWF qui a appelé Security.allowDomain(). L'appel de Security.allowDomain() ouvrait auparavant l'ensemble du domaine du fichier SWF ayant procédé à l'appel.
• Une prise en charge a été ajoutée pour les valeurs des caractères génériques avec Security.allowDomain("*") et Security.allowInsecureDomain("*"). La valeur caractère générique (*) autorise les opérations de programmation croisée quel que soit le fichier procédant à l'accès et quelle que soit l'origine de ce dernier. Le caractère générique sert alors d'autorisation globale. Des autorisations génériques sont requises pour activer certains types d'opérations respectant les règles de sécurité des fichiers locaux. De façon plus spécifique, pour qu'un fichier SWF local disposant d'autorisations d'accès réseau pour créer un script de contrôle de fichier SWF sur Internet, le fichier Internet SWF en cours d'accès doit appeler Security.allowDomain("*"), ce qui indique que l'origine du fichier SWF local est inconnue. (Si le fichier SWF Internet cible est chargé à partir d'une URL HTTPS, le fichier SWF Internet doit alors appeler Security.allowInsecureDomain("*").)

De façon exceptionnelle, la situation suivante peut se produire : Vous chargez un fichier SWF enfant à partir d'un domaine différent et souhaitez lui permettre de créer un script sur le fichier SWF parent, mais vous ne connaissez pas le domaine final du fichier SWF enfant. Cela peut se produire, par exemple, lorsque vous utilisez des redirections d'équilibrage de charge ou des serveurs tiers.

Dans ce cas, vous pouvez utiliser la propriété url de l'objet URLRequest que vous transmettez à Loader.load(). Par exemple, si vous chargez un fichier SWF dans un fichier SWF parent, vous pouvez accéder à la propriété contentLoaderInfo de l'objet Loader pour le fichier SWF parent :

Security.allowDomain(loader.contentLoaderInfo.url)

Vous devez attendre le début du chargement du fichier SWF enfant pour obtenir la valeur correcte de la propriété url. Pour détecter le début du chargement du fichier SWF, exploite l'événement progress.

La situation opposée peut également se produire ; en effet, vous pouvez créer un fichier SWF enfant sur lequel son fichier parent pourra créer un script, mais qui ignore le domaine de celui-ci. Dans ce cas, vous pouvez accéder à la propriété loaderInfo de l'objet d'affichage qui correspond à l'objet racine du fichier SWF. Dans le fichier SWF enfant, appelez Security.allowDomain( this.root.loaderInfo.loaderURL). Il n'est pas nécessaire d'attendre la fin du chargement du fichier SWF parent ; le parent sera déjà chargé lorsque celui de l'enfant commencera.

Si vous procédez à la publication de Flash Player 8 ou une version ultérieure, vous pouvez également traiter ces situations en appelant Security.allowDomain("*"). Cependant, il peut parfois s'agir d'un raccourci dangereux, dans la mesure où il autorise tout autre fichier SWF, quel que soit le domaine de ce dernier, à accéder au fichier SWF procédant à l'appel. Il est généralement plus sûr d'utiliser la propriété _url.

Pour plus d'informations, consultez les références suivantes :

• Le chapitre relatif à la sécurité du manuel Programmation d'ActionScript 3.0 et les derniers commentaires disponibles dans LiveDocs
• Le Livre blanc sur la sécurité de Flash Player 9

Paramètres

Voir aussi

Permet aux fichiers SWF et HTML appartenant aux domaines identifiés d'accéder aux objets et variables du fichier SWF effectuant l'appel, hébergé à l'aide du protocole HTTPS. Cette méthode n'est pas recommandée ; reportez-vous à « Considérations de sécurité », plus bas dans cette section.

Cette méthode fonctionne de la même façon que Security.allowDomain(), mais elle autorise en outre des opérations où la partie qui procède à l'accès est chargée avec un protocole non HTTPS et la partie cible est chargée avec le protocole HTTPS. A partir de la version 7 de Flash Player, les fichiers non HTTPS ne sont pas autorisés à programmer les fichiers HTTPS. La méthode allowInsecureDomain() lève cette restriction lorsque le fichier SWF HTTPS cible l'utilise.

Utilisez allowInsecureDomain() uniquement pour activer la programmation des fichiers non HTTPS vers les fichiers HTTPS. Utilisez cette méthode pour activer le script lorsque le fichier non HTTPS qui procède à l'accès et le fichier HTTPS qui est accédé sont servis à partir du même domaine. Par exemple, si un fichier SWF sur http://mysite.com doit contrôler par script un fichier SWF sur https://mysite.com. N'utilisez pas cette méthode pour activer les scripts de contrôle entre des fichiers non HTTPS, entre fichiers HTTPS ou de fichiers HTTPS vers des fichiers non HTTPS. Dans ces situations, recourez plutôt à allowDomain().

Considérations de sécurité : Flash Player offre la méthode allowInsecureDomain() pour plus de souplesse, même si l'appel de cette méthode n'est pas recommandé. La transmission d'un fichier avec le protocole HTTPS offre plusieurs protections pour vous et vos utilisateurs. Le fait d'appeler allowInsecureDomain affaiblit l'une de ces protections. Le scénario suivant illustre la façon dont la méthode allowInsecureDomain(), si elle n'est pas utilisée avec prudence, risque de compromettre la sécurité.

Tenez compte du fait que les informations suivantes constituent uniquement l'un des scénarios possibles et sont conçues pour vous aider à comprendre allowInsecureDomain() par l'intermédiaire d'un exemple réaliste de programmation croisée. Cet exemple ne couvre pas tous les problèmes relatifs à l'architecture de sécurité et doit être utilisé uniquement comme référence générale. Le Centre de développement de Flash Player contient des informations détaillées sur Flash Player et la sécurité. Pour plus d'informations, consultez http://www.adobe.com/devnet/security/.

Supposons que vous deviez créer un site de commerce électronique qui comprend deux composants : un catalogue, qui ne doit pas nécessairement être sécurisé, dans la mesure où il contient uniquement des informations publiques ; et un composant panier/règlements, qui doit être sécurisé pour protéger les informations financières et personnelles des utilisateurs. Supposons que vous deviez servir le catalogue à partir de http://mysite.com/catalog.swf et le panier à partir de https://mysite.com/cart.swf. Le cahier des charges de votre site exige qu'aucun tiers ne puisse voler les numéros de carte de crédit de votre utilisateur en profitant des faiblesses de votre architecture de sécurité.

Imaginons qu'un intermédiaire malveillant tente d'intervenir entre le serveur et vos utilisateurs pour s'emparer des numéros de carte de crédit que vos utilisateurs pénètrent dans votre application de panier. L'intermédiaire, peut être un FAI peu scrupuleux, par exemple, ou un administrateur malveillant travaillant dans la même entreprise que certains utilisateurs, ou de façon plus générale, toute personne ayant la possibilité d'afficher ou modifier les paquets réseau transmis sans protection sur Internet, entre vos utilisateurs et vos serveurs. Cette situation n'est pas rare.

Si cart.swf utilise HTTPS pour transmettre les informations bancaires aux serveurs, l'intermédiaire ne peut pas voler directement ces informations en détournant les paquets réseau, dans la mesure où la transmission HTTPS est chiffrée. Cependant, l'attaquant utilise une autre technique : modifier le contenu de l'un de vos fichiers SWF pendant sa remise à l'utilisateur, en remplaçant le fichier SWF par une version modifiée qui détourne les informations relatives à l'utilisateur vers un autre serveur.

Le protocole HTTPS, entre autres, empêche l'application de cette « modification », dans la mesure où non seulement les transmissions HTTPS sont chiffrées mais encore protégées contre les modifications. Si un intermédiaire tente de modifier un paquet, le récepteur détecte la modification et refuse le paquet. Ainsi, l'attaquant ne peut pas modifier cart.swf, dans la mesure où il est transmis par l'intermédiaire du protocole HTTPS.

Supposons maintenant que vous souhaitiez autoriser les boutons dans catalog.swf, servi par le protocole HTTP, pour ajouter des éléments au panier dans cart.swf, servi par le protocole HTTPS. Pour accomplir ceci, cart.swf appelle allowInsecureDomain(), ce qui autorise catalog.swf à créer un script de contrôle pour cart.swf. Cette action entraîne une conséquence non intentionnelle : un attaquant pourrait modifier catalog.swf lorsqu'il est téléchargé par l'utilisateur, car catalog.swf est transmis avec le protocole HTTP et n'offre aucune protection contre les modifications. Le fichier catalog.swf modifié par l'attaquant peut désormais programmer cart.swf, dans la mesure où cart.swf contient un appel à allowInsecureDomain(). Le fichier catalog.swf modifié peut utiliser ActionScript pour accéder aux variables de cart.swf et lire ainsi les informations sur les cartes bancaires et autres données sensibles. Le fichier catalog.swf peut ensuite envoyer ces données au serveur d'un attaquant.

Naturellement, cette implémentation n'est pas souhaitable, mais vous devez autoriser la programmation croisée entre les deux fichiers SWF de votre site. Voici deux façons de changer la conception de ce site virtuel d'e-commerce afin d'éviter allowInsecureDomain() :

• Servez tous les fichiers SWF de l'application avec le protocole HTTPS. Il s'agit de la solution la plus simple et la plus fiable. Dans le scénario décrit, vous pouvez servir les fichiers catalog.swf et cart.swf par l'intermédiaire du protocole HTTPS. Vous risquez de consommer un peu plus de bande passante et d'augmenter la charge du processeur du serveur en faisant basculer un fichier tel que catalog.swf du protocole HTTP au protocole HTTPS, ce qui se traduira par une légère augmentation du temps de chargement des applications au niveau de l'utilisateur. Vous devez faire des essais avec des serveurs réels pour déterminer la gravité de ces effets. De manière générale, elle reste cantonnée entre 10 et 20 %, et est parfois totalement absente. Vous pouvez généralement améliorer les résultats avec du matériel et des logiciels d'accélération HTTPS sur vos serveurs. L'un des principaux avantage de l'application du protocole HTTPS aux fichiers SWF qui doivent coopérer est que vous pouvez utiliser une URL HTTPS en tant qu'URL principale dans le navigateur de l'utilisateur sans générer d'avertissements de contenu mixtes à partir du navigateur. En outre, l'icône en forme de cadenas devient visible dans le navigateur, ce qui permet d'offrir aux utilisateurs un indicateur de sécurité reconnu.
• Utilisez la programmation HTTPS vers HTTP, et non pas HTTP vers HTTPS. Dans le scénario proposé, vous pouvez stocker le contenu du panier de l'utilisateur dans catalog.swf, puis utiliser cart.swf pour gérer le processus de règlement. Lors du règlement, cart.swf pourrait extraire le contenu du panier à partir des variables ActionScript de catalog.swf. La restriction concernant les scripts HTTP vers HTTPS est asymétrique, bien qu'un fichier catalog.swf livré par le protocole HTTP ne puisse pas être autorisé à contrôler par script un fichier cart.swf livré par HTTPS, le fichier cart.swf HTTPS peut créer un script de contrôle du fichier catalog.swf HTTP. Cette approche est plus délicate que l'approche intégralement HTTPS ; vous ne devez pas faire confiance aux fichiers SWF transmis avec le protocole HTTP, qui n'est pas protégé contre les modifications. Par exemple, lorsque cart.swf extrait la variable ActionScript qui décrit le contenu du panier, le code ActionScript de cart.swf ne peut pas être certain que la valeur de cette variable est au format attendu. Vous devez vous assurer que le panier ne contient pas de données non valides qui risquent d'entraîner une action imprévue de cart.swf. Vous devez également accepter le risque qu'un intermédiaire, en modifiant catalog.swf, fournisse des données valides mais inexactes à cart.swf, par exemple en plaçant des éléments dans le caddie de l'utilisateur. La procédure normale de règlement permet d'atténuer ce risque, sans toutefois l'écarter totalement, en affichant le contenu du caddie et le montant total pour approbation par l'utilisateur.

Les navigateurs Web appliquent la séparation des fichiers HTTPS et non HTTPS depuis de nombreuses années et le scénario ci-dessus illustre l'utilité de cette restriction. Flash Player permet de contourner cette restriction de sécurité lorsque c'est strictement nécessaire, mais analysez les conséquences avant d'y procéder.

Pour plus d'informations, consultez les références suivantes :

• Le chapitre relatif à la sécurité du manuel Programmation d'ActionScript 3.0 et les derniers commentaires disponibles dans LiveDocs
• Le Livre blanc sur la sécurité de Flash Player 9

Paramètres

Voir aussi

Charge un fichier de régulation interdomaines à partir d'un emplacement spécifié par le paramètre url. Les fichiers de régulation de Flash Player font office de mécanisme d'autorisation. Ils permettent de charger des données vers des animations Flash depuis un serveur autre que celui sur lequel elles se trouvent.

Par défaut, Flash Player recherche les fichiers de régulation dans un emplacement unique : /crossdomain.xml sur le serveur sur lequel porte la requête de chargement des données.

Avec Security.loadPolicyFile(), Flash Player peut charger les fichiers de régulation à partir d'emplacements aléatoires, comme il est indiqué dans l'exemple suivant :

  Security.loadPolicyFile("http://www.example.com/sub/dir/pf.xml");
  

De cette manière, Flash Player peut récupérer un fichier de régulation à l'URL spécifiée. Les permissions accordées par l'intermédiaire de ce fichier s'appliquent à l'ensemble du contenu, au même niveau ou à un niveau inférieur dans la hiérarchie virtuelle des répertoires du serveur. Par exemple, selon le code précédent, ces lignes ne renvoient pas d'exception :

 import flash.net.*;
  var request:URLRequest = new URLRequest("http://www.example.com/sub/dir/vars.txt");
  var loader:URLLoader = new URLLoader();
  loader.load(request);
  
  var loader2:URLLoader = new URLLoader();
  var request2:URLRequest = new URLRequest("http://www.example.com/sub/dir/deep/vars2.txt");
  loader2.load(request2);
  

Par contre, le code suivant renvoie une exception de sécurité :

 import flash.net.*;
  var request3:URLRequest = new URLRequest("http://www.example.com/elsewhere/vars3.txt");
  var loader3:URLLoader = new URLLoader();
  loader3.load(request3);
  

Vous pouvez utiliser loadPolicyFile() pour charger un nombre illimité de fichiers de régulation. Dans le cas d'une requête impliquant un fichier de régulation, Flash Player attend que le téléchargement des fichiers de régulation soit terminé avant de rejeter une requête. En dernier recours, si aucun des fichiers de régulation spécifiés par loadPolicyFile() n'autorise la requête, Flash Player effectue une recherche à l'emplacement par défaut, /crossdomain.xml.

L'utilisation du protocole xmlsocket avec un numéro de port spécifique permet de récupérer directement les fichiers de régulation depuis un serveur XMLSocket, comme indiqué dans l'exemple suivant :

  Security.loadPolicyFile("xmlsocket://foo.com:414");
  

De cette manière, Flash Player peut récupérer un fichier de régulation au niveau du port et de l'hôte spécifiés. Il est possible d'utiliser n'importe quel port (et non plus uniquement le port 1024 ou un port de numéro supérieur). Lors de la connexion au port spécifié, Flash Player transmet <policy-file-request />, suivi d'un octet de terminaison null. Il est possible de configurer un serveur XMLSocket afin qu'il distribue des fichiers de régulation et des connexions XMLSocket normales en utilisant un port unique. Dans ce cas, le serveur attend de recevoir <policy-file-request /> avant de transmettre un fichier de régulation. Il est également possible de configurer un serveur afin qu'il distribue les fichiers de régulation et les connexions standard via des ports différents. Dans ce cas, le serveur peut transmettre un fichier dès qu'une connexion est établie au niveau du port dédié aux fichiers de régulation. Le serveur doit renvoyer un octet nul à la fin du fichier de régulation avant de fermer la connexion. Si le serveur ne ferme pas la connexion, Flash Player y met fin après avoir reçu l'octet de terminaison null.

La syntaxe des fichiers de régulation transmis par un serveur XMLSocket est identique à celle des autres fichiers de régulation, à l'exception près que ces fichiers doivent également spécifier les ports auxquels ils permettent d'accéder. Un fichier de régulation transmis via un port dont le numéro est inférieur à 1024 peut autoriser l'accès à tous les ports. Un fichier de régulation transmis via le port 1024 ou supérieur ne peut définir l'accès qu'au port 1024 et aux ports supérieurs. Les ports accessibles sont spécifiés par l'attribut "to-ports" dans la balise <allow-access-from>. Il est possible d'utiliser des numéros de ports, des plages de ports et des caractères génériques. L'exemple suivant illustre un fichier de régulation XMLSocket :

  <cross-domain-policy>
    <allow-access-from domain="*" to-ports="507" />
    <allow-access-from domain="*.foo.com" to-ports="507,516" />
    <allow-access-from domain="*.bar.com" to-ports="516-523" />
    <allow-access-from domain="www.foo.com" to-ports="507,516-523" />
    <allow-access-from domain="www.bar.com" to-ports="*" />
  </cross-domain-policy>
  

Les fichiers de régulation récupérés à partir de l'ancien emplacement par défaut (emplacement —/crossdomain.xml d'un serveur HTTP sur le port 80) permettent implicitement d'accéder aux ports 1 024 et supérieurs. Il est impossible de récupérer un fichier de régulation autorisant des opérations XMLSocket depuis un autre emplacement sur un serveur HTTP. Les emplacements personnalisés des fichiers de régulation XMLSocket doivent être situés sur le serveur XMLSocket.

L'autorisation de connexion aux ports inférieurs à 1 024 ne peut être accordée que par un fichier de stratégie chargé par loadPolicyFile().

Vous pouvez empêcher un fichier SWF d'utiliser cette méthode en définissant le paramètre allowNetworking des balises object et embed dans la page HTML qui comporte le contenu SWF.

Pour plus d'informations, consultez les références suivantes :

• Le chapitre relatif à la sécurité du manuel Programmation d'ActionScript 3.0 et les derniers commentaires disponibles dans LiveDocs
• Le Livre blanc sur la sécurité de Flash Player 9

Paramètres

Voir aussi

Affiche le panneau Paramètres de sécurité de Flash Player.

Paramètres

Voir aussi

Ce fichier SWF est un fichier local qui a reçu la confiance de l'utilisateur en utilisant soit le gestionnaire de paramètres, soit un fichier de configuration FlashPlayerTrust. Ce fichier SWF peut aussi bien lire à partir de sources locales de données qu'il peut communiquer avec Internet.

Voir aussi

Le fichier SWF est un fichier local qui n'a pas été approuvé par l'utilisateur, et n'a pas été publié avec la désignation de mise en réseau. Ce fichier SWF peut lire à partir de sources locales de données mais ne peut pas communiquer avec Internet.

Voir aussi

Le fichier SWF est un fichier local qui n'a pas été approuvé par l'utilisateur, et a été publié avec la désignation de mise en réseau. Le fichier SWF peut communiquer sur Internet mais ne peut pas lire les sources de données locales.

Voir aussi

Ce fichier SWF provient d'une URL et fonctionne selon les règles basées sur le domaine du sandbox.

Voir aussi