Discussion :

[mamelouk]

Bonjour,

Imaginons que vous ayez un formulaire login/password dans votre appli GWT. Vous appelez la méthode de login() sur le serveur, que faites vous une fois que vous avez recu la réponse? :

1) vous redirigez vers la page qui contient l'application, et l'application redirige vers la page de login si l'authenfication n'est plus valide
2) l'application était déjà chargée, vous cachez le formulaire et l'affichez
3) autre

[Torg666]

moi j'ai choisi au lancement de l'appli d'afficher un fenetre de log, donc l'appli est déjà chargé.
Tant que pas de log/mdp valider la fenetre de log reste modale et donc le reste n'est pas accessible.
A voir si c'est une solution viable...

[pedouille]

C'est également ce que je fais ; pour sécuriser un minimum l'ensemble, je créé un sid lorsque l'utilisateur s'authentifie (et je le stocke côté serveur), et à chaque appel au serveur, je renvoi ce sid pour assurer que la personne s'est bien authentifié.

Une solution plus fiable peut être d'utilisé l'authentification HTTP d'Apache, mais cela déporte la gestion des utilisateurs hors de l'application, donc à voir...

[mamelouk]

cette solution me conviendrait aussi, sauf pour les pages d'administration, où je n'ai pas envie que ce soit possible, pour quelqu'un qui sait modifier le javascript en cours d'execution (via firebug par ex), de simuler un login réussi et de voir quels fonctions d'administration sont disponibles.

du coup, je vais voir comment se fait la gestion utilisateur coté apache... disons plus tard, car comme tout le monde j'ai des priorités ^^

merci

[Torg666]

Alors, dans mon cas, après le log je stock dans un objet, l'ID utilisateur et les ID droit lui correspondant.
Je ne crée rien sur le serveur, je ne crée pas de cookies et je vérifie jamais lorsque l'utilisateur accede à la base de donnée si il existe vraiment...
Par contre en fonction des droits de l'utilisateur je compte vérouiller les acces au differentes "fenetre" en me basant sur mon objet.
Alors de toute evidence, c'est pas suffisant... et je suis actuellement en train de me pencher sur la securité de mon appli... en fait je cherche a identifier les faille sans trop savoir comment m'y prendre et surtout savoir ce qui crains vraiment.
La seul chose que j'ai fais pour l'instant, c'est d'interdire l'usage de carateres speciaux sur le logging/mdp... ca devrai devrai limiter un peu les failles sur le log... mais après je dois avoue je sais pas trop quoi faire d'autre... si quelqu'un à des conseils je suis preneur

[pedouille]

Bonjour,

Mon premier conseil est de ne surtout pas stocké les informations sur les droits en clair côté client : il n'y a plus qu'a lire ces droits, et éventuellement les modifier (se fait très bien avec firebug, comme expliqué précédemment) pour s'attribuer n'importe quel droit.
De plus, la vérification des droits doit se faire côté serveur, car côté client, n'importe qui peut faire n'importe quoi. Toutes les actions côté serveur doivent donner lieu, au préalable à une vérification de la session : j'ai pour habitude de ne stocker qu'un numéro de session (hash MD5 quelconque) que je stocke côté client et serveur. Lors de tout appel au serveur, le client ajoute cet id de session dans les paramètres de la requête ; le serveur, avant de répondre, commence par regarder si il connait cet id de session, et récupère les infos nécessaire (Identifiant, droits sur l'applications,... tout ce dont on peut avoir besoin). A ce moment là, il vérifie si l'action demandée est possible pour l'utilisateur, et répond en conséquence.

Ce mode de fonctionnement des sessions est très classique, et assez solide, puisque pour s'attribuer des droits sans identification, il faut parvenir à capturer un identifiant de session valide et non périmé.

Voila, en espérant que ça puisse t'aider...

[Torg666]

Donc, en fait, il faut que je crée une session sur mon serveur et que avant d'interroger la BDD je confirme que la session coté client corresponde à une session coté serveur, quel serai le mieux:
- créer un objet par session?
- stocker les identifiant dans une liste par exemple?

Là je me pose une question, comment le serveur peut-il savoir qu'une session est terminée? Je suis un peu trop habituée à la JVM qui fais le ménage(+ ou -)... mais la étant donné que c'est interprété en Javascript... je sais pas trop.

De plus pour quitter mon application atm, "l'utilisateur" à pas 36 solutions, soit il se déconnecte "proprement" et ferme son browser (en gros ca arrivera jamais ou presque) soit il ferme son browser (le cas le plus courant a priori).

Dans le premier, je peu facilement le faire, dans le second... je sais pas... un thread coté client qui signale au serveur qu'il est toujours là... en fait je sais pas trop faut que je cherche un peu

Edit: en fais je suis trop bête, avec un WindowCloseListener ca devrai le faire.

[pedouille]

Pour stocker les sessions, c'est un peu au choix :
Perso, je fais un HashMap côté serveur dont la clé est l'id de session, et le contenu... peu importe en fait, ça dépend de tes besoins.
Une session est valide si le sid fourni par le client existe bien comme clé dans le hashmap.

Pour ce qui est de la fermeture de la session, c'est tout à fait ce que tu as dit ; à un détail près, si le navigateur plante. Dans ce cas là, il n'envoit pas l'évènement "Close" donc le serveur ne sait pas quand la session s'arrete, et elle est indéfiniment valide.

Pour palier à ce problème, il faut ajouter un timestamp dans le contenu de la session marquant par exemple, la dernière date d'activité enregistré pour cette session. A chaque appel, on remet cette date à now().
Ensuite, il faut utiliser un Timer qui vérifie à intervalles réguliers la validité de toutes les sessions du HashMap ; si l'une d'entre elle est expirée, il la supprime.

[kamel_leon]

Salut, je voulais savoir comment faire svp, si on peut naviguer sur une application web et quand on veut effectuer une action qui nécessite authentification, d'y revenir une fois l'authentification réussie
Merci d'avance