Comme expliqué dans mon précédent post sur LCDS, il existe un réel problème de sécurité avec cette technologie et Flex.

Généralement, une fois que l'utilisateur est logué, il a un identifiant attribué, et on envoie cet identifiant au serveur lorsqu'on doit récupérer des données le concernant. Imaginons par exemple une base de données avec des batiments et des appartements. Chaque appartement est possédé par un propriétaire, et un propriétaire peut posséder plusieurs appartements. Une requête pour récupérer les appartements d'un propriétaire précis serait : select * from appart where userid=1; (où 1 serait l'identifiant du propriétaire).

Malheureusement, Un utilisateur mal intentionné aurait vite fait de décompiler l'animation swf et de pouvoir passer n'importe quel identifiant au serveur, afin de voir les données d'autres utilisateurs.

Après réflexion, c'est au niveau du serveur qu'il est nécessaire de stocker ces informations. Lorsqu'un utilisateur s'identifie sur le serveur, il faudrai pouvoir associer à cet utilisateur ses données sensibles, afin de les réutiliser lors de ses requêtes suivantes.

Seulement, c'est là qu'est le problème... Comment être sur de récupérer les bonnes données pour le bon utilisateur. Si on doit à chaque fois renvoyer une info pour être sur d'obtenir les données correspondant à l'utilisateur logué, le problème est persistant.
C'est là que mon expérience avec Flash Media Server à porté ses fruits. Lors de développements avec FMS, un utilisateur qui se connecte sur le serveur est représenté par un "client". Celà veut dire qu'un objet niveau serveur est instancié et chaque fois que ce même utilisateur va faire des demandes ou envoyer des données au serveur, dans la portée du code, on aura accès à cet objet. Pour simplifier l'explication, on peut imaginer ça comme une sorte de cookie de session. Lorsqu'on se connecte sur un site web, on ouvre une ."session" et tant qu'on reste à naviguer sur le site, cette session reste active, et elle permet de nous donner un accès. Chaque fois que nous allons demander l'affichage d'une page sécurisée, le code de la page va tester si notre session est valide et si c'est le cas, nous autoriser à y accéder.

Le principe est le même. Chaque utilisateur connecté sur le serveur LCDS est doté d'un objet de type "FlexClient", qu'on peut trouver dans le package flex.messaging.client.

Le package flex.messaging permet d'avoir accès aux données des clients connectés. On récupère le client courant via la méthode flex.messaging.FlexContext.getFlexClient().

Cet objet possède deux méthodes : setAttribute et getAttribute. Ces méthodes permettent respectivement d'ajouter et de récupérer une information dans l'instance de FlexClient.

Pour mes besoins, j'ai donc imaginé la mise en place de la sécurité de l'application côté serveur, en utilisant la méthode suivante :

1. l'utilisateur s'authentifie (envoi des identifiants de connexion, login et mot de passe)
2. Requête SQL au serveur de base de données pour comparer ces informations d'identifiant. Si l'utilisateur n'est pas existant, alors je retourne simplement une valeur qui va indiquer que les infos sont incorrectes. Dans le cas contraire, l'utilisateur est valide
3. Si l'utilisateur est valide, alors je récupère le FlexClient correspondant à l'utilisateur et lui rajoute, via la méthode FlexClient.setAttribute, son identifiant, ainsi que certaines autres informations sensibles au besoin
4. A partir de là, chaque fois que l'utilisateur authentifié va faire des demandes de données au serveur, si ces données doivent ne concerner que lui, c'est dans son objet FlexClient côté serveur que je vais récupèrer les informations sensibles qui feront partie des requêtes SQL
5. Une fois que l'utilisateur se déconnecte de l'application, il le fera par l'intermédiaire d'un système de logout. Cette action supprimera de son objet FlexClient les informations supplémentaires que j'avais ajoutées lors de l'authentification, rendant ainsi l'utilisateur invalide en matière d'authentification.

Ainsi, je peux m'assurer que chaque utilisateur n'accède bel et bien qu'à ses données personnelles et ne peux en aucun cas accéder aux données d'autres utilisateurs, mis à part si il se logue avec les identifiants d'un autre utilisateur, mais ça ne fait plus partie de la sécurité serveur, là on parle de sécurité personnelle, à chacun de savoir protéger ses identifiants comme il se doit.

Je ne dévoile pas la totalité de mon système de sécurisation, mais avec ces pistes, il est déjà probable que chacun puisse mettre en oeuvre une sécurité bien plus avancée qu'en passant les informations sensibles à travers le réseau à chaque fois