6

Estoy intentando que Tuckey UrlRewriteFilter ponga en orden las URL de mi aplicación web. Un problema que tengo es que cuando Spring-Security advierte que un usuario anónimo está intentando acceder a un recurso protegido, lo redirige a una URL que incluye la ruta del servlet.Reescriba las URL de redireccionamiento de seguridad de primavera

Lo que me gustaría es, por ejemplo:

> GET http://localhost:8080/my-context/protected-resource 
< Location: http://localhost:8080/my-context/login 

Lo que actualmente me sale es:

documentos
> GET http://localhost:8080/my-context/protected-resource 
< Location: http://localhost:8080/my-context/-/login 

relevantes que he encontrado hasta ahora:

DefaultRedirectStrategy, que hace la redirección real en cuestión: http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/DefaultRedirectStrategy.html. Tiene una propiedad contextRelative que es tentadora, pero no creo que la corte, si es que puedo encontrar una manera de configurarla.

un blog que me ayudó a conseguir hasta aquí: http://nonrepeatable.blogspot.com/2009/11/using-spring-security-with-tuckey.html

Lo que me gustaría saber es:

  1. puede/debería convencer a Tuckey para reescribir la cabecera Location. < regla de salida > no parece ayudar a ninguno aquí.
  2. Puedo/debería de alguna manera ajustar la configuración SS para emitir la URL reescrita. No creo que esto sea tan ordenado, ya que se rompería si la reescritura estuviera desactivada.

web.xml parece

<filter> 
    <filter-name>UrlRewriteFilter</filter-name> 
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class> 
    <init-param> 
     <param-name>LogLevel</param-name> 
     <param-value>log4j</param-value> 
    </init-param> 
</filter> 
<filter-mapping> 
    <filter-name>UrlRewriteFilter</filter-name> 
    <url-pattern>/*</url-pattern> 
    <dispatcher>REQUEST</dispatcher> 
</filter-mapping> 

<filter> 
    <filter-name>springSecurityFilterChain</filter-name> 
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> 
</filter> 
<filter-mapping> 
    <filter-name>springSecurityFilterChain</filter-name> 
    <url-pattern>/*</url-pattern> 
    <dispatcher>REQUEST</dispatcher> 
    <dispatcher>FORWARD</dispatcher> 
    <dispatcher>INCLUDE</dispatcher> 
    <dispatcher>ERROR</dispatcher> 
</filter-mapping> 

<servlet> 
    <servlet-name>my-servlet</servlet-name> 
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
    <load-on-startup>1</load-on-startup> 
</servlet> 
<servlet-mapping> 
    <servlet-name>psms</servlet-name> 
    <url-pattern>/-/*</url-pattern> 
</servlet-mapping> 

urlrewrite.xml parece:

<urlrewrite> 
    <rule> 
     <from>^/(.*)$</from> 
     <to>/-/$1</to> 
    </rule> 
</urlrewrite> 

applicationContent-security.xml parece:

<http auto-config="true"> 
    <!-- allow GET requests to /login without authentication --> 
    <intercept-url pattern="/-/login" method="GET" filters="none"/> 

    <intercept-url pattern="/-/admin/**" access="ROLE_ADMIN"/> 
    <intercept-url pattern="/-/**" access="ROLE_USER"/> 

    <form-login login-page="/-/login" 
       login-processing-url="/-/login.do" 
       authentication-failure-url="/-/login?login_error" 
       default-target-url="/-/index" 
       always-use-default-target="true"/> 

    <logout logout-url="/-/logout" 
      logout-success-url="/-/login"/> 

    <access-denied-handler error-page="/-/access-denied"/> 
</http> 
+0

y configurando el atributo de la página de inicio de sesión/iniciar sesión? – rodrigoap

Respuesta

0

Me'v nunca usó Tuckey, pero después de un rápido vistazo en el docum entación Me gustaría tratar de añadir una regla para el caso de inicio de sesión:

<urlrewrite> 
    <rule> 
     <from>^/my-context/login$</from> 
     <to>/my-context/login</to> 
    </rule> 
    <rule> 
     <from>^/(.*)$</from> 
     <to>/-/$1</to> 
    </rule> 
</urlrewrite> 

EDITAR
Ok, y algo parecido a esto:

<urlrewrite> 
    <rule> 
     <from>^/-/login$</from> 
     <to>/login</to> 
    </rule> 
    <rule> 
     <from>^/(.*)$</from> 
     <to>/-/$1</to> 
    </rule> 
</urlrewrite> 
+2

El problema no es que las solicitudes entrantes no se reescriban, sino que los encabezados de ubicación salientes como parte de una redirección no se vuelven a escribir. Desde entonces he descubierto que una regla de salida con el protocolo completo, host, puerto, contexto, etc. captará el encabezado de la ubicación, pero tampoco es genial. – ptomli

2

Miré en este tema para nuestro proyecto el año pasado y por lo esa vez el problema era que Tucky no estaba cooperando con response.encodeRedirectUrl() para reescribir las URL de redireccionamiento. Me puse en contacto con ellos, pero no he seguido sobre esto.

Mi solución fue permitir que la URL desordenada volviera al cliente pero luego limpiarla con una regla de redireccionamiento de Tucky (una segunda redirección).

por lo que añadir otra regla que coincide con su fea URL de la redirección de seguridad y emitir su propio redirección a la URL limpia:

<rule> 
    <from>^/whatever/ugly.*$</from> 
    <to type="redirect">/login</to> 
</rule> 

Sí, se trata de dos redirecciones, pero el cliente nunca lo verá .. . que es probablemente el punto.

1

seguridad Primavera está haciendo la redirección de una URL absoluta como http://example.org/-/login

intenta utilizar un saliente en reglas sin el marcador ^ start of string para que coincida con la URL absoluta generada por el resorte.

<outbound-rule> 
    <from>/-/login(.*)$</from> 
    <to>/login$1</to> 
</outbound-rule>  
1

Me encontré con el mismo problema, pero parece arreglado en la versión 3.2.0 de Tuckey. es decir, response.encodeRedirectUrl() ahora está envuelto por Tuckeys UrlRewriteWrappedResponse donde tiene lugar la ejecución de la regla de salida.

Cuestiones relacionadas