• Facile

Ce cours est visible gratuitement en ligne.

Vous pouvez être accompagné et mentoré par un professeur particulier par visioconférence sur ce cours.

J'ai tout compris !

Mis à jour le 21/11/2013

Sécurité et Flash

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Nous allons étudier, dans la suite de ce chapitre, de nombreuses méthodes qui permettent de charger du contenu, dynamique ou non.
Mais depuis sa version 7, le Flashplayer intègre un nouveau dispositif de sécurité, qui empêche le chargement de données à partir d'un domaine distant.

crossdomain.xml

Imaginons que vous ayez une animation Flash sur votre site. Si vous lui demandez de charger des données textes ou binaires (images ou animations Flash) dans le même domaine, il n'y a pas de problème. Par même domaine, j'entends que vous utilisez un chemin d'accès relatif pour accéder aux données comme "monfichiertexte.txt", si le fichier est dans le même dossier que l'animation.

Maintenant, si vous utilisez un chemin d'accès complet pour accéder aux données, Flash ne se posera pas la question de savoir si le domaine est le même que celui de l'animation (ou pas) : il refusera l'accès aux données !

Sauf si vous placez à la racine du domaine un fichier bien spécial, un fichier texte au format XML pour être précis, il s'agit du fichier : crossdomain.xml.

Structure de crossdomain.xml

Maintenant, placez-vous du côté du webmaster qui veut, ou ne veut pas, faire charger des données à partir d'une animation hébergée sur un autre site.

Il va devoir placer un fichier crossdomain.xml à la racine de son site Web pour préciser les autorisations. Ce fichier sera chargé automatiquement par une animation Flash qui tenterait d'accéder aux données sur le domaine.

Voici un schéma résumant la situation :

Image utilisateur

Bref, ne sachant pas si vous utiliserez des chemins d'accès absolus ou pas, on va prévenir tout risque, et installer notre petit fichier XML à la racine de notre site.

Voilà comment se présente un crossdomain.xml classique :

<?xml version="1.0"?>
<cross-domain-policy>
        <allow-access-from domain="domaine_a_autoriser" />
</cross-domain-policy>

Il vous suffit de remplacer domaine_a_autoriser par le domaine que vous souhaitez autoriser.

Par exemple, si le Site du Zéro voulait autoriser l'accès à son site aux animations Flash, il faudrait que le Webmaster place à la racine du site (http://www.siteduzero.com/crossdomain.xml) un fichier xml qui autorise l'accès provenant de tous les domaines, on utilise donc l'étoile * comme "joker" :

<?xml version="1.0"?>
<cross-domain-policy>
        <allow-access-from domain="*" />
</cross-domain-policy>

On pourrait aussi accepter que les données ne soient chargées que de sites possédant un nom de domaine français en .fr et allemand en .de :

<?xml version="1.0"?>
<cross-domain-policy>
        <allow-access-from domain="*.fr" />
        <allow-access-from domain="*.de" />
</cross-domain-policy>

Je pense que vous avez bien compris. :D

Nouveautés de FlashPlayer 8

Le Flashplayer 8 offre une nouveauté intéressante : il nous permet de spécifier le chemin d'accès à un fichier crossdomain.xml.
C'est une option qui n'est pas très utile, car comme tout le monde ne possède pas le dernier FlashPlayer, il est préférable de conserver le fichier crossdomain.xml à la racine des sites Web.

Voilà comment s'y prendre : le fichier crossdomain.xml doit toujours être placé dans le site, mais il n'est plus indispensable qu'il se trouve à la racine. Il faudra par contre préciser dans l'animation Flash où il se trouve.

System.security.loadPolicyFile("http://www.tondomaine.com/crossdomain.xml");

Cette ligne de code est en fait superflue, puisque FLash irait de toute façon chercher le crossdomain.xml à la racine du site !

Mais vous pourriez tout aussi bien vous adapter à un fichier de police placé de façon non standard :

System.security.loadPolicyFile("http://www.tondomaine.com/undossier/unfichier.xml");

Contourner la protection

Nous allons maintenant voir une petite astuce toute bête permettant de "contourner" cette protection. J'écris "contourner" entre guillemets, car cette protection n'est pas là pour embêter le créateur d'une animation, ou l'utilisateur lambda. Elle permet seulement aux webmasters qui le souhaitent de protéger leur site Web d'un téléchargement abusif s'effectuant à partir des clients exécutant l'animation.

Alors qu'avec notre astuce, l'animation téléchargera les données en passant par un script sur votre serveur. Ça ne sera donc pas à votre avantage de faire télécharger des données d'un site web de façon abusive, puisque ça encombrera le vôtre !

Vous allez déjà placer un crossdomain.xml à la racine de votre site pour éviter les ennuis.

Ensuite, vous allez créer un fichier chargement.php :

<?PHP
readfile($_GET['lien']);
?>

Ainsi, si vous devez charger un fichier dans votre animation, et que ce fichier est placé sur un autre site Web sans crossdomain.xml, vous pourrez passer par votre fichier chargement.php.

Par exemple, si vous voulez charger dans votre animation la liste des news du SDZ à cette adresse http://www.siteduzero.com/Templates/xml/news_fr.xml, comme www.siteduzero.com ne possède pas de crossdomain.xml, vous aller charger cette page : chargement.php?lien=http://www.siteduzero.com/Templates/xml/news_fr.xml

En fait, il est même préférable "d'encoder" le lien avec la fonction escape() de Flash que nous avons déjà vu dans un chapitre précédent.
Une fois encodée au format URL, votre animation chargerait en fait :
chargement.php?lien=http%3A%2F%2Fwww%2Esiteduzero%2Ecom%2FTemplates%2Fxml%2Fnews%5Ffr%2Exml
Mais il faudrait alors décoder le lien dans le script PHP :

<?PHP
$lien = urldecode($_GET['lien']);
readfile($lien);
?>

Bon. Pour l'instant, vous ne savez pas encore comment charger ce fichier dans Flash, mais vous connaissez au moins la théorie. ;)

Vous l'aurez compris, pour être tranquille, il est indispensable de créer un fichier crossdomain.xml à la racine des sites d'où vous désirez charger du contenu.

L'utilité de System.security.loadPolicyFile() peut vous paraître superflue, mais nous verrons peut-être beaucoup plus loin dans ce tutoriel, que cette méthode a son importance quand on possède un serveur xmlsocket.

Vous devez aussi garder en tête que cette protection permet surtout de protéger le webmaster d'un site qui ne souhaite pas se faire "voler" des centaines de mégaoctets. Néanmoins, il est très facile de contourner cette protection en utilisant un script PHP, mais dans ce cas, les données circuleront par le site web hébergeant l'animation.

Exemple de certificat de réussite
Exemple de certificat de réussite