Проблема с сеансом обмена

Question

У меня возникает проблема, когда мы используем несколько вкладок с момента ее совместного использования в одном сеансе. Любые альтернативы этому? Можем ли мы создать уникальный сеанс, когда кто-то использует вкладку или CTRL + N.

Это корпоративное приложение Java EE/Struts2, если это имеет значение.

Answer 1

Нет простого способа достичь этого, о котором я знаю.

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

Существует несколько обходных идей о том, как «отключить» старое окно, если пользователь нажимает Ctrl + N, идя через многоступенчатую форму, но вам нужно будет предоставить более подробную информацию для идей по этому поводу.

Answer 2

Обычно экземпляр браузера рассматривается как один пользователь/сущность для целей отслеживания сеанса. Особенно, если вы используете файлы cookie для отслеживания сеансов. Я не уверен, что мне нравится предлагать разные вкладки для разных сеансов. Это неинтуитивно для веб-приложений. Все ИМХО, конечно.

При этом, если вы хотите изменить это, вам придется придумать индивидуальную реализацию. Возможно, вы можете создавать и прикреплять разные идентификаторы сеанса к URL для разных вкладок. Никогда не пробовал это сам, так что не знаю, как легко это будет.

Answer 3

Это проблема, с которой сталкиваются все ориентированные на сервер веб-приложения, это не относится к Java EE. Проблема в том, что большинство браузеров хранят файлы cookie для каждого пользователя, а не для каждой вкладки. Кроме того, это поведение, как правило, не прозрачно для пользователя, добавляя к путанице. Несколько решений, которые я могу придумать (хотя ни один из них не является действительно удовлетворительным):

• Принять приложение под более чем одним URI. Таким образом, любой браузер будет хранить файлы cookie самостоятельно, и, следовательно, у вас будет один сеанс для каждой версии приложения.
• Размножать идентификаторы сеанса с помощью другого механизма, например. через URI. Однако у этого есть несколько предостережений - он предоставляет идентификатор сеанса пользователю, он делает уродливые URI и создает риск безопасности (захват сеанса и т. Д.), Когда пользователи копируют или вставляют в закладки текущий URI (потому что тогда они сохранить идентификатор сеанса в ссылке).
• Пропагандировать идентификаторы сеанса через скрытые поля внутри страницы. Это решение, вероятно, требует переписать часть встроенной обработки сеанса и теряет идентификатор сеанса, когда ваша страница содержит ссылки на другие страницы вашего приложения.
• Для Firefox есть надстройка под названием «cookie pie», которая позволяет пользователям иметь независимые файлы cookie для некоторых или всех вкладок. Недостатком является то, что пользователи должны активно активировать его, и работа над проблемой табуляции становится ответственностью пользователя. Кроме того, он не работает при любых обстоятельствах (например, Google обнаруживает ваш активный логин независимо).
• Избегайте использования состояния сеанса и используйте другие механизмы для сохранения состояния между запросами. Подобно передаче идентификаторов сеанса через скрытые поля, это ломается при определенных обстоятельствах.
• Сделайте приложение полностью ориентированным на клиента, то есть запрограммируйте весь интерфейс в javascript и общайтесь с сервером через вызовы ajax. Таким образом, вы вообще не будете зависеть от реализации cookie браузера. Скорее всего, вам придется переписывать существенные суммы кода, хотя, полагая, что ваше приложение в основном работает уже.