Security  - AS3

Détermine la façon dont Flash Player ou AIR sélectionne le domaine à utiliser pour certains paramètres de contenu, ce qui couvre les autorisations relatives à la caméra et au microphone, les quotas de stockage et le stockage d’objets persistants partagés. Afin que le fichier SWF utilise les mêmes paramètres que dans Flash Player 6, définissez exactSettings sur false.

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 la propriété Security.exactSettings est définie sur true, Flash Player ou AIR a recours à des domaines exacts pour les paramètres du lecteur. La valeur par défaut de la propriété exactSettings est false. Si vous modifiez la valeur par défaut de la propriété exactSettings, faites-le avant que tout événement impliquant la sélection de paramètres de la part de Flash ou d’AIR ne 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().

Partie du domaine de la page HTML contenant le fichier swf.

Pour des raisons de sécurité, la méthode ne renvoie pas l’adresse URL complète, mais uniquement le domaine de la page, notamment http://www.exemple.com. Si ce fichier SWF n’est pas contenu dans une page HTML ou n’est pas en mesure d’accéder au domaine de page pour des raisons de sécurité, cette propriété renvoie la chaîne undefined.

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

Security.sandboxType a l’une des valeurs suivantes :

• remote (Security.REMOTE) —  Ce fichier provient d’une URL Internet et fonctionne selon des règles de sandbox basées sur le domaine.
• localWithFile (Security.LOCAL_WITH_FILE) — Ce fichier est un fichier local qui n’a pas été approuvé par l’utilisateur, et il ne s’agit pas d’un fichier SWF publié avec une désignation de mise en réseau. Ce fichier peut lire à partir de sources locales de données mais ne peut pas communiquer avec Internet.
• localWithNetwork (Security.LOCAL_WITH_NETWORK) — Ce 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 à partir de sources de données locales.
• localTrusted (Security.LOCAL_TRUSTED) — Ce fichier est un fichier local qui a été approuvé par l’utilisateur en utilisant soit le gestionnaire de paramètres de Flash Player, soit un fichier de configuration FlashPlayerTrust. Ce fichier peut aussi bien lire à partir de sources locales de données que communiquer avec Internet.
• application (Security.APPLICATION) — Ce fichier est exécuté dans une application AIR, et a été installé avec le package (le fichier AIR) pour cette application. Par défaut, les fichiers dans le sandbox de sécurité de l’application AIR peuvent effectuer la programmation croisée de n’importe quel fichier issu de n’importe quel domaine (alors que les fichiers situés en dehors du sandbox de sécurité de l’application AIR peuvent ne pas être autorisés à effectuer la programmation croisée du fichier AIR). Par défaut, les fichiers du sandbox de sécurité de l’application AIR peuvent charger le contenu et les données de n’importe quel domaine.

Pour plus d’informations concernant la sécurité, voir la rubrique du Pôle de développement Flash Player : Sécurité (disponible en anglais uniquement).

Plus d’exemples

Eléments de l’API associés

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

Remarque : l’appel de cette méthode depuis le code dans le sandbox de l’application AIR émet une exception SecurityError. Le contenu situé hors du domaine de sécurité de l’application ne peut pas effectuer la programmation croisée du contenu dans le sandbox de l’application. Toutefois, le contenu situé hors du sandbox de l’application peut communiquer avec le contenu du sandbox de sécurité de l’application par un pont sandbox.

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 autorise les 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 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 super-domaine 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 super-domaine 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 super-domaine 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 concernant la sécurité, voir la rubrique du Pôle de développement Flash Player : Sécurité (disponible en anglais uniquement).

Paramètres

Plus d’exemples

Eléments de l’API associés

Permet aux fichiers SWF et HTML appartenant aux domaines identifiés d’accéder aux objets et variables du fichier SWF appelant, hébergé à l’aide du protocole HTTPS.

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 par le protocole HTTPS offre plusieurs protections pour vous et vos utilisateurs. Le fait d’appeler allowInsecureDomain affaiblit l’une de ces protections.

Remarque : l’appel de cette méthode depuis le code dans le sandbox de l’application AIR émet une exception SecurityError. Le contenu situé hors du domaine de sécurité de l’application ne peut pas effectuer la programmation croisée du contenu dans le sandbox de l’application. Toutefois, le contenu situé hors du sandbox de l’application peut communiquer avec le contenu du sandbox de sécurité de l’application par un pont sandbox.

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().

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 Pôle de développement Flash Player contient des informations détaillées sur Flash Player et la sécurité. Pour plus d’informations, voir la rubrique du Pôle de développement Flash Player : Sécurité.

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 concernant la sécurité, voir la rubrique du Pôle de développement Flash Player : Sécurité (disponible en anglais uniquement).

Paramètres

Eléments de l’API associés

Recherche un fichier de régulation à l’emplacement spécifié par le paramètre url. Adobe AIR et Flash Player utilisent des fichiers de régulation pour déterminer s’ils autorisent des applications à charger des données depuis des serveurs autres que celui sur lequel elles se trouvent. Notez que même si la méthode se nomme loadPolicyFile(), le fichier n’est pas chargé tant qu’une requête réseau impliquant un fichier de régulation n’est pas créée.

Avec Security.loadPolicyFile(), Flash Player ou AIR peut charger les fichiers de régulation à partir d’emplacements aléatoires, comme l’illustre l’exemple suivant :

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

De cette manière, Flash Player ou AIR tente de récupérer un fichier de régulation à partir de l’URL spécifiée. Les autorisations accordées par l’intermédiaire du fichier de régulation 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 ou AIR 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 ou AIR consulte les emplacements d’origine par défaut.

Lorsqu’il recherche un fichier de régulation maître,. Flash Player attend une réponse du serveur pendant trois secondes. En l’absence d’une réponse, l’application considère qu’il n’existe pas de fichier de régulation maître. Toutefois, si aucune valeur de dépassement de délai par défaut est définie pour les appels à loadPolicyFile(), Flash Player suppose que le fichier appelé existe et attend aussi longtemps que nécessaire pour le charger. Pour avoir la certitude qu’un fichier de régulation maître est chargé, appelez-le donc explicitement par le biais de loadPolicyFile().

Vous ne pouvez pas vous connecter aux ports généralement réservés. Pour obtenir une liste complète des ports bloqués, voir la rubrique « Restriction des API de réseau » dans le Guide du développeur d’ActionScript 3.0.

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 l’illustre l’exemple suivant : Les connexions de socket ne sont pas soumises aux restrictions de ports réservés décrites ci-dessus.

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

De cette manière, Flash Player ou AIR peut récupérer un fichier de régulation au niveau du port et de l’hôte spécifiés. Lors de la connexion au port spécifié, Flash Player ou AIR transmet <policy-file-request />, suivi d’un octet de terminaison null. Le serveur doit renvoyer un octet null à la fin du fichier de régulation avant de fermer la connexion. Si le serveur ne ferme pas la connexion, Flash Player ou AIR y met fin après avoir reçu l’octet de terminaison null.

Vous pouvez éviter qu’un fichier SWF utilise cette méthode en définissant le paramètre allowNetworking des balises object et embed dans la page HTML qui héberge le contenu SWF.

Pour plus d’informations concernant la sécurité, voir la rubrique du Pôle de développement Flash Player : Sécurité (disponible en anglais uniquement).

Paramètres

Plus d’exemples

Affiche le panneau Paramètres de sécurité de Flash Player. Cette méthode ne s’applique pas au contenu dans Adobe AIR ; son appel dans une application AIR n’a aucun effet.

Paramètres

Eléments de l’API associés

Le fichier est exécuté dans une application AIR, et a été installé avec le package (le fichier AIR) pour cette application. Ce contenu est inclus dans le répertoire des ressources de l’application AIR (où le contenu de l’application est installé).

Eléments de l’API associés

Ce fichier est un fichier local qui a été approuvé par l’utilisateur en utilisant soit le gestionnaire de paramètres de Flash Player, soit un fichier de configuration FlashPlayerTrust. Ce fichier peut aussi bien lire à partir de sources locales de données que communiquer avec Internet.

Eléments de l’API associés

Le fichier est un fichier local qui n’a pas été approuvé par l’utilisateur, et il ne s’agit pas d’un fichier SWF publié avec une désignation de mise en réseau. Dans Adobe AIR, le fichier local n’est pas dans le répertoire des ressources de l’application ; ce type de fichier est placé dans le sandbox de sécurité de l’application. Ce fichier peut lire à partir de sources locales de données mais ne peut pas communiquer avec Internet.

Eléments de l’API associés

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

Eléments de l’API associés

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

Eléments de l’API associés