poner cookie borde java jsessionid

cookie - poner borde a un jlabel en java



¿Bajo qué condiciones se crea un JSESSIONID? (5)

¡Cuidado si tu página incluye otros .jsp o .jspf (fragmento)! Si no te pones

<%@ page session="false" %>

también en ellos, la página principal terminará iniciando una nueva sesión y configurando la cookie JSESSIONID.

En particular, para las páginas .jspf, esto sucede si configuró su web.xml con tal fragmento de código:

<jsp-config> <jsp-property-group> <url-pattern>*.jspf</url-pattern> </jsp-property-group> </jsp-config>

con el fin de habilitar los scriptlets dentro de ellos.

¿Cuándo / cuáles son las condiciones cuando se crea un JSESSIONID ?

¿Es por dominio? Por ejemplo, si tengo un servidor de aplicaciones Tomcat e implemento varias aplicaciones web, ¿se creará un JSESSIONID diferente por contexto (aplicación web), o se compartirá entre aplicaciones web siempre que sean del mismo dominio?


Aquí hay alguna información sobre una fuente más de la cookie JSESSIONID :

Acabo de depurar un código Java que se ejecuta en un servidor Tomcat. No estaba llamando a request.getSession() explícitamente en ninguna parte de mi código, pero noté que todavía se estaba configurando una cookie JSESSIONID .

Finalmente, eché un vistazo al código Java generado correspondiente a una JSP en el directorio de trabajo debajo de Tomcat.

Parece que, te guste o no, si invocas un JSP desde un servlet, ¡ JSESSIONID se creará!

Agregado: acabo de encontrar que al agregar la siguiente directiva JSP:

<%@ page session="false" %>

puede deshabilitar la configuración de JSESSIONID mediante un JSP.


CORRECCIÓN: vote por la respuesta de Peter Štibraný, ¡es más correcta y completa!

Un "JSESSIONID" es el ID único de la sesión http: consulte el javadoc aquí . En el javadoc, encontrará la siguiente frase: "La información de la sesión se aplica solo a la aplicación web actual (ServletContext), por lo que la información almacenada en un contexto no será directamente visible en otro".

Entonces, cuando llegas por primera vez a un sitio, se crea una nueva sesión y se vincula al SevletContext. Si implementa múltiples aplicaciones, la sesión no se comparte.

También puede invalidar la sesión actual y, por lo tanto, crear una nueva. Por ejemplo, al cambiar de http a https (después de iniciar sesión), es una muy buena idea crear una nueva sesión.

Espero que esto responda a su pregunta.


La cookie JSESSIONID se crea / envía cuando se crea la sesión. La sesión se crea cuando el código llama a request.getSession() o request.getSession(true) por primera vez. Si solo desea obtener la sesión, pero no crearla si no existe, use request.getSession(false) : esto le devolverá una sesión o un null . En este caso, no se crea una nueva sesión y no se envía la cookie JSESSIONID. (Esto también significa que la sesión no se crea necesariamente en la primera solicitud ... usted y su código tienen el control cuando se crea la sesión)

Las sesiones son por contexto:

SRV.7.3 alcance de sesión

Los objetos HttpSession deben tener un ámbito en el nivel de aplicación (o contexto de servlet). El mecanismo subyacente, como la cookie utilizada para establecer la sesión, puede ser el mismo para diferentes contextos, pero el objeto al que se hace referencia, incluidos los atributos en ese objeto, nunca debe ser compartido entre contextos por el contenedor.

( Servlet 2.4 especificación )

Actualización: Cada llamada a la página JSP crea implícitamente una nueva sesión si todavía no hay sesión. Esto se puede desactivar con la directiva de la session=''false'' , en cuyo caso la variable de sesión no está disponible en la página JSP.


Para los enlaces generados en un JSP con etiquetas personalizadas, tuve que usar

<%@ page session="false" %>

en el JSP

Y

request.getSession().invalidate();

en la acción Struts