Подтвердить что ты не робот

Сессия теряется и создается как новая в каждом запросе сервлета

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

Я проверил много мест. Я не могу найти, в чем проблема. Я также включил session-config в web.xml как в tomcat, так и в приложении. Я также разрешил принимать файлы cookie в своих браузерах. Протестировано в каждом браузере. Это не работает.

Я просто разрабатываю простой java ee applcation с помощью JSP/Servlet. Я столкнулся с проблемой только после того, как я развернулся на tomcat на серверной машине.

4b9b3361

Ответ 1

Спустя годы я никогда не отправлял ответ обратно. В то время я был занят и забыл об этом вопросе. Но сегодня я ищу решение в Stackoverflow, как обычно, и увидел, что это уведомление упоминает, что я получаю очки от этого Вопроса. Похоже, что другие разработчики сталкиваются с одной и той же проблемой. Итак, я попытался вспомнить, как я решил проблему. И да, я решил вручную поместить идентификатор сеанса для отслеживания/сохранения идентификатора сеанса.

Пожалуйста, посмотрите код, который я вручную вернул jsessionid внутри сервлета.

HttpSession session = request.getSession();
if (request.getParameter("JSESSIONID") != null) {
    Cookie userCookie = new Cookie("JSESSIONID", request.getParameter("JSESSIONID"));
    response.addCookie(userCookie);
} else {
    String sessionId = session.getId();
    Cookie userCookie = new Cookie("JSESSIONID", sessionId);
    response.addCookie(userCookie);
}

Ответ 2

Одной из возможных причин для этого является наличие "голого" имени хоста (т.е. одного без части домена). Это довольно распространено, если вы работаете в Интранет.

Проблема в том, что почти все куки файлы браузеров не будут принимать файлы cookie для имен хостов без имени домена. Это сделано для того, чтобы предотвратить evilsite.com от установки Cookie для com (что было бы плохо, так как это было бы окончательным cookie отслеживания).

Поэтому, если вы получите доступ к вашему заявлению через http://examplehost/, он не будет принимать никаких файлов cookie, а для http://examplehost.localdomain/ он будет принимать (и возвращать) cookie просто отлично.

Отвратительная вещь в том, что сервер не может различать "браузер получил куки и проигнорировал его", и "браузер никогда не получал cookie". Таким образом, каждый отдельный доступ будет выглядеть как совершенно новый sesson для сервера.

Ответ 3

Попробуйте добавить плагин Live Http Headers в firefox и убедитесь, что cookie сеанса действительно передается в браузер с сервера, и убедитесь, что браузер отправляет его обратно при следующем запросе.

Ответ 4

Пожалуйста, проверьте, не является ли сеанс недействительным в вашем коде где-нибудь. Найдите код, похожий на request.getSession().invalidate();

Ответ 5

Сначала проверьте, настроен ли context.xml не.

Далее полезно знать, что файлы cookie зависят от домена, порта и контекста. Если ссылки на странице указывают на другой домен, порт и/или контекстный путь в отличие от текущего URL-адреса запроса (тот, который вы видите в адресной строке браузера), то cookie не будет передан, что приведет к тому, что сеанс больше не может быть идентифицирован, и вы получите новый из контейнера servlet.

Если это не является причиной, проверьте, если вы не делаете перенаправление по запросу каждый, используя HttpServletResponse.sendRedirect() по какой-либо причине. Если вы сделаете это уже по первому запросу, то cookie будет потерян. Вам нужно будет заменить

response.sendRedirect(url);

по

response.sendRedirect(response.encodeRedirectURL(url));

Ответ 6

Я столкнулся с проблемой устаревшего https session cookie (мой ad-hoc term) из-за безопасного флага.

У меня была эта проблема при переключении между http и https. Файл cookie, хранящийся в https-сеансе, никогда не был перезаписан http-сеансом. Он оставался в памяти FireFox на вечность. Он был виден в FireFox Tools/Options/Privacy/Delete single cookie, где в поле "Отправить" это было только для защищенных подключений. Очистка этого одного файла cookie или всех файлов cookie является обходным способом.

Я отлаживал проблему с помощью wget, и я заметил такой заголовок:

Set-Cookie: JSESSIONID=547ddffae0e5c0e2d1d3ef21906f; Path=/myapp; Secure; HttpOnly

Слово secure отображается только в https-соединениях и создает этот устаревший файл cookie. Это SecureFlag (см. OWASP). Есть способы отключить этот флаг на стороне сервера, который кажется постоянным решением, но, возможно, небезопасным.

Или это ошибка браузера, что файл cookie не перезаписан?

Ответ 7

Измените файл tomcat context.xml и замените тег <Context> на <Context useHttpOnly="false">, это помогло мне.

Ответ 8

Если есть конфигурация баланса нагрузки, необходимо будет сконфигурировать маршрут в сети для сохранения запросов на одном сервере. В противном случае каждый запрос перейдет на другой сервер, потеряв атрибут сеанса.