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

Question

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

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

Проблема не возникает в Firefox, кажется, что ошибка в Chrome.

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

Я нашел несколько сообщений о/TOMCAT вопросов Chrome печенья и предложение установить, sessionCookiePathUsesTrailingSlash = ложным в context.xml , но это не решает проблему.

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

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

1. подключиться к веб-сайт через HTTPS
2. выход из системы/Войти
3. подключиться к веб-сайт с помощью HTTP
4. Tomcat JSESSIONID печенья больше не могут быть сохранены (как ни странно пользователь/пароль куки хранятся)

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

Хорошо, я добавил это к моему web.xml

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

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

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

Answer 1

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

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

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

дискуссионной here (same solution)

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

Answer 2

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

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

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

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

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

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

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

4.3.3 Управление Cookie

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

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

Удаление куки вручную из 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> 

Изменение имени печенья, установка sessionCookiePathUsesTrailingSlash или удаление HttpOnly не имел никакого эффекта

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

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

---

ОБНОВЛЕНО Вопрос, наконец, помеченный как не исправит, потому что это намеренное изменение. См https://www.chromestatus.com/feature/4506322921848832

Строгих Secure Cookies

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

Answer 3

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

Аннотация документа:

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

Хром already implemented this feature in v 52 а также особенность также implemented in Mozilla несколько дней назад.

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

Answer 4

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

Пусть браузера:

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

2. If not secure http состояние использование "JSESSIONIDForHttp".