Хранилище Chrome не работает после перезагрузки веб-сервера tomcat

Недавно я заметил, что при перезагрузке моего веб-сервера Tomcat браузер Chrome больше не может хранить файлы cookie. т.е. tomcat использует файлы cookie для http-сеансов, и браузер больше не может получить свой сеанс http, а также cookie, который мы используем для хранения зарегистрированного пользователя, терпит неудачу, и пользователь не остается в системе.

Это, кажется, новая проблема с Chrome, возможно, из недавнего обновления, я не помню, чтобы это было раньше. Если я закрою браузер Chrome, а затем снова его заново, он будет снова прекрасен (пока сервер не перезагрузится снова).

Проблема не возникает в Firefox, похоже на ошибку в Chrome.

Кто-нибудь еще заметил эту проблему или знал о решении?

Я нашел несколько сообщений о проблемах с Chrome/tomcat cookie и предложение установить, sessionCookiePathUsesTrailingSlash = false в контексте .xml но это не устраняет проблему.

Кажется, это может быть связано с сайтом, поддерживающим как https, так и http, и переключение между ними (хотя это произошло на веб-сайте, который также не поддерживает https...)

Хорошо, теперь я могу воссоздать проблему, шаги.

  • подключиться к веб-сайту через https
  • logout/login
  • подключиться к веб-сайту через http
  • Tomcat JSESSIONID cookie больше не может быть сохранен (нечетные куки файлы пользователя/пароля хранятся)

Это происходит только в Chrome, и только после обновления Chrome, который добавляет флаг "небезопасный" на страницах входа, которые используют http

Хорошо, я добавил это в свой web.xml

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

Это не устранило проблему, но проблема всегда возникала с помощью http, т.е. заставляла http больше не хранить файл cookie JSESSIONID. Я пробовал <secure>false</secure>, но все еще получаю старую проблему. Поэтому, по крайней мере, это связано с этой настройкой. У кого-нибудь есть идеи?

Записанная ошибка в Chrome, https://bugs.chromium.org/p/chromium/issues/detail?id=698741

Ответы

Ответ 1

Я смог воспроизвести вашу проблему с Chrome: просто нужно создать HttpSession из зоны HTTPS. Любой последующий HTTP-запрос не будет отправлять cookie сеанса, и любая попытка Set-Cookie:JSESSIONID= через HTTP игнорируется хром.

Проблема локализована, когда пользователь переключается с HTTPS на HTTP. Файл cookie сеанса HTTPS поддерживается, даже если сервер перезагружен и работает правильно. (Я тестировал Tomcat6, Tomcat 9 и использовал прокси-сервер apache для SSL)

Это заголовок ответа, отправленный Tomcat, когда сеанс создан из HTTPS

 Set-Cookie: JSESSIONID=CD93A1038E89DFD39F420CE0DD460C72;path=/cookietest;Secure;HttpOnly

и этот для HTTP (примечание Secure отсутствует)

 Set-Cookie:SESSIONID=F909DBEEA37960ECDEA9829D336FD239;path=/cookietest;HttpOnly

Chrome игнорирует второй set-Cookie. С другой стороны Firefox и Edge заменяют Secure cookie не-secured. Чтобы определить, какое должно быть правильное поведение, я рассмотрел RFC2109

4.3.3 Управление файлами cookie

Если пользовательский агент получает заголовок ответа Set-Cookie, чье имя NAME    так же, как и ранее существовавший файл cookie, и чей домен и путь    значения атрибутов точно (строка) соответствуют значениям из ранее существовавших    cookie, новый файл cookie заменяет старый.

Итак, ясно, что хром-ошибка, как вы предполагали в вопросе: HTTP файл cookie должен заменить тот, который установлен HTTPS

Удаление cookie вручную из Chrome или аннулирование сеанса на стороне сервера заставляет его работать снова (если после этих действий сеанс создается с использованием HTTP)

По умолчанию файл cookie JSESSIONID создается с помощью Secure, когда запрашивается HTTPS. Я думаю, это причина, по которой Chrome не позволяет перезаписывать файл cookie. Но если вы попытаетесь установить <secure>false</secure> в web.xml, то Tomcat игнорирует его, а заголовок set-Cookie отправляется с Secure

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

Изменение имени файла cookie, установка sessionCookiePathUsesTrailingSlash или удаление HttpOnly не имеет эффекта

Я не мог найти обходной путь для этой проблемы, кроме как недействительный сеанс сервера при входе пользователя в систему с HTTPS на HTTP.

Наконец, я открыл ошибку в хроме: https://bugs.chromium.org/p/chromium/issues/detail?id=698839

ОБНОВЛЕНО Проблема окончательно отмечена как Не будет исправлена ​​, потому что это намеренное изменение. См. https://www.chromestatus.com/feature/4506322921848832

Строгие безопасные файлы cookie

Это добавляет ограничения на файлы cookie, отмеченные атрибутом "Безопасный". В настоящее время безопасные файлы cookie недоступны из-за небезопасности (например, HTTP). Однако ненадежное происхождение может по-прежнему добавлять безопасные файлы cookie, удалять их или косвенно выселять их. Эта функция изменяет банку cookie так, что ненадежное происхождение никак не может касаться защищенных файлов cookie. Это оставляет высечку за выселение печенья, которое все равно может привести к удалению файлов cookie, но только после того, как все cookie, не являющиеся безопасными, будут выселены.

Ответ 2

Я помню это несколько раз, и насколько я помню, это была единственная рекомендация по этому вопросу, как вы упомянули:

Возможным решением этого может быть добавление sessionCookiePathUsesTrailingSlash=false в context.xml и посмотреть, как это происходит.

Некоторая информация по этому вопросу из здесь

введите описание изображения здесь

Обсуждение здесь (это же решение)

Надеюсь, я не путал проблемы, и это поможет вам, сообщите мне, если мне нужно отредактировать/если сработает/если я удалю, спасибо!

Ответ 3

Существует черновик документа, чтобы отказаться от модификации "защищенных" куки файлов из незащищенных источников (представленных Google). В нем указаны рекомендации по изменению документа HTTP State Management Mechanism.

Резюме документа:

Этот документ обновляет RFC6265, удаляя возможность для безопасное начало для установки файлов cookie с "безопасным" флагом и для перезаписи cookies, чей флаг "безопасный" установлен. Это обесценивание улучшает изоляции между HTTP и HTTPS-происхождением и снижает риск вредоносное вмешательство.

Chrome уже реализовал эту функцию в версии 52, а также функция реализовано в Mozilla несколько дней назад.

Чтобы решить эту проблему, я думаю, вы должны подключиться к веб-сайту только через https.

Ответ 4

Плохой способ, я думаю, установить sessionCookieName = "JSESSIONIDForHttp" в context.xml

Предоставить браузеру cookie:

  • Если безопасное условие https используется по умолчанию "JSESSIONID".

  • Если не безопасно http использовать условие "JSESSIONIDForHttp".