Иногда flash.message отображает, а иногда нет - PullRequest
Новая
       10

Иногда flash.message отображает, а иногда нет

0 голосов
/ 28 ноября 2018

Мы столкнулись с ситуацией, когда иногда flash.message отображается правильно, но иногда оно вообще не отображается.Буду признателен за любые советы по устранению неполадок.

Вот как выглядит код в нашем контроллере: 

log.debug("missing required fields ${errorMsg}")
flash.error = errorMsg
...
log.debug("leaving moveToDraft with flash.message: ${flash.message} and 
    flash.error: ${flash.error}")
redirect(controller: 'challengeManagement', action: 'show', id: 
    challenge.challengeNumber)

Вот как выглядит код представления: 

<g:if test="${flash.message}">
    <div class="message"><%=flash.message%></div>
</g:if>
<g:if test="${flash.error}">
     <div class="error"><%=flash.error%></div>
</g:if>

Этот код всегда работает для меняна моей машине разработки и тестовых системах, но для нашего специалиста по обеспечению качества примерно половина времени флэш-сообщение не отображает.Из операторов log.debug я подтвердил, что он устанавливается и имеет значение при выходе из метода контроллера.Глядя на «просмотр источника» со страницы, становится ясно, что div не существует.Они никогда не были выписаны, а это значит, что условия испытаний не были выполнены.

Теперь редирект 307 происходит после вышеупомянутого перенаправления.Так что это может быть проблемой, учитывая ограниченную область действия объекта flash ... за исключением того, что я также получаю перенаправление 307 и всегда вижу flash.message / flash.error на странице.

Есть ли способ отладки флэш-объекта, чтобы я мог видеть, когда он очищен?Кроме того, есть ли страница, которая описывает механизм более подробно?(Я читал, что это зависит от файлов cookie, но я не вижу его в списке файлов запросов).Любые другие идеи или мысли о том, как устранить неполадки?

Мой следующий шаг - переписать без использования flash-объекта, но меня беспокоит то, что я не понимаю, в чем проблема, и мы везде используем flash-объекты.

1 Ответ

0 голосов
/ 29 ноября 2018

Отвечая на мой вопрос на всякий случай, если это поможет кому-то еще.Проблема действительно была редиректом 307.

Для любого другого браузера, кроме этой конкретной версии браузера, перенаправление 307 не приводило к очистке флэш-объекта.И в этой конкретной версии браузера вспышка очищалась только часть времени, скажем, 40%.Я не знаю, почему это так, но я проследил это без сомнения.(Я подозреваю, что между двумя правилами переписывания Apache есть условие состязания, но я больше не буду исследовать.)

307 был создан правилами перезаписи на нашем сервере Apache, который перенаправлял любой входящий http-запрос на запрос https,Поэтому решение для нас было простым: сделать наши первоначальные запросы уже https, чтобы они не противоречили правилам переписывания Apache.Было два способа сделать это: 1) создать полный URI, а затем перенаправить, используя URI, а не обычные параметры контроллера / действия 

String baseUrl = ContextUtil.grailsBaseURL(true)
String uri = "${baseUrl}/challengeManagement/show/${challenge.challengeNumber}"
redirect (uri: uri)

2) добавить переменную конфигурации безопасности Spring, которая заставляет его использоватьhttps, а не http 

grails.plugin.springsecurity.secureChannel.definition = ['/**' : 
      'REQUIRES_SECURE_CHANNEL']
...