tomcat - jkworkersfile - mod_jk download

Mezcla de sesiones-apache httpd con mod_jk, tomcat, seguridad de primavera-que sirve datos de otros usuarios

Question

Recientemente nos enfrentamos a un problema grave, que un usuario recibió datos de otro usuario. Este problema es casi imposible de reproducir.

Estamos usando la administración estándar de usuarios registrados provista por Spring-security, y estamos seguros de que el problema no está en almacenar al usuario en variables de instancia o cosas similares de simultaneidad en nuestra aplicación.

Realmente dudamos de que el problema esté en SpringSecurity o Tomcat.

Nuestro servidor frontal es Apache httpd, conectado a tomcat mediante el conector ajp (mod_jk). No estamos haciendo ningún equilibrio de carga (httpd se preocupa por SSL, algunas reescrituras de URL y sirve algunos módulos de php)

Aquí está nuestra configuración:

## OS
OS Name:        Linux 
OS Version:     2.6.32-5-686
Architecture:   i386

## Apache httpd
Server version: Apache/2.2.16 (Debian)
Server built:   Sep  4 2011 20:27:42

## mod_jk
mod_jk/1.2.30 (installed via apt-get)

## JVM
JVM Version:    1.6.0_18-b18
JVM Vendor:     Sun Microsystems Inc.

## Tomcat
Server version: Apache Tomcat/6.0.28
Server built:   February 12 2011 1443

Culpamos a httpd / mod_jk de esta mezcla de sesiones por lo que nuestra única solución sería eliminar apache httpd. Pero antes de abandonar esta configuración popular y ampliamente utilizada, nos gustaría saber si alguien ha enfrentado el problema similar.

Los únicos problemas similares que he encontrado fueron en balanceo de carga o mod_jk.

¿Alguna vez has enfrentado algún problema similar? Cualquier sugerencia, idea, enlace o experiencia será muy apreciada. ¡Gracias!

Answer 1

Si excluye el problema de la sesión concurrente, la única posibilidad es que la lógica de su negocio sea defectuosa y sirva los datos de otro usuario. Por favor, publique muestras de código de cómo se determina el ''usuario actual'' y luego se usa.

EDITAR: los errores que se manifiestan solo en la producción a menudo son causados ​​por las condiciones de la raza ( http://en.wikipedia.org/wiki/Race_condition ). Asegúrese de que su código utilice variables locales siempre que sea posible, y emplee bloqueo / sincronización cuando corresponda.

Answer 2

Uno de los posibles problemas puede ser un segundo intento de inicio de sesión. Considera seguir el caso:

• El usuario abre dos pestañas del navegador con dos formas de inicio de sesión.
• Pestaña 1: inicie sesión como usuario_1. Cargue algunos datos en la sesión HTTP.
• Pestaña 2: inicie sesión como usuario_2. Cargue algunos datos en la sesión HTTP.

En la mayoría de los navegadores será la misma sesión HTTP. Entonces en realidad tendrá datos de user_1 y user_2 combinados en una sesión HTTP. Cualquier página que use objetos de sesión puede verse afectada.

Tienes dos opciones aquí:

• Prevenir esta situación Detecte el segundo intento de inicio de sesión y solicite al usuario que cierre la sesión primero. Es fácil con Spring Security, vea el código a continuación.
• Si necesita absolutamente una cuenta por pestaña del navegador, puede almacenar sus datos de sesión en un mapa por nombre de usuario.

Puede evitar el segundo intento de inicio de sesión gracias al contenido de Control de sesión simultánea:

<http>
    ...
    <session-management>
        <concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />
    </session-management>
</http>

¿Ya está hecho en tu aplicación?

Answer 3

Hasta el momento no hemos podido reproducir el error, pero hemos descubierto que algunas personas enfrentan el mismo problema con mod_jk:

• https://issues.apache.org/bugzilla/show_bug.cgi?id=47714
• http://grails.1312388.n4.nabble.com/Spring-Security-after-log-in-user-changed-and-session-mixed-up-td4636714.html (en la parte inferior)

Entonces ahora estamos ejecutando con esta configuración:

• JkOptions DisableReuse: http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
• reintentos de trabajo = 0: http://tomcat.apache.org/connectors-doc/reference/workers.html#Advanced Worker Directives

Y estamos planeando cambiar mod_jk por mod_proxy_http.

Dejo esta pregunta sin respuesta, porque no puedo asegurar (y nadie que tenga el mismo problema pueda asegurar) que la solución corrige el error.

Si alguien pudiera compartir cualquier información, ¡apreciaría mucho! Gracias.

Answer 4

He encontrado el mismo problema con Glassfish 3.1.2.2 y Mod_JK 1.2.19

Puede reproducir el error con un script JMeter y una buena afirmación.

Aquí está la entrada de mi blog contando la historia: http://jeecookbook.blogspot.com/2013/07/modjk-session-mixed-between-users.html

El uso de Mod_proxy con esta afirmación resuelve el problema: no se detecta más mezcla.

Answer 5

Cuando se integran JSF y Spring, la inyección de dependencias JSF entra en conflicto con la inyección de dependencia de Spring, por lo que Spring reescribió el módulo JSF que maneja eso para simplemente ajustar Spring DI en su lugar. Entonces, cuando declaro un JSF ManagedBean como Session Scoped, también debo darle una anotación @Controller para que también se reconozca como Spring Bean.

Para obtener más información, vea esto.