session - Sesiones ColdFusion vs sesiones J2EE
java-ee (4)
Las sesiones nativas de CF no usan cookies de sesión, por lo que pueden durar en reinicios de navegador / máquina, mientras que todos los servidores Java EE usan cookies de sesión de forma predeterminada, por lo que su sesión solo puede durar mientras su navegador esté abierto.
No puedo encontrar dónde se especifica este comportamiento en Servlet JSR, pero en Servlet Spec 3.0 (es decir, no JRun), puede establecer una fecha de caducidad para su cookie de sesión Java EE con el fin de imitar el comportamiento de la sesión nativa CF.
Como se menciona en nosilleg, esto podría ser una ventaja, pero también podría considerarse un problema de seguridad, según los requisitos de seguridad de la aplicación en la que esté trabajando.
¿Hay algún beneficio para las sesiones de ColdFusion frente a las sesiones de J2EE?
La documentación de la sesión de ColdFusion menciona los beneficios de las sesiones de J2EE, pero no las ventajas de las sesiones de ColdFusion. Las sesiones J2EE han estado disponibles desde ColdFusion MX (lanzado en 2002), pero todavía hay mucha gente que usa sesiones estándar de ColdFusion. ¿Hay alguna desventaja de las sesiones J2EE que no están presentes con las sesiones de ColdFusion?
La administración de sesión J2EE proporciona las siguientes ventajas sobre la administración de sesión de ColdFusion:
- La gestión de sesiones J2EE utiliza un identificador de sesión específico de la sesión,
jsessionid, que se crea de nuevo al inicio de cada sesión.- Puede compartir variables de sesión entre páginas de ColdFusion y páginas JSP o servlets de Java a los que llame desde las páginas de ColdFusion.
- El alcance de la sesión es serializable (convertible en una secuencia de bytes que luego puede restaurarse completamente en el objeto original). Con la administración de la sesión de ColdFusion, el alcance de la sesión no es serializable. Solo los ámbitos serializables se pueden compartir entre servidores.
Por lo tanto, considere usar la administración de sesión J2EE en cualquiera de los siguientes casos:
- Desea maximizar la seguridad de la sesión, particularmente si también usa variables de cliente
- Desea compartir variables de sesión entre páginas de ColdFusion y páginas JSP o servlets en una sola aplicación.
- Desea poder terminar una sesión manualmente mientras mantiene la cookie de identificación del cliente para que sea utilizada por el alcance del Cliente.
- Desea admitir sesiones en clúster; por ejemplo, para admitir el failover de sesión entre servidores.
No existen desventajas serias al usar cookies de sesión Java EE, y hay algunas ventajas de usarlas, como se indicó anteriormente en su pregunta.
La única desventaja de los tokens Java EE es que las cookies no se pueden modificar fácilmente mediante programación. CF Tokens puede. Puede modificar los tokens de CF para que sean solo sesión. También puede modificarlos para que sean solo SSL y httpOnly.
Puede hacer tokens Java EE solo SSL y también httpOnly, pero implica argumentos JVM.
En CF9, Adobe también mejoró la aleatoriedad de los tokens de CF para estar más a la par con los tokens de Java EE.
Realmente no creo que importe cuál usas (suponiendo que estés en CF9 o superior). Pero los tokens de Java EE son los más cercanos a trabajar de forma segura listos para usar. Pero si quiere ir más allá de simplemente configurar las cookies para "solo sesión" y hacer que sean solo SSL y httpOnly, tendrá que profundizar en la configuración de JVM. No puedes hacer eso en tu App.cfc.
Una de las principales desventajas de las variables de sesión J2EE en ColdFusion es que los cambios, como hacer que sean cookies "seguras", tienen lugar en una instancia amplia.
Esto significa que cada sitio que se ejecuta en esa instancia debe ejecutarse bajo https, incluido el propio administrador de ColdFusion. Para los servidores que alojan varios sitios que requieren sesiones, esto generalmente será problemático. Además, si está ejecutando el Administrador de ColdFusion desde el servidor web incorporado, hay un poco de un proceso para que funcione en SSL.
Si necesita las ventajas documentadas de las cookies J2EE, y necesita que la cookie sea segura, todos los sitios que requieren sesiones deben estar en https.
Si no necesita ninguna de las ventajas documentadas de las cookies J2EE, y está ejecutando CF9 o posterior, entonces es mejor que vaya con las cookies de ColdFusion.
Tenga en cuenta que Railo todavía tiene el mismo problema pero con más flexibilidad ya que la etiqueta cfapplication tiene un atributo de tipo sessiontype donde puede elegir entre las cookies de sesión j2ee o cf por sitio.
Tuve un pequeño problema en el que perdí completamente las variables de sesión entre las solicitudes. Estaba usando una publicación cfhttp con sesiones J2EE. Imagine este escenario: 1. call.cfm en la carpeta wwwRoot / test hace una llamada a una página de índice también en la misma carpeta. 2. index.cfm envía la solicitud a wwwRoot / test / controller / login.cfm. 3. login.cfm establece algunas variables de sesión y envía al usuario a wwwRoot / test / index.cfm 4. index.cfm no ve las variables de sesión creadas.
Todas las solicitudes de envío se realizan a través de la localización con addtoken = "yes".
Desactiva las variables de sesión J2EE y viola! Funciona exactamente como debería.