UrlRewriteFilter Прямая ссылка на https

Я использую UrlRewriteFilter для перенаправления на SSL. Я использую Glassfishv2.

Мое правило сейчас выглядит примерно так. Это в моем urlrewrite.xml в WEB-INF моей военной папки. Есть ли какие-либо другие настройки Glassfish, которые необходимо установить?

<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-адресов таково, что оно никогда не будет выполнено. Я не совсем уверен, что здесь происходит. Любые идеи?


java url-rewriting glassfish
person adi    schedule 02.08.2010    source источник

Ответы (3)


arrow_upward
11
arrow_downward

Я подозреваю, что проблема в том, что значение заголовка 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>
person Tim Stone    schedule 02.08.2010
comment
Большое спасибо, Тим и Винит. Отсутствующая в правиле схема была проблемой и теперь перенаправляет правильно. - person adi; 02.08.2010
comment
использование схемы для типа в первом условии у меня не сработало. Вместо этого я использовал это, которое сработало: ‹тип условия=оператор заголовка=неравное имя=X-Forwarded-Proto›^HTTPS$‹/условие› - person ninjasense; 19.06.2014

arrow_upward
0
arrow_downward

Значение имени хоста, указанное в правиле перезаписи URL, не может включать схему. UrlRewriteFilter внутренне использует методы Servlet API для определения имени хоста через request.getServerName(); этот вызов метода никогда не возвращает схему, поэтому вам лучше выполнить проверку схемы отдельно (как подразумевал Тим).

Если вы заметили другие доступные методы, проверку схемы необходимо выполнить отдельно, поскольку схема доступна только через request.getScheme() в API, который предоставляется отдельно через UrlRewriteFilter.

Настоящая причина того, почему FF сообщает об ошибке перенаправления, вероятно, связана с тем, что несколько 302 отправляются обратно клиенту для исходного запроса (и последующих запросов, сделанных клиентом). Возможно, вы захотите отслеживать HTTP-трафик, чтобы определить, существует ли правило, которое присутствует при сбое перенаправления HTTPS, по фактической причине поведения в вашем приложении.

ИЗМЕНИТЬ:

Если возможно, вы можете расследовать использование КОНФИДЕНЦИАЛЬНОГО элемента транспортной гарантии. в web.xml, чтобы убедиться, что контейнер сервлетов принудительно выполняет все HTTP-запросы через SSL.

person Vineet Reynolds    schedule 02.08.2010

arrow_upward
0
arrow_downward

Я не совсем уверен, что не так с вашим примером выше, но это одна из тех замечательных проблем, которые можно легко решить с помощью OCPsoft rewrite, другого 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}"));

}

Объект Scheme доступен, начиная с версии Rewrite 1.0.1: http://ocpsoft.org/rewrite/

person Lincoln    schedule 27.03.2012