Barrapunto

En fin, llevo pocas entradas en mi bitacora y esta va a ser la primera en que pido ayuda...

vamos a ver, estoy arreglando bugs en una simple aplicacion web hecha en java, lo tipico, struts+jsp+oracle, tan simple y sencilla que ni siquiera necesita ejbs ni nada parecido, vamos, ningun problema

el caso es que el cenutrio (no tengo otro nombre para el) que construyo esto tenia una forma mas bien extrania de programar, mezcla de chapuzas impresionantes (como por ejemplo tres bucles anidados para parsear un ResultSet y dejarlo *tal y como estaba* en la bbdd) y mezcla de ejemplos copiados, literalmente, de varios tutoriales de internet (no es conia, con comentarios, nombres de variable y todo!!), asi que parte de mi trabajo ahora es ir arreglando lo que este hombre dejo cuando se fue de la empresa

asi que tengo una aplicacion web sencilla, que se ejecuta sobre un jboss 3.2.3 y usa un LDAP para la autenticacion, que se hace con un formulario de html, dicho formulario redirige a un servlet interno de tomcat (o jboss, no estoy muy seguro) llamado j_security_check al que se le pasan dos parametros (j_username y j_password) y que hace la autenticacion de acuerdo a una configuracion en el fichero login-conf.xml de jboss donde se indica como acceder al LDAP, como identificar al usuario, sus roles, etc, etc...

en fin, para el que tenga curiosidad, todo esto tiene pinta de estar sacado de este articulo (hasta la ultima coma), lo encontre metiendo trozos de codigo en google...

el caso es que la cosa funciona, mas o menos: el usuario accede a la pagina de login, mete su usuario y contrasenia, le da a submit y...

sale un bonito error 404 diciendo que no ha podido acceder a http://<nombredelamaquina>/<nombredelaaplicacion>/ j_security_check

cosa que no deberia pasar, pues la autenticacion, llegado ese punto, ha funcionado, si se da a la flecha de atras y se recarga la pagina, el usuario aparece como autenticado, asi que el proceso ha llegado al servlet, le ha mandado los parametros correctamente, ha hecho la busqueda en el LDAP y ha vuelto a la aplicacion con los datos necesarios...

lo mas cachondo del tema es que la incidencia que habla de este problema esta abierta por este mismo tipo y es del mismo dia en que introdujo la pagina de login en el clearcase que usamos para repositorio de codigo, es decir, que cuando lo hizo ya sabia que la cosa fallaba y decidio que mejor se encargaba otro!

asi pues, alguien me puede explicar que esta pasando?

llevo un dia buscando por inet y no encuentro nada definitivo sobre el tema (salvo comentarios de gente preguntando porque les falla y respuestas que no me aclaran nada), lo que mas me escama es que, aunque hay un sitio donde se dice a que pagina tiene que ir para hacer login, no se define en ningun lado lo que se debe de hacer una vez el usuario se haya identificado con exito

estoy por quitar todo esto y hacerlo a mano, es decir, eliminar la llamada a j_security_check, implementar una accion de struts que se encargue de ello y que llame a un modulo JAAS pasandole los parametros que necesite, pero me gustaria, antes de seguir ese camino, entender por que este sistema no funciona y si se me esta escapando algo, por lo que he estado viendo, es un sistema de autenticacion definida en la especificacion de los servlets y que parece estandar (aunque yo nunca lo habia usado)

cualquier comentario sobre el tema es bienvenido...

Editando: gracias a un comentario de un PH (gracias!;D) parece que esto ya funciona... tal y como dice en su comentario, este es un sistema para proteger el acceso a recursos, es decir, un sistema de autorizacion, no para hacer la autenticacion de la aplicacion per se (eso se pdria considerar una ventaja aniadida), asi que con algo tan sencillo como cambiar la pagina de entrada a la aplicacion por un recurso protegido (en mi caso una pagina con las acciones que se pueden realizar en la aplicacion), el login aparece y permite entrar al usuario sin problemas

todavia me queda cambiar ciertos detalles menores, pero, al menos, esto ya funciona...

por cierto, gracias tambien a ti, chavi, el link es muy interesante y lo he guardado en marcadores para leermelo luego con tranquilidad y aprender algo mas de este tema
por lo que he leido, en este caso es tomcat el que se encarga de la llamada al servlet, pero a su vez este llama al sistema de seguridad de jboss, al parecer, aunque el tema del j_security_check es estandar, en la especificacion se deja bastante libertad a los fabricantes a la hora de implementarlo, asi que tanto el servidor de sun como weblogic como tomcat lo hacen de forma diferente, segun he leido, en weblogic se podria usar esta herramienta como se pretendia aqui, usando extensiones propietarias de este servidor.

dejo tambien aqui algunos links que pueden ser interesantes para entender todo esto:
- Documentacion del framework de seguridad de jBoss (JBossSX)
- Un articulo de javaworld que explica bastante bien como funciona este sistema
- Documentacion y tutoriales sobre JAAS en Sun

Editando 2: probando estas cosas, me he vuelto a encontrar con otro problema: los usuarios
efectivamente si intentas acceder a un recurso protegido, saldra la pagina de login y todo ira como la seda, pero, que pasa si accedes directamente a la pagina de login? por ejemplo, metiendo en favoritos el link? me juego la cabeza a que la mayor parte de los usuarios lo tienen hecho asi, y, efectivamente, vuelve a fallar...

lo malo es que si les paso el link nuevo, al meterlo les redirigira a la misma pagina de login y la volveran a meter en favoritos (si no es ahora, sera dentro de una semana), asi que le estoy dando vueltas a una solucion definitiva, de momento he puesto en el jsp de login este codigo:

<%
if (request.getSession().isNew())
    response.sendRedirect("../index.jsp");
%>

si, lo se, no es muy elegante, no sigue lo de los jsp modelo 2, pero funciona (en todas las pruebas y configuraciones que he probado hasta ahora)

la idea es que si accede directamente a la pagina de login, la sesion sera nueva, asi que le redirigira al index que al ser un recurso protegido, les mandara otra vez al login, es mucha vuelta pero el usuario no ve nada de esto
si el usuario es bueno, decente y hace las cosas como debe, intentara ir a la pagina de index de buenas a primeras, que le mandara al login, en ese caso la sesion no sera nueva asi que para el no habra ninguna diferencia ni tendra que dar mas vueltas...

algun comentario sobre esto?

creo que acabo de inventar la programacion orientada a la burocracia ("no, sin el formulario A-45 no le podemos atender")...