Nécessité de définir l'en-tête de cookie sur l'utilisation AIR de SWFLoader pour récupérer le fichier Flex .swf distant

Question

Je suis en train de coder une application AIR 1.5 dans laquelle je souhaite charger à distance un fichier Flex .swf à partir d'un serveur Web. J'utilise Flex 3.2 SDK et j'essaie d'utiliser la fonction de sous-application via SWFLoader. J'ai référencé le document de développement et de chargement des sous-applications sur la façon de procéder.

Je peux effectivement charger avec succès le fichier .swf Flex à partir d'un serveur Web distant et il est chargé dans un sandbox distant. Les formulaires en cours d'exécution de ce fichier .swf respectent même le paramètre de transparence que j'ai défini sur la fenêtre native AIR.

Voici le hic:

Pour une situation de production, notre serveur web utilise Spring Security pour détourner tout accès non autorisé à une page Web de connexion (ce qui est le cas pour les déploiements de construction développement/AQ normales ainsi). Si une connexion réussie a été effectuée, la réponse du login définit un cookie. Cet en-tête de cookie doit être présent sur toutes les interactions HTTP ultérieures qui cherchent à extraire le contenu du site.

Je ne peux pas comprendre comment définir un en-tête de cookie sur mes utilisations de SWFLoader pour récupérer les fichiers Flex .swf. Comment puis-je utiliser SWFLoader pour récupérer des fichiers d'un site web protégé par Spring Security (qui est un moyen largement utilisé pour sécuriser l'accès aux sites Web basés sur Java), qui s'appelait auparavant la sécurité Acegi avant de fusionner avec Source de printemps).

L'exécution de notre code Flex était un jeu d'enfant lorsque vous l'utilisiez dans un navigateur Flash Player sandbox - les éléments de Spring Security étaient gérés par le navigateur. Essayer d'exécuter notre application Flex dans AIR en tant que sous-application dans les limites sûres d'un sandbox distant s'avère être une expérience infernale. Le contrôle HTML d'AIR, bien qu'il fonctionne assez bien avec Spring Security, est une interdiction car tout contenu .swf ou .pdf chargé n'apparaîtra pas si la transparence est définie sur true dans la fenêtre native AIR. Notre conception particulière de l'interface utilisateur exige que la transparence soit définie sur true car nous faisons des fenêtres enfants MDI qui flottent sur le bureau de l'utilisateur.

Answer 1

J'ai résolu ce problème en enchaînant l'utilisation d'un contrôle AIR HTML conjointement à l'utilisation de SwfLoader pour ensuite charger le fichier .swf distant désiré. J'ai écrit une fonction JavaScript sur une page Web HTML que mon application AIR charge dans une instance HTML (lorsque l'événement de fin de page se déclenche, il est alors possible d'appeler la fonction JavaScript à partir du code AIR Flex - le code Flex peut, bien sûr, gérer l'événement HTML complet).

Cette fonction JavaScript utilise XmlHttpRequest() pour se connecter au site Web qui utilise Spring Security pour l'autorisation. Un en-tête Set-Cookie est traité lors d'une connexion réussie. Lorsque la réponse pour XmlHttpRequest() est terminée, un événement click synthétique est distribué sur un objet DIV fictif qui a été placé sur la page Web. Le code AIR Flex peut enregistrer et traiter cet événement de clic synthétique. Lors du traitement de l'événement click, le code AIR Flex sait alors qu'il est prudent de procéder à l'instanciation d'une instance de SwfLoader. Lorsque l'événement complet de l'objet SwfLoader se déclenche, la référence d'objet du SwfLoader est placée dans la liste d'affichage de l'application AIR.

L'utilisateur voit alors le fichier SWF chargé à distance commencer à s'exécuter et afficher sa propre interface utilisateur. Il s'exécute dans un contexte de sandbox distant sous-application. La fonctionnalité de sous-application est prise en charge dans Flex SDK 3.2 via le contrôle SwfLoader. L'application AIR gère donc l'en-tête de cookie établi par le contrôle HTML. Cet en-tête de cookie est émis dans la requête HTTP du contrôle SwfLoader lorsqu'il est utilisé pour charger le fichier .swf distant. Le filtre de sécurité Spring voit cela et trouve que la requête provient d'une session utilisateur authentifiée.