L'objectif des scénarios suivants est d'illustrer les effets des nouvelles règles de sécurité locales dans Flash Player 8.
Les règles de sécurité locales de Flash Player 8 ont été conçues pour protéger les utilisateurs. Pour ces derniers, les fichiers SWF locaux représentent généralement du contenu final, c'est-à-dire des éléments téléchargés depuis une source Internet ou installés en même temps qu'une application. Pour les auteurs Flash, toutefois, les fichiers SWF locaux sont bien souvent une simple version temporaire du contenu en cours de développement, c'est-à-dire des éléments destinés à être déployés sur un serveur HTTP. Des restrictions de sécurité peuvent donc parfois empêcher votre contenu de fonctionner comme prévu, simplement parce que vous lisez vos fichiers SWF alors qu'ils sont encore des fichiers locaux.
Les trois méthodes suivantes permettent de tester le contenu Flash en développement, par ordre de complexité croissante :
L'idéal, pour éviter des restrictions de sécurité indésirables pendant les tests d'aperçu dans un navigateur, serait que Flash Player puisse faire la différence entre le contenu Flash en cours de développement et les fichiers SWF non approuvés téléchargés sur Internet. Malheureusement, aucune méthode automatisée fiable ne permet à Flash Player d'effectuer cette opération.
Par contre, il est possible, et pratique, de configurer Flash Player de sorte qu'il fasse confiance à tous les fichiers SWF provenant d'une certaine zone de votre système de fichiers local. Par exemple, si vous stockez tout votre travail Flash en cours sous C:\FlashSites, vous pouvez ouvrir le Gestionnaire de paramètres et ajouter le répertoire C:\FlashSites à votre liste de chemins approuvés. Dès cet instant, chaque fois que vous affichez tout fichier SWF issu du répertoire C:\FlashSites ou de l'un de ses sous-répertoires, Flash Player le place dans le Sandbox Approuvé local, évitant ainsi tout échec lié à la sécurité. Par contre, assurez-vous de ne jamais placer de fichiers SWF issus de sources auxquelles vous ne faites pas confiance dans vos zones approuvées ! De même, le fait de conserver vos propres fichiers SWF locaux à l'écart des fichiers SWF non approuvés des autres auteurs vous permettra de bénéficier des mêmes protections améliorées que tous les utilisateurs de Flash Player.
Imaginons que vous configuriez un répertoire approuvé dans le Gestionnaire des paramètres. A présent, votre propre travail n'est plus interrompu par des problèmes de sécurité. Toutefois, vous devrez peut-être partager vos fichiers SWF en cours de développement avec divers collègues, auteurs HTML, développeurs Flex, artistes bitmap, etc. Ou encore, vous souhaiterez montrer vos fichiers SWF à vos supérieurs ou à des clients. Parmi ces personnes, certains n'auront probablement pas configuré de répertoire approuvé sur leurs ordinateurs. Donc, s'ils ouvrent vos fichiers SWF sous forme de fichiers locaux et que ces derniers tentent de communiquer avec Internet (par exemple en appelant getURL), ou avec des pages HTML, les règles de sécurité locales peuvent empêcher votre contenu de fonctionner comme prévu sur leurs ordinateurs. De plus, certains de ces membres de votre 'communauté de travail' n'auront probablement pas installé FlashAuthor.cfg sur leurs ordinateurs. Donc, si vos fichiers SWF sont de version 8 ou ultérieure, ils ne verront même pas les boîtes de dialogue d'avertissement leur signalant les raisons de l'échec.
Malheureusement, aucune recette magique ne permet de résoudre ces problèmes de 'communauté de travail'. A la base, le problème est que lorsque Flash Player s'exécute sur les ordinateurs de vos collègues, il n'a aucun moyen de distinguer (temporairement) vos fichiers SWF locaux des fichiers SWF potentiellement non approuvés issus de téléchargements sur Internet.
Le moyen le plus sûr pour résoudre ces problèmes de 'communauté de travail' consiste à publier vos fichiers SWF sur un serveur de test HTTP, puis d'envoyer des liens, plutôt que d'envoyer directement les fichiers SWF. Toutefois, cette méthode présente parfois des inconvénients ou se révèle impossible : par exemple, si vous ne disposez pas de serveur HTTP privé ou si vous devez partagez vos fichiers SWF avec des personnes extérieures à votre réseau et ne souhaitez pas les publier sur des serveurs publics. D'autres possibilités sont alors envisageables :
La meilleure solution dépend en fait de votre situation.
La majorité des nouvelles règles de sécurité locales resteront transparentes pour les utilisateurs finaux de Flash Player. Toutefois, comme nous venons de le voir, certains d'entre eux possèdent peut-être des applications Flash locales destinées à communiquer avec Internet. Dès que ces utilisateurs migrent vers Flash Player 8, des boîtes de dialogue leur signalent les opérations potentiellement risquées.
Dans ce cas, les options des utilisateurs sont simples. Ils peuvent choisir d'ignorer le problème, contacter le vendeur de l'application pour demander un correctif ou tenter de corriger eux-mêmes le problème.
Les utilisateurs qui décident de corriger le problème peuvent cliquer sur le bouton Paramètres de la boîte de dialogue d'avertissement. Le Gestionnaire des paramètres apparaît alors et leur permet d'obtenir des informations sur la sécurité locale, en choisissant Edit Locations > Add Location, puis de sélectionner un chemin local à approuver. L'identification du chemin qui peut être approuvé n'est pas toujours une tâche facile. Approuver le seul chemin qui apparaît dans la boîte de dialogue d'avertissement est parfois suffisant, mais il arrive aussi que plusieurs fichiers SWF soient impliqués dans l'application concernée. Dans ce cas, il est parfois nécessaire d'approuver l'ensemble du répertoire contenant ces fichiers SWF. Après avoir choisi les chemins à approuver, l'utilisateur doit revenir dans l'application qui a déclenché l'avertissement de sécurité et la redémarrer, par exemple en actualisant son navigateur.
Une fois dans le Gestionnaire de paramètres, l'utilisateur peut également choisir d'activer l'option 'Toujours autoriser' afin d'approuver tous les fichiers SWF des versions 7 et antérieures. Cette opération est bien plus simple que l'identification des chemins qui doivent être approuvés mais, en contrepartie, la sécurité des utilisateurs s'en trouve réduite.
Imaginons maintenant que vous développiez une application utilisant des fichiers SWF locaux et que certains de vos utilisateurs vous informent que des boîtes de dialogue de sécurité de Flash Player leur signalent des opérations potentiellement risquées lorsqu'ils affichent certaines parties de votre application. Disons que votre application est un système d'aide hybride, forme courante d'application SWF locale : un ensemble de fichiers HTML et SWF qui communiquent entre eux à l'aide de getURL et éventuellement de la fonction fscommand.
La première étape consiste à déterminer la gravité du problème. S'agit-il d'un composant essentiel d'une application importante avec une faille majeure ou d'une petite défaillance de votre violon d'Ingres ? Pensez-vous redistribuer les fichiers corrigés à tous vos utilisateurs ? La réponse sera souvent affirmative, mais assurez-vous que le jeu en vaut la chandelle.
Une possibilité consiste à demander à vos utilisateurs d'approuver le chemin d'accès à votre système d'aide dans le Gestionnaire des paramètres. Toutefois, cette opération peut être laborieuse pour certains utilisateurs ou leur poser des problèmes s'ils ne comprennent pas les implications de leurs décisions en matière de sécurité.
Une autre possibilité serait de republier vos fichiers SWF en tant que local/réseau, ou de les traiter ensuite à l'aide du Programme de mise à jour du contenu local*. Si les seules violations de sécurité provoquées par votre contenu proviennent d'appels à la méthode getURL, cela devrait être suffisant. Toutefois, si vous fichiers SWF et HTML se programment les uns les autres à l'aide de fscommand, de getURL ("javascript:...") ou d'autres opérations de script hybrides, le Sandbox local/réseau ne suffira pas pour restaurer l'état précédent de votre application. Vous devrez alors placer vos fichiers SWF dans un Sandbox Approuvé local.
Si vos utilisateurs disposent de connaissances techniques, vous pouvez leur fournir un fichier FlashPlayerTrust et des instructions sur son emplacement de stockage. Vous pouvez également créer un petit script ou programme créant automatiquement un fichier FlashPlayerTrust à l'emplacement approprié. Si vous savez où vos fichiers SWF sont installés, il vous suffit d'approuver le répertoire où ils doivent résider. Toutefois, si les utilisateurs ont choisi un emplacement d'installation personnalisé, il vous faudra peut-être leur signaler l'emplacement dans lequel ils ont installé votre contenu ou rechercher vos fichiers SWF dans leur système de fichiers local.
Pour notre dernier scénario, imaginons que vous développiez une application SWF locale destinée à synchroniser périodiquement des données avec un serveur HTTP et à servir de référentiel local de ces données le reste du temps. Les données en question étant le contenu d'un carnet d'adresses, on pourrait voir cette application comme un « gestionnaire de contacts parfois connectés ».
Disons que vous avez déterminé que vous avez besoin de droits d'Envoi Net, mais pas de droits de Lecture locale. Par exemple, vous n'avez pas besoin de lire des fichiers XML locaux pour la configuration. Ainsi, lors de la publication de vos fichiers SWF, vous activez l'option 'Accès au réseau uniquement' de la Sécurité de lecture locale dans les options de publication de Flash. Vos fichiers SWF sont maintenant libres d'utiliser getURL, XML.load et d'autres opérations HTTP.
Vous allez à présent vous attaquer à la connexion de votre application à la source de données HTTP nécessaire pour la synchronisation. Imaginons que vous utilisiez XML.sendAndLoad() pour échanger des données XML simples. XML.sendAndLoad étant une opération de Lecture Net, vous avez besoin d'un fichier de régulation sur le serveur HTTP avec lequel vous effectuez la synchronisation. Disons maintenant que vous souhaitiez que votre fichier de régulation ne gère que les données concernées, pas la totalité du serveur HTTP. Vous placez alors ce fichier de régulation à côté de la source de données XML et vous appelez System.security.loadPolicyFile dans votre fichier SWF client, en spécifiant l'emplacement du fichier de régulation. Le fichier de régulation a l'aspect suivant :
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Le fichier de régulation doit approuver tous les emplacements ("*") de sorte que vos fichiers SWF local/réseau puissent charger les données de votre serveur, tout en respectant le principe d'autorisations globales.
Et ça devrait marcher !
