22 votes

question sur GWT, les cookies et la gestion des pages web

j'utilise gwt pour créer un site web. cette question concerne une page de connexion et les cookies pour sauvegarder les détails de connexion. GWT vous permet de créer un site web dans une seule page web.

J'ai configuré l'application de la manière suivante : il y a une boîte de connexion avec un bouton de connexion, et si les détails sont corrects, l'interface utilisateur sous-jacente sera chargée et la boîte de connexion sera supprimée.

Cela signifie qu'à chaque fois que je rafraîchis ma page, l'application m'amène à la page de connexion. Y a-t-il moyen de créer un cookie qui contienne les informations de l'utilisateur, par exemple un jour, qui entrerait les détails dans la boîte de connexion et se connecterait automatiquement ?

De même, le bouton de déconnexion dans l'application Web supprimerait les informations contenues dans le cookie et vous amènerait à la page de connexion (supprimer les informations du cookie et vous diriger vers la partie connexion de la page Web).

ou y aurait-il une approche différente.

61voto

Igor Klimer Points 11703

Je dirais que vous avez presque réussi :D Voici comment je gère les ouvertures et fermetures de session dans mon application :

  1. L'utilisateur charge la page - s'il a un cookie défini avec un jeton (voir les points suivants pour plus d'informations), envoyez ce jeton au serveur pour vérifier s'il est toujours valide. S'il est valide, vous êtes connecté, passez au point 5. Voir les notes ci-dessous sur la façon de gérer un jeton invalide.
  2. L'utilisateur saisit la combinaison utilisateur/pass. Cette information est envoyée au serveur (il serait préférable de l'envoyer via une connexion cryptée, mais c'est difficile à réaliser avec GWT - par exemple, voir cette question ).
  3. Le serveur vérifie si l'utilisateur/ hachage de mot de passe (voir ci-dessous) correspond à ce qui se trouve dans la base de données ou autre. Si c'est le cas, il génère un jeton (juste une chaîne aléatoire et plutôt longue, comme un UUID ) et le renvoie au client.
  4. Si l'utilisateur a coché la case "Se souvenir de moi" lors de la connexion, stockez le jeton dans un cookie avec une date d'expiration future (consultez d'autres guides/questions pour savoir quelle est la période recommandée).
  5. Lorsque le client reçoit le jeton, il doit l'utiliser pour chaque demande faite au serveur que vous voulez que seuls les utilisateurs authentifiés puissent exécuter. Le serveur vérifie alors si le jeton est valide (vous devez garder la trace des paires jeton/utilisateur dans votre base de données) et, si c'est le cas, autorise la transaction ou autre. Voilà le piège : si vous comptez uniquement sur le cookie, vous serez vulnérable à une attaque XSRF . C'est pourquoi vous devriez passer le jeton également (le cookie est transféré automatiquement - c'est pourquoi une attaque XSRF est possible) comme une partie de la demande (vous savez, comme un champ supplémentaire dans JSON ou un champ dans un POJO que vous envoyez via GWT-RPC ou même dans l'en-tête HTTP).
  6. En cas de déconnexion explicite (en cliquant sur le lien "Logout", etc.), envoyer une information au serveur que cet utilisateur vient de se déconnecter. Le serveur doit alors supprimer/invalider le jeton. Il doit le faire indépendamment de l'option "Se souvenir de moi", car une déconnexion explicite signifie que l'utilisateur veut supprimer ses informations de connexion sur ce PC/navigateur et empêcher d'autres personnes de se connecter en son nom. Si l'utilisateur ferme simplement le navigateur/la page et que vous avez correctement défini le cookie au point 4 (c'est-à-dire qu'il n'expirera pas à la fermeture du navigateur - là encore, uniquement si l'option "Se souvenir de moi" a été choisie), lors de sa prochaine visite, l'utilisateur devrait être automatiquement connecté au point 1.

Quelques notes supplémentaires

  • C'est très important : n'oubliez pas de vérifier, côté serveur, si le jeton transmis par le cookie est identique à celui transmis dans le cadre de la demande/du paiement.
  • Ne fais pas ça. stocker les mots de passe dans votre base de données en texte brut - stocker les hachages des mots de passe. Utilisez BCrypt pour une sécurité maximale. C'est pourquoi j'ai écrit que vous devriez comparer hachage des mots de passe et non les mots de passe réels.
  • Lorsque le serveur rencontre un jeton invalide, cela peut signifier un certain nombre de choses - de normal à alerte. En général, il est bon d'enregistrer ces situations et de vérifier régulièrement les journaux pour détecter toute activité anormale.
    1. L'utilisateur n'avait pas visité le site depuis longtemps et le jeton a expiré . Assurez-vous de gérer correctement l'expiration des jetons côté client (les dates d'expiration correctes des cookies devraient permettre à l'utilisateur d'être redirigé vers la page de connexion, sans envoyer le jeton expiré) et côté serveur (une tâche spéciale qui scanne quotidiennement la liste des jetons et supprime les jetons expirés ?)
    2. Peut-être que vous avez mis d'autres restrictions sur la validation des jetons - comme le jeton ne peut pas être expiré et la tentative actuelle doit provenir de la même IP que celle pour laquelle le jeton a été initialement généré.
    3. Il y avait un erreur lors de l'envoi de la demande et il est arrivé malformé/corrompu - on ne peut pas faire grand chose à ce sujet, mais rediriger l'utilisateur vers la page de connexion
    4. Un tiers essaie de se connecter en utilisant un jeton fabriqué à la main. . Si vous utilisez des jetons stupidement faciles à deviner (comme ceux basés sur le nom d'utilisateur, la rotation 13, votre propre "cryptage" super spécial, etc. sera se faire piquer par ça tôt ou tard. UUID est un exemple de bon candidat pour les jetons - comme son nom l'indique, il s'agit d'un jeton de type universellement unique ce qui signifie que deux utilisateurs ne doivent pas avoir le même UUID et que les UUID eux-mêmes sont aléatoires et longs.

La sécurité des applications AJAX est une affaire sérieuse - J'ai vu trop d'applications web avec des failles de sécurité faciles à exploiter... Assurez-vous de comprendre complètement ce que vous faites et pourquoi vous le faites. Si vous avez des questions, n'hésitez pas à les poser :)

4voto

Piotr Points 3808

Ici vous pouvez trouver quelques informations sur la sécurité de la connexion dans GWT. Il y a également une section sur la façon d'utiliser les cookies pour se souvenir qu'un utilisateur s'est connecté.

1voto

Voici le meilleur lien que j'ai pu trouver (avec des informations complètes). implementation ).un cycle complet de connexion avec maintien d'un cookie ( sessionId ).

Ce serait beaucoup mieux si vous aviez une option appelée " Remember me "

Gestion des sessions dans GWT

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X