web-dev-qa-db-fra.com

Pourquoi définir une directive JSP page session = "false"?

Je me demandais quand vous voudriez définir la directive de page suivante dans un JSP:

<%@ page session="false" %>

Je sais que cela empêche la création de l'objet de session, mais quand auriez-vous besoin de le faire? Est-ce considéré comme une bonne pratique lorsqu'un JSP n'a pas besoin d'accéder à la session implicite?

NOTE: La raison pour laquelle je pose cette question est parce que c'était dans ce tutoriel Spring MVC et je suppose que les gens de SpringSource connaissent leur travail} _ - http://blog.springsource.com/2011/01/04/haricots verts: faire-démarrer-avec-le-printemps-mvc/

58
Mike G

Une des raisons serait performance et memory . Si vous avez une page qui n'a pas besoin d'être impliquée dans une session (comme par exemple un about.jsp ou un faq.jsp), le comportement par défaut d'impliquer chaque JSP dans une session imposera la surcharge de la création d'un nouvel objet de session (le cas échéant). existe déjà) et une utilisation accrue de la mémoire, car davantage d’objets résident sur le tas. 

Cet effet sera grandement exagéré dans le cas où une page unique affichait un trafic élevé associé à un taux de rebond élevé, c’est-à-dire que les utilisateurs ne continueraient pas à parcourir le site, mais quitteraient le site immédiatement après avoir visualisé cette page. objet de session par utilisateur qui ne sera plus jamais utilisé et sera finalement récupéré après son expiration - ajouté au début de la création d’objet, de l’utilisation de la mémoire et du nettoyage de la mémoire sans vous donner une valeur réelle.

80

Ce paramètre est également une mesure de sécurité, car il évite également une attaque potentielle DoS . Pensez à un script simple qui itérativement wgets le JSP: il générera beaucoup de sessions en quelques secondes.

18
sde

J'ai en fait un scénario réel dans mon application pour son utilisation. Squid agit en tant que proxy inverse devant notre application. Le serveur squid est configuré pour interroger toutes les instances Tomcat hébergeant notre application afin de vérifier que les serveurs sont opérationnels et, sinon, Squid basculera vers un autre serveur de notre cluster.

L'interrogation réelle de Squid vers notre application est configurée pour interroger une page spécifique de l'application. Le sondage de Squid n'étant pas un navigateur, il ne peut pas tenir de session. Cela signifie que chaque sondage sur la page du serveur obligerait Tomcat à créer une session à laquelle Squid ne peut pas faire référence. Nous ajoutons la directive <%@ page session="false" %> afin qu'aucune session ne soit créée sur chaque sondage. Si nous n'utilisions pas cette directive, des milliers de sessions seraient créées plus de 4 heures sans raison.

5
Reimius

Je me suis plongé dans un autre cas d'utilisation dans mon application de production, en pensant que je le partagerais ici au cas où cela aiderait quelqu'un.

Nous avons une application Web UI qui protège la plupart des ressources via une session. Cependant, certaines ressources sont protégées par une partie du niveau Web situé en face de notre application dans notre déploiement en production. Par conséquent, en ce qui concerne l'application, ces ressources sont totalement non protégées. Certaines de ces ressources "non protégées" sont des JSP.

Dans le cas où un utilisateur établit une session sur l'une de nos ressources protégées, puis passe un appel XHR du navigateur à l'une des ressources "non protégées", nous rencontrions un problème où le conteneur prétend qu'un utilisateur anonyme tente d'accéder une session de l'utilisateur foo , arrêtant ainsi l'exécution. Configurer le JSP "non protégé" pour qu'il n'utilise pas de sessions nous a permis de résoudre ce problème.

0
austinbruch

Un autre cas d'utilisation où il est réellement nécessaire d'ajouter cette directive concerne l'utilisation du filtre noSessionCreation d'Apache Shiro dans le fichier de configuration .ini, par exemple. parce que votre schéma d'authentification est sans état. Si vous en manquez, vous rencontrerez un org.Apache.shiro.subject.support.DisabledSessionException.

0
Hein Blöd