Передача данных сеанса между двумя разными приложениями

#session #tomcat #jsf-2 #state

#сеанс #tomcat #jsf-2 #состояние

Вопрос:

У меня есть два приложения, работающие на Tomcat, JSF 2 Mojarra 2. Оба приложения сопоставляются с одним и тем же доменом, но каждое с другим шаблоном в этом домене. Одно приложение используется в качестве главной страницы, а другое используется для доступа к защищенным ресурсам (не спрашивайте, почему не все в одном приложении, это было специально разработано, чтобы разделить приложения как две разные сущности, каждая из которых отвечает за свое дело). Теперь возникает вопрос: возможно ли это, и если да, то как передать состояние сеанса между этими двумя отдельными приложениями. Чтобы проиллюстрировать некоторые распространенные ситуации:

  1. Пользователь что-то делает в основном приложении, на котором запущен веб-сайт, а затем входит в систему, и все, что он / она делал, переносится на новый сеанс после входа в новое приложение.

  2. (Я думаю, это немного сложнее) Пользователь регистрируется в первом приложении и автоматически входит в систему после успешной регистрации в другом приложении. Приложение, в которое вы должны войти, использует форму входа в систему j_security_check (это будет сложная часть)

Ответ №1:

Несколько способов:

  1. Храните данные в DB which и идентифицируйте их с помощью длинного, уникального, трудно угадываемого автоматически сгенерированного ключа, который вы, в свою очередь, также сохраняете в файле cookie для всего домена. Таким образом, оба приложения могут получать данные из базы данных на основе ключа, найденного в файле cookie.

  2. Предоставьте ServletContext оба приложения друг другу. В Tomcat это вопрос добавления crossContext="true" к <Context> элементу context.xml веб-приложения. Таким образом, вы можете получить данные друг друга ServletContext , ServletContext#getContext(). наконец, вставив Map<String, SomeData> туда некоторые, которые вводятся с помощью некоторого идентификатора, который является общим для обоих приложений, например, идентификатора пользователя, вошедшего в систему (вы должны только убедиться, что у одного и того же пользователя не может быть более одного сеанса).

Комментарии:

1. Спасибо, очень полезно. Второй вариант кажется идеальным здесь и именно то, что я ищу. Я некоторое время рассматривал вариант 1, но решил отказаться от него, не думал, что это хорошая идея — идти на такие меры и сохранять данные, которые вполне могут оказаться бесполезными (например, пользователь никогда не выходит за пределы точки входа в систему), а затем дополнительно управлять обслуживанием всего этого. Все еще не уверен, как подойти к проблеме login j_security. Вы говорите, что я должен убедиться, что у одного и того же пользователя не более одного сеанса.. новый создается при входе в систему . Не будут ли оба приложения хранить два разных сеанса?