приложения, поддерживающие сеанс - PullRequest
2 голосов
/ 20 апреля 2011

Я намеренно написал «сессионную информацию» вместо «общих сеансов». Ниже приведен сценарий:

У меня есть веб-приложение (WA1), развернутое в одном экземпляре Tomcat. Предположим, что все приложения развернуты в корне, и мы не имеем дело с контекстами. Это приложение позволяет пользователям входить в систему, делать свои вещи на сайте и выходить из системы.

В другом экземпляре tomcat есть другое веб-приложение (WA2). Это приложение обрабатывает службу, скажем, она читает некоторые файлы и потоки в браузере.

WA1 обслуживает страницу, на которой есть ссылка на WA2.

Теперь у меня есть действующий сеанс в WA1, который определяет, кто является пользователем, и является ли сеанс действительным сеансом. Я хотел бы, чтобы WA2 узнал об этом, прежде чем выполнить запрос со страницы, обслуживаемой WA1.

Какой лучший способ справиться с этим?

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

Я склоняюсь к механизму «токенов», где WA1 создает токен, связанный с каждым сеансом, и делает его доступным для каждого URL-адреса WA2 с любой страницы, обслуживаемой WA1. WA2 сначала проверяет токен и проверяет, является ли он действительным токеном (для этого есть много способов: A: сделать вызов веб-службы WA1, чтобы узнать, является ли токен действительным токеном сеанса. B: WA1 сохраняется в БД или Файловая система и WA2 ищет оттуда ..), и если он действителен, то удовлетворять запрос. Проблема здесь заключается в том, чтобы удостовериться, что токен становится недействительным после истечения сеанса в WA1.

Я хотел бы знать, достаточно ли хорош этот подход, или есть ли лучшие способы сделать это?

Спасибо

M. Скорее

1 Ответ

1 голос
/ 20 апреля 2011

По умолчанию API сервлета использует cookie, обычно называемый jsessionid, для хранения идентификатора сеанса в каждом браузере.Затем браузер передает куки на сервер с каждым запросом.Пока оба экземпляра tomcat находятся в одном домене, они оба должны иметь доступ к этому cookie.Если я что-то не упустил, это всего лишь вопрос тестирования этого cookie во втором приложении.

Обновление: Даже если каждый экземпляр tomcat работает в другом домене, они все равноподелитесь этими файлами cookie, вызвав метод setDomain(String domainPattern) класса Cookie.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...