CODEWITHSUNDEEP
javaglassfishurl-rewriting
adi
adi

Reputation: 71

UrlRewriteFilter Direct to https

I am using UrlRewriteFilter to redirect to SSL. I am running Glassfishv2.

My rule looks something like this now. It's in my urlrewrite.xml in WEB-INF of my war folder. Is there any other glassfish setting that needs to be set?

<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>

But FF keeps saying that the URL redirect rule is in a way that it will never complete. I am not exactly sure whats happening here. any ideas?

Upvotes: 7

Views: 7419

Answers (3)

Lincoln
Lincoln

Reputation: 3191

I'm not exactly sure what is wrong with your example above, but this is one of those lovely problems that can be easily solved using OCPsoft rewrite, another open-source 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}"));

}

The Scheme object is available as of Rewrite version 1.0.1: http://ocpsoft.org/rewrite/

Upvotes: 0

Vineet Reynolds
Vineet Reynolds

Reputation: 76709

The value of the hostname specified in the url rewriting rule cannot include the scheme. UrlRewriteFilter internally uses the Servlet API methods to determine the hostname, via request.getServerName(); this method call never returns the scheme, so you're better of performing the scheme validation separately (as Tim has implied).

If you notice the other methods available, scheme validation has to be done separately, since the scheme is made available only via the request.getScheme() method in the API, which is exposed separately via UrlRewriteFilter.

The real reason on why FF reports the error in redirection is probably due to multiple 302s being sent back to the client, for the original request (and the subsequent requests made by the client). You might want to monitor the HTTP traffic to determine if there is a rule that is present when the HTTPS redirection fails, on the actual cause of the behavior in your application.

EDIT:

If possible, you can investigate the use of the CONFIDENTIAL transport guarantee element in web.xml to ensure that the servlet container forces all HTTP requests to be made over SSL.

Upvotes: 0

Tim Stone
Tim Stone

Reputation: 19169

I suspect the problem is that the value of the host header (which you're comparing against) does not contain the scheme used to access the resource, where your comparison value does. This means that the condition is always true, because the host never equals what you're comparing it to, leading to an infinite redirect loop.

Looking at the documentation for UrlRewriteFilter, you should be able to do something like this to get what you want:

<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>

Upvotes: 11

Related Questions