2012-06-05 19 views
6

Desarrollo de aplicaciones web en Java EE con JSF. Todas las páginas están protegidas de la visualización por formulario de autenticación con la acción 'j_security_check' y las entradas 'j_username' y 'j_password'.Redirección incorrecta después de iniciar sesión (Java EE w/JSF)

Después de registro de éxito en, sin embargo, no estoy redirigido a la página que quería acceder a esta URL, pero

/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development 

Así que estoy mirando las jsf.js archivo de script con todo el código JS en lugar de la página que quería ver No importa si accedo a la raíz web o a cualquier otra página, siempre se me redirige a esta URL. Luego cambio la URL a cualquier página, la carga bien y estoy conectado.

Tengo que decir que ya tuve este problema que mágicamente desapareció, así que me redirigió correctamente. Después de algunas semanas se rompió nuevamente pero no lo hago si fue mi culpa, y si lo fue, no sé la causa. No estaba jugando con las reglas de redireccionamiento o navegación en absoluto.

Es bueno mencionar que también estoy usando PrettyFaces.

EDIT:

<security-constraint> 
    <display-name>secured</display-name> 
    <web-resource-collection> 
     <web-resource-name>all</web-resource-name> 
     <description/> 
     <url-pattern>/*</url-pattern> 
    </web-resource-collection> 
    <auth-constraint> 
     <description/> 
     <role-name>admin</role-name> 
     <role-name>teacher</role-name> 
    </auth-constraint> 
</security-constraint> 
<security-constraint> 
    <display-name>secured for admins</display-name> 
    <web-resource-collection> 
     <web-resource-name>admin pages</web-resource-name> 
     <description/> 
     <url-pattern>/admin/*</url-pattern> 
    </web-resource-collection> 
    <auth-constraint> 
     <description/> 
     <role-name>admin</role-name> 
    </auth-constraint> 
</security-constraint> 
<security-constraint> 
    <display-name>unsecured</display-name> 
    <web-resource-collection> 
     <web-resource-name>css</web-resource-name> 
     <description/> 
     <url-pattern>/css/*</url-pattern> 
    </web-resource-collection> 
    <web-resource-collection> 
     <web-resource-name>js</web-resource-name> 
     <description/> 
     <url-pattern>/js/*</url-pattern> 
    </web-resource-collection> 
    <web-resource-collection> 
     <web-resource-name>img</web-resource-name> 
     <description/> 
     <url-pattern>/img/*</url-pattern> 
    </web-resource-collection> 
</security-constraint> 
<login-config> 
    <auth-method>FORM</auth-method> 
    <realm-name>wetk-security</realm-name> 
    <form-login-config> 
     <form-login-page>/faces/login.xhtml</form-login-page> 
     <form-error-page>/faces/login.xhtml</form-error-page> 
    </form-login-config> 
</login-config> 
+0

¿Qué hay en los elementos '' del archivo 'web.xml'? –

+0

Editado la pregunta. – redhead

Respuesta

8

El contenedor de seguridad administrada redirigirá a la última solicitud HTTP que desencadenó la comprobación de autenticación. En su caso, aparentemente es el archivo JSF ajax API JavaScript incluido automáticamente. Eso puede suceder si el navegador ha cargado la página a ser autenticada completamente desde la memoria caché del navegador, mientras que el navegador ha cargado completamente el archivo JS desde el servidor, o ha probado la validez de caché del archivo JavaScript mediante una solicitud GET condicional .

Usted desea excluir los recursos JSF (<h:outputScript>, <h:outputStylesheet> y <h:graphicImage> de comprobaciones de autenticación. Usted podría hacer que al excluir el patrón común URL /javax.faces.resource/*. Es posible que sólo desee agregar el patrón /faces prefijo que estás aparentemente usarlo en lugar del patrón de *.xhtml sufijo.

también es necesario indicar al navegador que no páginas restringido el caché para evitar que el navegador carga desde la memoria caché (por ejemplo, presionando el botón después de cerrar la sesión posterior). Asignar el siguiente filtro en el mismo patrón de URL que el de su <security-constraint>.

@WebFilter("/secured/*") // Use the same URL pattern as <security-constraint> 
public class NoCacheFilter implements Filter { 

    @Override 
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { 
     HttpServletRequest httpReq = (HttpServletRequest) request; 
     HttpServletResponse httpRes = (HttpServletResponse) response; 

     if (!httpReq.getRequestURI().startsWith(httpReq.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER)) { // Skip JSF resources (CSS/JS/Images/etc) 
      httpRes.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. 
      httpRes.setHeader("Pragma", "no-cache"); // HTTP 1.0. 
      httpRes.setDateHeader("Expires", 0); // Proxies. 
     } 

     chain.doFilter(request, response); 
    } 

    // ... 
} 
+0

Así que probé su código y en el proceso de inicio de sesión (la primera solicitud y luego de enviar el formulario) el filtro nunca recibe la página solicitada. Solo lo recibe cuando cambio la URL nuevamente. Entonces, no volviendo a funcionar, aún veo el guión de JS. – redhead

+0

¿Borró la memoria caché del navegador antes de probar? – BalusC

+0

Probé una Opera completamente borrada pero sin cambios. – redhead

Cuestiones relacionadas