UrlRewriteFilter Directo a https

Question

Estoy usando UrlRewriteFilter para redirigirme a SSL. Estoy ejecutando Glassfishv2.

Mi regla se ve más o menos así ahora. Está en mi urlrewrite.xml en WEB-INF de mi carpeta war. ¿Hay alguna otra configuración de Glassfish que deba establecerse?

<rule> 
     <condition name="host" operator="notequal">https://abc.def.com</condition> 
    <condition name="host" operator="notequal">^$</condition> 
    <from>^/(.*)</from> 
    <to type="permanent-redirect" last="true">https://abc.def.com/ghi/$1</to> 
    </rule> 

Pero FF sigue diciendo que la regla de URL de redireccionamiento es de una manera que nunca se completará. No estoy exactamente seguro de lo que está pasando aquí. ¿algunas ideas?

Answer 1

Sospecho que el problema es que el valor del encabezado host (con el que compara) no contiene el esquema utilizado para acceder al recurso, donde su valor de comparación sí lo hace. Esto significa que la condición siempre es verdadera, porque el host nunca es igual a lo que está comparando, lo que lleva a un bucle de redirección infinita.

En cuanto a la documentación de UrlRewriteFilter, usted debería ser capaz de hacer algo como esto para conseguir lo que quiere:

<rule> 
    <condition type="scheme" operator="notequal">https</condition> 
    <condition name="host" operator="equal">abc.def.com</condition> 
    <from>^/(.*)</from> 
    <to type="permanent-redirect" last="true">https://abc.def.com/ghi/$1</to> 
</rule> 

Answer 2

El valor del nombre de host especificado en la URL regla de reescritura no puede incluir el esquema. UrlRewriteFilter usa internamente los métodos de API de servlet para determinar el nombre de host, a través de request.getServerName(); esta llamada al método nunca devuelve el esquema, por lo que es mejor realizar la validación del esquema por separado (como lo ha implicado Tim).

Si observa que hay otros métodos disponibles, la validación del esquema debe hacerse por separado, ya que el esquema solo está disponible mediante el método request.getScheme() en la API, que se expone por separado a través de UrlRewriteFilter.

La razón real de por qué FF informa el error en la redirección probablemente se deba a que se enviaron múltiples 302 al cliente, para la solicitud original (y las solicitudes posteriores realizadas por el cliente). Es posible que desee supervisar el tráfico HTTP para determinar si hay una regla presente cuando la redirección HTTPS falla, en la causa real del comportamiento en su aplicación.

EDIT:

Si es posible, se puede investigar el uso del elemento CONFIDENCIAL transport guarantee en web.xml para asegurarse de que las fuerzas contenedor de servlets todas las peticiones HTTP que se realicen a través de SSL.

Answer 3

No estoy exactamente seguro de lo que está mal con su ejemplo anterior, pero esta es una de esas preciosas problemas que pueden resolverse fácilmente utilizando OCPsoft reescritura, otro de código abierto URLRewriteFilter:

@Override 
public Configuration getConfiguration(final ServletContext context) 
{ 

    return ConfigurationBuilder.begin() 
    .defineRule() 

    .when(Direction.isInbound() 
     .and(Domain.matches("abc.def.com")) 
     .and(Path.matches("/{path}").where("path").matches(".*")) 
     .andNot(Scheme.matches("https")) 
    .perform(Redirect.to("https://abc.def.com/{path}")); 

} 

El Scheme objeto está disponible desde Rewrite versión 1.0.1: http://ocpsoft.org/rewrite/