Question

我正在使用UrlRewriteFilter重定向到SSL。我正在运行Glassfishv2。

我的规则现在看起来像这样。它位于我的war文件夹的WEB-INF中的urlrewrite.xml中。是否需要设置其他玻璃鱼设置？

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

但FF一直说URL重定向规则是永远不会完成的。我不确定这里发生了什么。任何想法？

Answer 1

我怀疑问题是host标头（您要比较的标头）的值不包含用于访问资源的方案，您的比较值就是这样。这意味着条件始终为真，因为主机永远不会与您比较它的内容相等，从而导致无限重定向循环。

查看UrlRewriteFilter的文档，你应该可以做这样的事情来获得你想要的东西：

<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

网址重写规则中指定的主机名值不能包含该方案。 UrlRewriteFilter在内部使用Servlet API方法通过request.getServerName()确定主机名;此方法调用永远不会返回该方案，因此您最好单独执行方案验证（正如Tim暗示的那样）。

如果您注意到其他可用方法，则必须单独进行方案验证，因为该方案仅通过API中的request.getScheme()方法提供，该方法通过UrlRewriteFilter单独公开。

FF在重定向中报告错误的真正原因可能是由于多个302被发送回客户端，原始请求（以及客户端发出的后续请求）。您可能希望监视HTTP流量，以确定HTTPS重定向失败时是否存在规则，以确定应用程序中行为的实际原因。

修改

如果可能，您可以调查web.xml中CONFIDENTIAL transport guarantee元素的使用，以确保servlet容器强制通过SSL进行所有HTTP请求。

Answer 3

我不确定上面的示例有什么问题，但这是可以使用OCPsoft重写轻松解决的一个可爱问题，另一个开源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}"));

}

重写版本1.0.1时Scheme对象可用：http://ocpsoft.org/rewrite/

UrlRewriteFilter直接到https

3 个答案: