sesion - session java
La mejor opción para la gestión de sesiones en Java (6)
La mejor forma de administrar la sesión en Java. Escuché que las cookies no son una opción confiable para esto, ya que se almacenan en el navegador y se puede acceder más adelante. ¿Es esto correcto? Si es posible, presente las respuestas con el ejemplo de codificación.
Cuál es el mejor entre:
- Reescritura de URL : el servidor agregará un parámetro adicional al final del enlace URL
- Parámetro oculto en Formulario : el servidor agregará un parámetro adicional en cada formulario en HTML
- cookie : el servidor le pedirá al navegador que mantenga una cookie.
2 preguntas importantes:
¿Qué tecnología web estás usando? JSF, Struts, SpringMVC o simplemente servlets / JSPs.
Los servlets / JSP ya le brindan el soporte de sesión que necesita.
Ejemplo de JSP:Hello, <%= session.getAttribute( "theName" ) %>Realmente no creo que tengas algo de qué preocuparte sobre las cookies, ya que los datos se almacenan de forma segura en el servidor y la manipulación de la cookie se realiza de forma automática.
¿Tu aplicación está instalada en un solo servidor?
Si es SÍ que no tiene ningún problema, use la opción de sesión servlet.
si NO tienes que encontrar otra forma de hacerlo. Como usar una sesión fija, o tal vez analizar todo el objeto de la sesión en las solicitudes / respuestas como un campo. Esta opción de hecho requiere que tome medidas de seguridad.
Http es un protocolo de extracción sin estado, del lado del cliente.
Para implementar una conversación con estado sobre él, Java EE Web Server necesita ocultar cierta información (que es sessionid) en el lado del cliente y el mecanismo que puede usar debe seguir las especificaciones HTTP y HTML.
Hay tres formas de lograr este objetivo:
- Reescritura de URL : el servidor agregará un parámetro adicional al final del enlace URL.
- Parámetro oculto en Formulario : el servidor agregará un parámetro adicional en cada formulario en HTML.
- cookie : el servidor le pedirá al navegador que mantenga una cookie.
Básicamente, el servidor web moderno tendrá un "filtro" para elegir qué camino usar automáticamente.
Entonces, si el Servidor detectó que el navegador ya desactivó el soporte de cookies, cambiará a otras formas.
La cookie simplemente almacena la identificación de la sesión, esta ID es inútil una vez que la sesión ha expirado.
Todos los frameworks web de Java admiten cookies o ID de sesión con codificación URL. Elegirán el enfoque correcto automáticamente, por lo que no hay nada que deba hacer. Simplemente solicite el objeto de sesión desde su contenedor y se encargará de los detalles.
[EDIT] Hay dos opciones: Cookies y una URL especial. Hay problemas con ambos enfoques. Por ejemplo, si codifica la sesión en una URL, las personas pueden intentar pasar la sesión (por ejemplo, colocando la URL en un correo). Si quieres entender esto, lee un par de artículos sobre seguridad y crea servidores de aplicaciones. De lo contrario: su servidor de aplicaciones Java hará lo correcto para usted. No lo pienses
La especificación del servlet define la API para acceder / configurar datos de sesión en la aplicación J2EE estándar. También define que los datos de la sesión se almacenan en el lado del servidor y no se transfiere nada al cliente, excepto el identificador de la sesión. Hay 2 mecanismos de cómo se transfiere la identificación de la sesión:
1) solicitud de URL, por ejemplo, jessionid = ....
2) galleta
El mecanismo se determina automáticamente en función de las capacidades del cliente.
EDITAR No existe la mejor opción, hay una especificación de servlet que define el camino.
La administración de la sesión (identificación del cliente, manejo de cookies, datos del ámbito de la sesión de guardado, etc.) básicamente ya la realiza el propio servidor de aplicaciones. No necesita preocuparse por eso en absoluto. Puede establecer / obtener objetos Java en la sesión mediante HttpSession#setAttribute() y #getAttribute() . Lo único que realmente debe cuidar es la reescritura de URL para el caso de que el cliente no admita cookies. A continuación, agregará un identificador jsessionid a la URL. En el JSP puede usar la c:url JSTL para esto. En el Servlet puede usar HttpServletResponse#encodeURL() para esto. De esta forma, el servidor puede identificar al cliente leyendo la nueva URL de solicitud.
Su nueva pregunta probablemente sea "¿Pero cómo están relacionadas las cookies con esto? ¿Cómo lo hace todo el servidor?". Bueno, la respuesta es esta: si el servidor recibe una solicitud de un cliente y el código del lado del servidor (su código) está tratando de obtener la HttpSession por HttpServletRequest#getSession() mientras que todavía no hay una creada (primera solicitud en una nueva sesión ), el servidor creará uno nuevo en sí mismo. El servidor generará una ID larga, única y difícil de adivinar (la que puede obtener mediante HttpSession#getId() ) y establecerá esta ID como un valor de la cookie con el nombre jsessionid . Debajo del capó, el servidor usa HttpServletResponse#addCookie() para esto. Finalmente, el servidor almacenará todas las sesiones en algún tipo de Map con la ID de sesión como clave y la HttpSession como valor.
De acuerdo con la especificación de cookies HTTP, el cliente debe enviar las mismas cookies en los encabezados de la solicitud subsiguiente. Debajo del capó, el servidor buscará la cookie jsessionid mediante HttpServletRequest#getCookies() y determinará su valor. De esta forma, el servidor puede obtener la HttpSession asociada y devolverla mediante cada llamada en HttpServletRequest#getSession() .
Al grano: lo único que se almacena en el lado del cliente es la ID de la sesión (en el sabor de una cookie) y el objeto HttpSession (incluidos todos sus atributos) se almacena en el lado del servidor (en la memoria de Java). No necesita preocuparse por la administración de la sesión usted mismo y tampoco tiene que preocuparse por la seguridad.