В веб-приложении, реализованном на Java с использованием JSP и Servlets; если я храню информацию в пользовательском сеансе, эта информация передается со всех вкладок одного и того же браузера. Как отличить сеансы в браузере-вкладках? В этом примере:
<%@page language="java"%>
<%
String user = request.getParameter("user");
user = (user == null ? (String)session.getAttribute("SESSIONS_USER") : user);
session.setAttribute("SESSIONS_USER",user);
%>
<html><head></head><body>
<%=user %>
<form method="post">
User:<input name="user" value="">
<input type="submit" value="send">
</form>
</body></html>Скопируйте этот код на странице JSP (testpage.jsp ), разверните этот файл в существующем контексте веб-приложения на сервере (я использую Apache Tomcat), затем откройте браузер (FF, IE7 или Opera), используя правильный URL ( localhost/context1/testpage.jsp), введите ваше имя на входе и отправьте форму. Затем откройте новую вкладку в том же браузере, и тогда вы сможете увидеть свое имя (получить из сеанса) на новой вкладке. Будьте осторожны с кешем браузера, иногда кажется, что этого не происходит, но он находится в кеше, обновите вторую вкладку.
Спасибо.
Ответы:
Вы можете использовать HTML5 SessionStorage (window.sessionStorage). Вы сгенерируете случайный идентификатор и сохраните в сеансе Хранилище для вкладки браузера. Тогда каждая вкладка браузера имеет свой собственный идентификатор.
источник
Вы должны понимать, что сеансы на стороне сервера являются искусственным дополнением к HTTP. Поскольку HTTP не имеет состояния, сервер должен каким-то образом распознать, что запрос принадлежит конкретному пользователю, которого он знает и для которого существует сеанс. Есть 2 способа сделать это:
Что ты пытаешься делать? Почему вы хотите, чтобы вкладки имели отдельные сессии? Может быть, есть способ достичь цели без использования сессий вообще?
Изменить: для тестирования могут быть найдены другие решения (например, запуск нескольких экземпляров браузера на отдельных виртуальных машинах). Если одному пользователю необходимо одновременно выполнять разные роли, тогда в приложении должна быть реализована концепция «роли», чтобы один логин мог иметь несколько ролей. Вам нужно решить, является ли это более приемлемым, с использованием перезаписи URL или просто с учетом текущей ситуации, поскольку просто невозможно обрабатывать вкладки браузера отдельно с помощью сеансов на основе файлов cookie.
источник
Свойство window.name Javascript - это единственная вещь, которая будет сохраняться в течение всей активности вкладок, но может оставаться независимой (вместо URL-болтовни).
источник
Ты не должен.Если вы хотите сделать такую вещь, либо вам нужно заставить пользователя использовать один экземпляр вашего приложения, записывая URL-адреса «на лету», используя идентификатор sessionID (а не sessionid, он не будет работать) id и передавая его в каждом URL-адресе.
Я не знаю, зачем вам это нужно, но если вам не нужно создать совершенно непригодное приложение, не делайте этого.
источник
Я придумал новое решение, которое немного перегружено, но, похоже, работает как прототип. Одно из предположений заключается в том, что вы находитесь в системной среде чести для входа в систему, хотя это можно изменить, запрашивая пароль при каждом переключении вкладок.
Используйте localStorage (или эквивалентный) и событие хранилища HTML5, чтобы определить, когда новая вкладка браузера изменила, какой пользователь активен. Когда это произойдет, создайте призрачное наложение с сообщением о том, что вы не можете использовать текущее окно (или временно отключите окно, возможно, вы не захотите, чтобы оно было таким заметным). Когда окно восстанавливает фокус, отправьте запись AJAX-запроса пользователь вернулся.
Одно предостережение об этом подходе: у вас не может быть никаких обычных вызовов AJAX (то есть тех, которые зависят от вашего сеанса), происходящих в окне, которое не имеет фокуса (например, если у вас был вызов, произошедший после задержки), если только перед этим вы вручную делаете повторный вход в AJAX. Поэтому на самом деле все, что вам нужно сделать, это сначала проверить свою функцию AJAX, чтобы убедиться, что localStorage.currently_logged_in_user_id === window.yourAppNameSpace.user_id, и если нет, сначала войдите в систему через AJAX.
Другой - это условия гонки: если вы можете переключать окна достаточно быстро, чтобы запутать его, вы можете получить последовательность relogin1-> relogin2-> ajax1-> ajax2, причем ajax1 выполняется в неправильном сеансе. Чтобы обойти эту проблему, отправьте запросы AJAX входа в массив, а затем onstorage и перед выполнением нового запроса входа прервите все текущие запросы.
Последнее, на что нужно обратить внимание - это обновления окна. Если кто-то обновит окно, когда у вас активен, но не выполнен запрос на вход в AJAX, он будет обновлен на имя не того человека. В этом случае вы можете использовать нестандартное событие beforeunload, чтобы предупредить пользователя о возможной путанице и попросить его нажать Отмена, в то же время повторно выполняя запрос входа в AJAX. Тогда единственный способ, которым они могут это испортить, - это нажать OK до завершения запроса (или случайно нажав Enter / пробел, потому что OK - к сожалению для этого случая - по умолчанию.) Есть другие способы обработки этого случая, например обнаружение нажатий F5 и Ctrl + R / Alt + R, которые будут работать в большинстве случаев, но могут быть сорваны из-за перенастройки сочетания клавиш пользователя или альтернативного использования ОС. Тем не менее, это немного крайний случай в реальности, и наихудшие сценарии никогда не бывают такими плохими: в конфигурации системы чести вы будете зарегистрированы как неправильный человек (но вы можете сделать это очевидным, если персонализируете страницы цветами, стилями, заметными именами, и т.д.); в конфигурации с паролем ответственность лежит на последнем человеке, который ввел свой пароль, чтобы выйти из системы или поделился своим сеансом, или, если этот человек фактически является текущим пользователем, нарушения не существует.
Но, в конце концов, у вас есть приложение «один пользователь на вкладку», которое (будем надеяться) просто работает как надо, без необходимости настраивать профили, использовать IE или переписывать URL-адреса. Убедитесь, что вы четко указываете на каждой вкладке, кто вошел в эту вкладку, хотя ...
источник
У нас была эта проблема, и мы решили ее очень легко. Я имею в виду легко, потому что никакого программирования не участвует. Мы хотели, чтобы пользователь мог войти в несколько учетных записей в одном окне браузера, не конфликтуя между сеансами.
Таким образом, решение было случайных поддоменов.
Поэтому мы попросили нашего системного администратора настроить SSL-сертификаты для * .abc.com, а не для abc.com. После небольшого изменения кода каждый раз, когда пользователь пытается войти в систему, он попадает на вкладку со случайным номером субдомена. поэтому каждая вкладка может иметь свою собственную сессию независимо. Также, чтобы избежать любого конфликта, мы разработали случайное число, используя хэш или md5 идентификатора пользователя.
источник
Я буду честен здесь. , , все вышеперечисленное может быть или не быть правдой, но все это кажется СЛИШКОМ СЛОЖНЫМ или не учитывает знание того, какая вкладка используется на стороне сервера.
Иногда нам нужно применить бритву Оккама.
Вот подход Оккама: (нет, я не Оккам, он умер в 1347 году)
1) назначить уникальный идентификатор браузера для вашей страницы при загрузке. , , тогда и только тогда, когда у окна еще нет идентификатора (поэтому используйте префикс и обнаружение)
2) на каждой вашей странице (используйте глобальный файл или что-то еще) просто поместите код на место для обнаружения события фокуса и / или события наведения мыши. (Я буду использовать jquery для этой части, для простоты написания кода)
3) в вашей функции фокуса (и / или наведения мыши) установите cookie с окном window.name
4) читать значение cookie со стороны вашего сервера, когда вам нужно прочитать / записать данные, относящиеся к вкладке.
Сторона клиента:
сторона сервера (C # - для примера)
Готово.
источник
Вы можете использовать переписывание ссылок, чтобы добавить уникальный идентификатор ко всем вашим URL-адресам, когда начинаете с одной страницы (например, index.html / jsp / что угодно). Браузер будет использовать одни и те же файлы cookie для всех ваших вкладок, поэтому все, что вы помещаете в файлы cookie, не будет уникальным.
источник
Я думаю, что вы, вероятно, хотите, чтобы поддерживать состояние навигации по вкладкам, а не специально создавать один сеанс для каждой вкладки. Это именно то, чего достигает платформа Seam с их контекстом / контекстом беседы. Их реализация основана на том факте, что идентификатор диалога распространяется с каждым запросом и создает понятие диалога на стороне сервера, которое находится между сеансом и запросом. Это позволяет контролировать поток навигации и управление состоянием.
Хотя это в основном нацелено на JSF, посмотрите и проверьте, можете ли вы кое-что почерпнуть из: http://docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620
источник
В javascript, как я могу однозначно идентифицировать одно окно браузера из другого, которые находятся под тем же идентификатором сессии
По существу используйте window.name. Если он не установлен, установите для него уникальное значение и используйте его. Это будет отличаться для разных вкладок, которые принадлежат одному сеансу.
источник
Другой подход, который работает, состоит в том, чтобы создать уникальный идентификатор окна и сохранить это значение вместе с идентификатором сеанса в таблице базы данных. Идентификатор окна, который я часто использую, является целым числом (сейчас). Это значение создается, когда окно открывается и переназначается тому же окну, если оно обновляется, перезагружается или передается самому себе. Значения окна (входы) сохраняются в локальной таблице по ссылке. Когда значение требуется, оно получается из таблицы базы данных на основе ссылки идентификатора окна / идентификатора сеанса. Хотя этот подход требует локальной базы данных, он практически надежен. Мне было легко использовать таблицу базы данных, но я не вижу причин, по которым локальные массивы не будут работать так же хорошо.
источник
Недавно я разработал решение этой проблемы с помощью файлов cookie. Вот ссылка на мое решение. Я также включил пример кода решения с использованием ASP.NET, вы сможете адаптировать его к JSP или сервлетам, если вам нужно.
https://sites.google.com/site/sarittechworld/track-client-windows
источник
Spring Session поддерживает несколько сеансов в одном браузере. Посмотрите примеры и детали реализации http://docs.spring.io/spring-session/docs/current/reference/html5/guides/users.html
источник
Примечание: решение здесь должно быть сделано на этапе разработки приложения. Было бы сложно спроектировать это позже.
Используйте скрытое поле для передачи идентификатора сеанса .
Для этого на каждой странице должна быть форма:
Каждое действие на вашей стороне, включая навигацию, отправляет форму обратно (при
actionнеобходимости). Для «небезопасных» запросов вы можете включить другой параметр, например, содержащий значение JSON данных, которые будут отправлены:Поскольку нет файлов cookie, каждая вкладка будет независимой и не будет знать о других сеансах в том же браузере.
Много преимуществ, особенно когда речь идет о безопасности:
Некоторые недостатки:
Дополнительная информация здесь .
источник
Я решил это следующим образом:
вот код:
Я надеюсь помочь тебе
источник
Я читал этот пост, потому что думал, что хочу сделать то же самое. У меня похожая ситуация для приложения, над которым я работаю. И на самом деле это вопрос тестирования больше, чем практичность.
Прочитав эти ответы, особенно ответ, который дал Майкл Боргвардт, я понял, какой рабочий процесс должен существовать:
Это решит проблему, когда пользователь увидит данные «другого пользователя» в своем сеансе. Они на самом деле не видят данные «другого пользователя» в своем сеансе, они действительно видят данные из единственного открытого сеанса. Очевидно, что это вызывает некоторые интересные данные, так как некоторые операции перезаписывают одни данные сеанса, а не другие, поэтому у вас есть комбинация данных в этом единственном сеансе.
Теперь, чтобы решить проблему тестирования. Единственный жизнеспособный подход заключается в использовании директив препроцессора для определения необходимости использования сеансов без файлов cookie. Видите, благодаря созданию определенной конфигурации для конкретной среды, я могу сделать некоторые предположения об окружающей среде и для чего она используется. Это позволило бы мне технически подключить одновременно двух пользователей, и тестировщик мог протестировать несколько сценариев из одного сеанса браузера, даже не выходя из какого-либо из этих сеансов сервера.
Тем не менее, этот подход имеет ряд серьезных предостережений. Не в последнюю очередь это тот факт, что тестер тестирует не то, что собирается запустить в производство.
Так что я думаю, что должен сказать, что в конечном итоге это плохая идея.
источник
Сохранение метки времени в window.sessionStorage, если она еще не установлена. Это даст уникальное значение для каждой вкладки (даже если URL-адреса одинаковы)
http://www.javascriptkit.com/javatutors/domstorage.shtml
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage
Надеюсь это поможет.
источник
Самый простой способ различать сеансы на вкладках браузера - запретить настройку файлов cookie в вашем конкретном домене. Таким образом, вы можете иметь отдельные сессии из отдельных вкладок. Скажем, вы запрещаете куки с этого домена: www.xyz.com. Вы открываете Tab 1, авторизуетесь и начинаете просмотр. Затем вы открываете Tab 2, и вы можете войти в систему как тот же пользователь или другой; в любом случае у вас будет сеанс, отдельный от Tab 1. И так далее.
Но, конечно, это возможно, когда у вас есть контроль над клиентской стороной. В противном случае, решения, предписанные людьми здесь, должны применяться.
источник
вам нужно будет сделать
1- сохранить куки для списка аккаунтов
2 - опционально хранить куки для файлов по умолчанию
3 - хранить для каждой учетной записи с индексом, таким как acc1, acc2
4 - введите в URL-адрес что-то, представляющее индекс учетных записей, и если нет, вы выберете индекс по умолчанию, например, gmail mail domain.com/0/some-url >> 0, здесь представлен индекс учетной записи, также вам может понадобиться узнать, как использовать urlwrite
5 - при выборе файла cookie выберите его в соответствии с вашим URL-адресом, представляющим индекс учетной записи.
С уважением
источник
Я вижу много реализаций, в которых есть изменения на стороне клиента для манипулирования куки-файлами идентификатора сессии. Но в общем случае куки с идентификатором сессии должны быть HttpOnly, чтобы java-скрипт не мог получить к ним доступ, иначе это может привести к перехвату сессии через XSS
источник
Если это связано с тем, что на каждой вкладке будет выполняться отдельный поток в вашем приложении, а смешивание обоих потоков вызывает проблемы, то лучше «регионализировать» объекты сеанса, чтобы каждый поток использовал свою область сеанса.
Эта область может быть реализована так же, как и просто иметь разные префиксы для каждого потока, или объект сеанса будет содержать несколько карт (по одной для каждого потока), и вы используете эти карты вместо атрибутов сеанса, хотя лучше всего было бы расширить класс сеанса и используйте это вместо этого.
источник