Lors de la mise en œuvre de la fonctionnalité "Mémoriser de moi" pour un site Web, pourquoi compliquerons-nous les choses et avoir un jeton appelé souvenir de moi des jetons d'un jeton de session.
Au meilleur de ma compréhension, souvenez-vous que ME Jeton peut être utilisé pour vous connecter et créer un nouveau jeton de session tandis que le jeton de session ne dure que quelques minutes ou jusqu'au moment de la fermeture du navigateur. Pourquoi ne pouvons-nous augmenter la durée d'expiration du jeton de session elle-même à la durée souhaitée que nous souhaitons que l'utilisateur soit connecté?
J'ai besoin de mettre en œuvre une telle fonctionnalité dans une application basée sur Flex fonctionnant sur Tomcat et je me demande la nécessité de me souvenir des jetons
Aussi, est-il possible d'obtenir cette fonctionnalité de la boîte dans Tomcat?
5 Réponses :
Par exemple, une session se termine dès que l'utilisateur ferme son navigateur. Ainsi, le cookie de session expirera dès que le navigateur est fermé.
Depuis que le but de la fonctionnalité des souvenirs est de garder l'utilisateur connecté à travers des sessions, les informations stockées dans le cookie mémorisée de souvenir doivent persister sur des redémarrages du navigateur.
Pour obtenir cette fonctionnalité "hors de la boîte" Regardez à l'aide d'un cadre comme Spring Security .
Si nous ajoutons la clause expirée dans le cookie de session, il peut être fait durer à un certain nombre de jours, quel est le préjudice dans cela? Existe-t-il une raison spécifique d'écrire un mécanisme compliqué d'avoir deux jetons différents?
N'oubliez pas que les cookies stockent habituellement le nom d'utilisateur et une sorte de jeton. Les deux d'entre eux sont utilisés pour authentifier l'utilisateur. Jetez un coup d'œil à Meilleure pratique de Cookie de connexion persistante qui décrit le processus assez bon.
Le cookie de session est utilisé pour stocker un ID de session sur le client qui permet au serveur de reconnaître une session une session une chargement des données de session associées à la session.
N'oubliez pas que les cookies de moi ont une durée de vie plus longue (généralement des jours ou des semaines) que des cookies de session. Les cookies de session expirent généralement après quelques minutes ou lorsque le navigateur est fermé.
Du sommet de ma tête, il y a quelques raisons pour lesquelles deux cookies différents sont utilisés:
Mais ce que je manque de comprendre, c'est pourquoi ne peut pas être prolongé de la vie d'un cookie de session lorsque nous avons besoin de sessions plus longues. J'ai essayé d'ajouter un filtre de servlet qui ajoute une clause d'expiration à un cookie de session et augmente ainsi sa durée d'expiration. Je ne pouvais pas voir le préjudice dans l'utilisation d'une telle approche qui est tout à fait pratique pour moi au lieu de construire un tout nouveau mécanisme d'introduire un cookie souvenir de moi dans ma demande. Si j'ajoute un souvenir de moi Cookie, j'ai besoin de faire un certain nombre de modifications à mon application.
Donc, je suppose que vous n'utilisez pas la sécurité de printemps ni même la combinaison des flamboyants, de la sécurité du ressort et de l'intégration de Spring Flasheds sur votre serveur, n'est-ce pas? Ceux-ci pourraient fournir la fonctionnalité des souvenirs de la boîte de la boîte. Si vous changez vraiment la date d'expiration du cookie de session, n'oubliez pas de configurer le délai d'expiration de la session sur le serveur. Sinon, le serveur pourrait invalider la session trop tôt.
Je ne suis que dans la phase d'évaluation, j'ai une application flambée où j'essaie d'implémenter l'authentification. L'ajout d'une expiration à la session Cookie semblait être une option facile, alors que je ne suis pas sûr que Spring Security peut facilement fonctionner avec une application blazeds, y compris sa fonctionnalité de souvenir de moi
Jetez un coup d'œil à Intégration de Spring Blaseds . La dernière version ajout de la prise en charge de la fonctionnalité de souvenir de Spring Security. Il vous permet donc d'utiliser la sécurité de printemps et les flamboyants et avec un peu de configuration de printemps, tout devrait fonctionner hors de la boîte.
1) Les sessions contiennent généralement un tas de données autres que le nom de connexion de l'utilisateur. Par conséquent, si vous venez de définir la date d'expiration à quelques semaines ou quelques mois comme un jeton de souvenir de moi, vous rencontreriez probablement des problèmes de performances sur le serveur en raison de milliers ou de millions d'objets de session de poids lourds.
2) N'oubliez pas que les jetons sont le côté client, pas du côté serveur. Cela met toutes les exigences de stockage sur le navigateur de l'utilisateur, qui constitue une meilleure solution pour des données simples telles que les noms de connexion. Si vous vous êtes invoqué sur des identifiants de session liés à des objets en mémoire sur le serveur, vous redémarrez chaque fois que vous redémarrez votre serveur ou votre processus de serveur (pour déployer une application mise à jour, par exemple), tous ces objets de session seraient perdus.
Est-il possible d'intégrer de manière transparente la sécurité du ressort à votre application Flex sans affecter le code client?
Je n'ai aucune idée de l'intégration de mon application Flex à la sécurité du printemps pour utiliser sa fonction Me souvenir de moi, est-il possible de le faire.
Je ne sais pas, je n'utilise pas le printemps ou le flex.
Les gens ont dit correctement que la session contient un certain nombre d'objets de poids lourds. Avec suffisamment d'utilisateurs sur votre système, si vous essayez de les garder tous dans la quantité finie de mémoire que le serveur a, éventuellement, vous allez planter le serveur lorsque la mémoire Max est sortie.
J'ai travaillé sur un projet une fois où une mise à jour de code de production avait une fuite de mémoire. C'était un projet J2EE (oui J2EE non Java EE). Lorsqu'un utilisateur connecté pour vérifier sa facture à cette société de téléphone, la session utilisateur n'a pas été publiée correctement à partir de la mémoire (je ne me souviens pas de la cause, mais c'était définitivement le problème). Ce bogue imite ce que vous demandez de faire exprès.
Le serveur a continué de creuser. Nous avons donc mis un profileur dessus. Nous regarderions la mémoire que l'utilisation de la mémoire augmente la journée jusqu'à ce qu'elle soit surmontée et shorty après l'accident du serveur d'applications. Nous avons ajouté de la mémoire et avons augmenté le paramètre de mémoire VM. Je leur ai dit que c'était une fuite de mémoire mais parce que je n'étais pas une personne de 200,00 $ / heure de "expert du serveur" ne voulait pas y croire parce que les personnes qui étaient là ont encore cru que le collectionneur des ordures était tout puissant au lieu d'être tout simplement très bon.
Deux jours plus tard (il affectait le système "Afficher votre facture", pas le système commercial principal, c'est-à-dire qu'il n'avait pas la même charge de travail ou la même-mémoire, même s'il avait beaucoup de mémoire matérielle dans les serveurs), ils ont embauché Quelques consultants de 200,00 $ par heure qui, après une journée, leur ont dit que l'application avait une fuite de mémoire susmentionnée. C'était fixé et tout était bon ... moins les frais de consultants.
Dans tous les cas, voici le retrait de ceci: Si vous ne mettez pas fin à des sessions utilisateur lorsque les utilisateurs se déconnectent ou ferment leur navigateur (heure de la session OUT), vous exécutez un risque réel de maxing votre mémoire et de vous bloquer vos serveurs. . Surtout si votre site ou votre application comporte un nombre important d'utilisateurs. Comme mentionné par d'autres, les jetons légers / biscuits sont les meilleurs.
La raison pour laquelle nous devrions utiliser un autre cookie autre que le cookie de sessionID pour vous rappeler que l'utilisateur n'est pas parce que les sessions devraient expirer rapidement ou faire face à des problèmes de performances sur le serveur.
Jetée (et probablement de nombreux autres conteneurs de servlet) dispose d'une fonctionnalité qui permet d'expulsion automatique des sessions inactives de la mémoire au disque ou à la base de données que l'IMHO résume toutes les justifications ci-dessus autour de problèmes de performances fournis avec stockage des sessions de poids en mémoire.
La raison pour laquelle un autre cookie est utilisé est que vous souvenez-vous - moi de se rappeler l'utilisateur même après l'expiration de la session. Donc, si la session d'utilisateur a expiré, l'autre cookie est utilisé pour authentifier l'utilisateur sans qu'ils doivent entrer un mot de passe, ce qui rend évidemment des attaques de phishing moins probables. Bien qu'il y ait également des inconvénients, par exemple si quelqu'un gagne de l'accès à votre ordinateur portable et de voler vos jetons d'authentification serait en mesure de vous imiter, sauf si le serveur ne s'applique encore plus de mesures de sécurité pour lier le jeton à votre client et à votre emplacement. < / p>
En bref, rappelez-vous-moi est un mécanisme d'authentification et non un remplacement des cookies de session.
Je crois que cela va bien d'avoir des dates d'expiration de session à long terme tant qu'ils sont stockées hors de la mémoire. Et une fois qu'ils expirent, demandez simplement un mot de passe. De nombreux sites Web offrent cette fonctionnalité comme «Se souvenir de moi depuis 30 jours», qui est obtenue simplement en utilisant un biscuits de sessionID à long terme, rien d'autre.