Как отличить сессии в браузере-вкладках?


135

В веб-приложении, реализованном на 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), введите ваше имя на входе и отправьте форму. Затем откройте новую вкладку в том же браузере, и тогда вы сможете увидеть свое имя (получить из сеанса) на новой вкладке. Будьте осторожны с кешем браузера, иногда кажется, что этого не происходит, но он находится в кеше, обновите вторую вкладку.

Спасибо.



1
Это то, что пользователь должен сделать: откройте IE, нажмите «Файл-> Новая сессия»
Stefan Steiger,

3
@Quandary, ваше решение не является универсальным (в других браузерах это не работает) и, самое главное, оно не очень удобно (пользователи не знают о сессиях).
Oriol Terradas

2
Некоторые люди, кажется, не могут себе представить, какова цель этого. Проблемная область - это практически любая ситуация, в которой вы хотите разрешить разные «просмотры» вашего веб-сайта. Как только пользователь может иметь более одного просмотра вашего сайта, он неизбежно долго (или случайно пытается) получить доступ к двум различным представлениям одновременно. Примеры включают: временное управление версиями (переключение на просмотр веб-сайта, поскольку он существовал в определенный момент в прошлом); песочница (внесение изменений в сайт, пока другие не видят); представления на основе ролей (посмотрите, как сайт выглядит для менее привилегированного пользователя); и т.д.
Рон Берк

Ответы:


92

Вы можете использовать HTML5 SessionStorage (window.sessionStorage). Вы сгенерируете случайный идентификатор и сохраните в сеансе Хранилище для вкладки браузера. Тогда каждая вкладка браузера имеет свой собственный идентификатор.

Данные, сохраненные с помощью sessionStorage, не сохраняются на вкладках браузера, даже если обе вкладки содержат веб-страницы из одного и того же домена. Другими словами, данные внутри sessionStorage ограничиваются не только доменом и каталогом вызывающей страницы, но и вкладкой браузера, в которой находится страница. Сравните это с файлами cookie сеанса, которые сохраняют данные от вкладки к вкладке.


7
Из документов: «Данные, сохраненные с помощью sessionStorage, не сохраняются на вкладках браузера, даже если две вкладки содержат веб-страницы из одного и того же домена. Другими словами, данные внутри sessionStorage ограничиваются не только доменом и каталогом вызывающей страницы, но и вкладка браузера, в которой находится страница. Сравните это с файлами cookie сеанса, которые сохраняют данные от вкладки к вкладке. " Простое тестирование подтверждает это поведение в Chrome и FF.
Jswanson

21
Обратите внимание, что идентификатор будет дублироваться при использовании функции Chrome «Duplicate Tab». Как правило, это не проблема, но следует продумать.
JosiahDaniels

За исключением случаев, когда вы «дублируете» вкладку в Chrome или Firefox. В этом случае SessionStorage копируется.
Tiago Freitas Leal

@ Гонсало Галлотти: И как это поможет мне, если сессия будет на стороне сервера? )))
Стефан Штайгер

@StefanSteiger. Затем вы можете отправить идентификатор BrowserTab (сохраненный в хранилище сеансов) с помощью Ajax Call. На стороне сервера вам понадобится пользовательская логика, потому что WebSession - это то же самое. Но вы можете создать HashMap с объектами Session по вкладке.
Гонсало

23

Вы должны понимать, что сеансы на стороне сервера являются искусственным дополнением к HTTP. Поскольку HTTP не имеет состояния, сервер должен каким-то образом распознать, что запрос принадлежит конкретному пользователю, которого он знает и для которого существует сеанс. Есть 2 способа сделать это:

  • Печенье. Более чистый и популярный метод, но это означает, что все вкладки и окна браузера одним пользователем совместно используют сеанс - IMO, это на самом деле желательно, и я был бы очень раздражен на сайте, который заставил меня войти в систему для каждой новой вкладки, так как я использовать вкладки очень интенсивно
  • Перезапись URL. К любому URL на сайте добавлен идентификатор сеанса. Это больше работы (вы должны что-то делать везде, где у вас есть внутренняя ссылка на сайт), но позволяет иметь отдельные сеансы на разных вкладках, хотя вкладки, открытые по ссылке, по-прежнему будут совместно использовать сеанс. Это также означает, что пользователь всегда должен входить в систему, когда он заходит на ваш сайт.

Что ты пытаешься делать? Почему вы хотите, чтобы вкладки имели отдельные сессии? Может быть, есть способ достичь цели без использования сессий вообще?

Изменить: для тестирования могут быть найдены другие решения (например, запуск нескольких экземпляров браузера на отдельных виртуальных машинах). Если одному пользователю необходимо одновременно выполнять разные роли, тогда в приложении должна быть реализована концепция «роли», чтобы один логин мог иметь несколько ролей. Вам нужно решить, является ли это более приемлемым, с использованием перезаписи URL или просто с учетом текущей ситуации, поскольку просто невозможно обрабатывать вкладки браузера отдельно с помощью сеансов на основе файлов cookie.


6
Это для большого приложения, которое хранит пользовательскую информацию и окружающую среду. Когда кто-то входит в систему с разными пользователями на разных вкладках, для тестирования или для разных ролей, он пересекает информацию из вкладок.
Oriol Terradas

Просто очень позднее дополнение, почему: потому что мне нужно это знать, например, чтобы узнать, на КАКУЮ страницу моего сайта ориентирован пользователь, а не только на то, что он переходил со страницы на страницу ( вместо этого они пошли от вкладки к вкладке).
Оливер Уильямс

16

Свойство window.name Javascript - это единственная вещь, которая будет сохраняться в течение всей активности вкладок, но может оставаться независимой (вместо URL-болтовни).


3
window.sessionStorage делает то же
самое

3
осторожно, поскольку хранилище сеансов копируется в новую вкладку, когда пользователь выбирает «открыть в новой вкладке» ... хотелось бы, чтобы у меня была ссылка для подробностей, но см .: bugzilla.mozilla.org/show_bug.cgi?id=818389
felickz

2
Имейте в виду, что то, что вы сохраните в настройке window.name, будет по-прежнему доступно в других доменах, когда пользователь перейдет на другие страницы в той же вкладке.
Накиб

15

Ты не должен.Если вы хотите сделать такую ​​вещь, либо вам нужно заставить пользователя использовать один экземпляр вашего приложения, записывая URL-адреса «на лету», используя идентификатор sessionID (а не sessionid, он не будет работать) id и передавая его в каждом URL-адресе.

Я не знаю, зачем вам это нужно, но если вам не нужно создать совершенно непригодное приложение, не делайте этого.


9
Это для большого приложения, которое хранит пользовательскую информацию и окружающую среду. Когда кто-то входит в систему с разными пользователями на разных вкладках, для тестирования или для разных ролей, он пересекает информацию из вкладок.
Oriol Terradas

38
Старый ответ, я знаю, но почта Google позволяет вам иметь разные учетные записи на вкладке, и это не «совершенно непригодное для использования приложение»
Джордж

2
@George, ответ по-прежнему правильный, и для вашего примера вы увидите, что в URL-адресе представлен индекс учетных записей, хранящихся в файлах cookie, Google Mail просто хранит все файлы cookie и выберите один из них в соответствии с URL-адресом.
Ммм

5
Не уверен, что ответ по-прежнему правильный, вы явно можете это сделать. Gmail делает это. Что касается того, как он это делает, это может быть не элегантно, но это работает, и вот что важно
Джордж

2
Старый ответ, но я могу добавить, что WhatsApp и Telegram не позволяют открывать две вкладки одновременно. Это не делает их непригодными для использования
Чарли

13

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

Используйте 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-адреса. Убедитесь, что вы четко указываете на каждой вкладке, кто вошел в эту вкладку, хотя ...


6
+1 потому что вы нашли время, чтобы действительно обдумать это! :-) Глядя на все предостережения, вы просто знаете, что это плохая идея. Мой урок, извлеченный из этого материала, заключается в том, чтобы по-настоящему понять, какие данные должны входить в сессии, а какие - нет.
Питер

10

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

Таким образом, решение было случайных поддоменов.

23423.abc.com
242234.abc.com
235643.abc.com

Поэтому мы попросили нашего системного администратора настроить SSL-сертификаты для * .abc.com, а не для abc.com. После небольшого изменения кода каждый раз, когда пользователь пытается войти в систему, он попадает на вкладку со случайным номером субдомена. поэтому каждая вкладка может иметь свою собственную сессию независимо. Также, чтобы избежать любого конфликта, мы разработали случайное число, используя хэш или md5 идентификатора пользователя.


3
Это похоже на умную альтернативу перезаписи URL. В результате вы получаете нужную переменную (идентификатор сеанса) в HTTP-совместимом месте, которое видно, но не навязчиво. Nits, которые приходят на ум: 1) нужен подстановочный знак в DNS, очевидно, 2) весь ваш веб-сайт должен избегать любых абсолютных URL-адресов, которые могли бы перенаправить пользователя назад (например, к поддомену "www", 3) возможно, хотят запретить поиск веб-сканеров , но это, вероятно, ситуация в частной сети, так что это может быть уже сделано. Спасибо, что поделились этим!
Рон Берк

@ user3534653: Мне нравится подход. Но вы сказали: «Нет программирования». Затем вы продолжаете говорить «с небольшим изменением кода». Так действительно, небольшое изменение кода не программирование? ;) Кроме того, этот подход может не работать, если у вас есть несколько приложений с каноническими ссылками, где домен жестко задан / настроен (канонически).
Стефан Штайгер

5

Я буду честен здесь. , , все вышеперечисленное может быть или не быть правдой, но все это кажется СЛИШКОМ СЛОЖНЫМ или не учитывает знание того, какая вкладка используется на стороне сервера.

Иногда нам нужно применить бритву Оккама.

Вот подход Оккама: (нет, я не Оккам, он умер в 1347 году)

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

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

3) в вашей функции фокуса (и / или наведения мыши) установите cookie с окном window.name

4) читать значение cookie со стороны вашего сервера, когда вам нужно прочитать / записать данные, относящиеся к вкладке.

Сторона клиента:

//Events 
$(window).ready(function() {generateWindowID()});
$(window).focus(function() {setAppId()});
$(window).mouseover(function() {setAppId()});


function generateWindowID()
{
    //first see if the name is already set, if not, set it.
    if (se_appframe().name.indexOf("SEAppId") == -1){
            "window.name = 'SEAppId' + (new Date()).getTime()
    }
    setAppId()
}

function setAppId()
{
    //generate the cookie
    strCookie = 'seAppId=' + se_appframe().name + ';';
    strCookie += ' path=/';

    if (window.location.protocol.toLowerCase() == 'https:'){
        strCookie += ' secure;';
    }

    document.cookie = strCookie;
}

сторона сервера (C # - для примера)

//variable name 
string varname = "";
HttpCookie aCookie = Request.Cookies["seAppId"];
if(aCookie != null) {
     varname  = Request.Cookies["seAppId"].Value + "_";
}
varname += "_mySessionVariable";

//write session data 
Session[varname] = "ABC123";

//readsession data 
String myVariable = Session[varname];

Готово.


1
Мне очень нравится ваш упрощенный ответ и ссылка на бритву Оккама. Просто хотел дважды проверить, что это решение все еще работает для вас.
Джефф Марино

1
Стоит отметить, что если обновление страницы продолжит свою сессию, такой подход не будет работать. Другой предложенный подход в другом ответе об использовании window.sessionStorage мне кажется более разумным.
Розенфельд

@quijibo Все еще отлично работает в моем приложении, да. Что касается обновления страницы, может быть верно для некоторых браузеров, использование window.sessionStorage может решить проблему, не пытаясь ее решить
Майк А.

3
Что такое функция "se_appframe ()"?
АндреМиранда

Что такое se_appframe ?
Kiquenet

2

Вы можете использовать переписывание ссылок, чтобы добавить уникальный идентификатор ко всем вашим URL-адресам, когда начинаете с одной страницы (например, index.html / jsp / что угодно). Браузер будет использовать одни и те же файлы cookie для всех ваших вкладок, поэтому все, что вы помещаете в файлы cookie, не будет уникальным.


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

2

Я думаю, что вы, вероятно, хотите, чтобы поддерживать состояние навигации по вкладкам, а не специально создавать один сеанс для каждой вкладки. Это именно то, чего достигает платформа Seam с их контекстом / контекстом беседы. Их реализация основана на том факте, что идентификатор диалога распространяется с каждым запросом и создает понятие диалога на стороне сервера, которое находится между сеансом и запросом. Это позволяет контролировать поток навигации и управление состоянием.

Хотя это в основном нацелено на JSF, посмотрите и проверьте, можете ли вы кое-что почерпнуть из: http://docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620


2

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

По существу используйте window.name. Если он не установлен, установите для него уникальное значение и используйте его. Это будет отличаться для разных вкладок, которые принадлежат одному сеансу.


1

Другой подход, который работает, состоит в том, чтобы создать уникальный идентификатор окна и сохранить это значение вместе с идентификатором сеанса в таблице базы данных. Идентификатор окна, который я часто использую, является целым числом (сейчас). Это значение создается, когда окно открывается и переназначается тому же окну, если оно обновляется, перезагружается или передается самому себе. Значения окна (входы) сохраняются в локальной таблице по ссылке. Когда значение требуется, оно получается из таблицы базы данных на основе ссылки идентификатора окна / идентификатора сеанса. Хотя этот подход требует локальной базы данных, он практически надежен. Мне было легко использовать таблицу базы данных, но я не вижу причин, по которым локальные массивы не будут работать так же хорошо.


1

Недавно я разработал решение этой проблемы с помощью файлов cookie. Вот ссылка на мое решение. Я также включил пример кода решения с использованием ASP.NET, вы сможете адаптировать его к JSP или сервлетам, если вам нужно.

https://sites.google.com/site/sarittechworld/track-client-windows



1

Примечание: решение здесь должно быть сделано на этапе разработки приложения. Было бы сложно спроектировать это позже.

Используйте скрытое поле для передачи идентификатора сеанса .

Для этого на каждой странице должна быть форма:

<form method="post" action="/handler">

  <input type="hidden" name="sessionId" value="123456890123456890ABCDEF01" />
  <input type="hidden" name="action" value="" />

</form>

Каждое действие на вашей стороне, включая навигацию, отправляет форму обратно (при actionнеобходимости). Для «небезопасных» запросов вы можете включить другой параметр, например, содержащий значение JSON данных, которые будут отправлены:

<input type="hidden" name="action" value="completeCheckout" />
<input type="hidden" name="data" value='{ "cardNumber" : "4111111111111111", ... ' />

Поскольку нет файлов cookie, каждая вкладка будет независимой и не будет знать о других сеансах в том же браузере.

Много преимуществ, особенно когда речь идет о безопасности:

  • Не зависит от JavaScript или HTML5.
  • По своей сути защищает от CSRF .
  • Не зависит от печенья, поэтому защищает от пуделя .
  • Не уязвим для фиксации сессии .
  • Может предотвратить использование кнопки «Назад», что желательно, если вы хотите, чтобы пользователи следовали по заданному пути через ваш сайт (это означает, что могут быть предотвращены логические ошибки, которые иногда могут быть атакованы неправильными запросами).

Некоторые недостатки:

  • Функциональность кнопки Назад может быть желательной.
  • Не очень эффективно с кэшированием, так как каждое действие - это ПОЧТА.

Дополнительная информация здесь .


1

Я решил это следующим образом:

  • Я назначил имя окну, это имя ресурса подключения.
  • плюс 1, чтобы избавиться хранится в куки для подключения вложения.
  • Я создал функцию для захвата всех ответов xmloutput и назначения sid и rid для cookie в формате json. Я делаю это для каждого окна.

вот код:

var deferred = $q.defer(),
        self = this,
        onConnect = function(status){
          if (status === Strophe.Status.CONNECTING) {
            deferred.notify({status: 'connecting'});
          } else if (status === Strophe.Status.CONNFAIL) {
            self.connected = false;
            deferred.notify({status: 'fail'});
          } else if (status === Strophe.Status.DISCONNECTING) {
            deferred.notify({status: 'disconnecting'});
          } else if (status === Strophe.Status.DISCONNECTED) {
            self.connected = false;
            deferred.notify({status: 'disconnected'});
          } else if (status === Strophe.Status.CONNECTED) {
            self.connection.send($pres().tree());
            self.connected = true;
            deferred.resolve({status: 'connected'});
          } else if (status === Strophe.Status.ATTACHED) {
            deferred.resolve({status: 'attached'});
            self.connected = true;
          }
        },
        output = function(data){
          if (self.connected){
            var rid = $(data).attr('rid'),
                sid = $(data).attr('sid'),
                storage = {};

            if (localStorageService.cookie.get('day_bind')){
              storage = localStorageService.cookie.get('day_bind');
            }else{
              storage = {};
            }
            storage[$window.name] = sid + '-' + rid;
            localStorageService.cookie.set('day_bind', angular.toJson(storage));
          }
        };
    if ($window.name){
      var storage = localStorageService.cookie.get('day_bind'),
          value = storage[$window.name].split('-')
          sid = value[0],
          rid = value[1];
      self.connection = new Strophe.Connection(BoshService);
      self.connection.xmlOutput = output;
      self.connection.attach('bosh@' + BoshDomain + '/' + $window.name, sid, parseInt(rid, 10) + 1, onConnect);
    }else{
      $window.name = 'web_' + (new Date()).getTime();
      self.connection = new Strophe.Connection(BoshService);
      self.connection.xmlOutput = output;
      self.connection.connect('bosh@' + BoshDomain + '/' + $window.name, '123456', onConnect);
    }

Я надеюсь помочь тебе


0

Я читал этот пост, потому что думал, что хочу сделать то же самое. У меня похожая ситуация для приложения, над которым я работаю. И на самом деле это вопрос тестирования больше, чем практичность.

Прочитав эти ответы, особенно ответ, который дал Майкл Боргвардт, я понял, какой рабочий процесс должен существовать:

  1. Если пользователь переходит к экрану входа, проверьте существующий сеанс. Если существует, обойдите экран входа в систему и отправьте их на экран приветствия.
  2. Если пользователь (в моем случае) переходит к экрану регистрации, проверьте существующий сеанс. Если он существует, сообщите пользователю, что вы собираетесь выйти из сеанса. Если они согласны, выйдите из системы и начните регистрацию.

Это решит проблему, когда пользователь увидит данные «другого пользователя» в своем сеансе. Они на самом деле не видят данные «другого пользователя» в своем сеансе, они действительно видят данные из единственного открытого сеанса. Очевидно, что это вызывает некоторые интересные данные, так как некоторые операции перезаписывают одни данные сеанса, а не другие, поэтому у вас есть комбинация данных в этом единственном сеансе.

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

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

Так что я думаю, что должен сказать, что в конечном итоге это плохая идея.


0

Сохранение метки времени в window.sessionStorage, если она еще не установлена. Это даст уникальное значение для каждой вкладки (даже если URL-адреса одинаковы)

http://www.javascriptkit.com/javatutors/domstorage.shtml

https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage

Надеюсь это поможет.


1
Это, вероятно, хорошо, но теоретически небезопасно. Некоторые операционные системы (например, Windows) имеют очень грубую детализацию временных меток, что означает, что вы можете искать временную метку несколько раз и возвращать одно и то же значение. Более того, если вы снова откроете браузер после сбоя, и он сразу откроет все вкладки, они могут получить одинаковую временную метку.
Гили

0
How to differ sessions in browser-tabs?

Самый простой способ различать сеансы на вкладках браузера - запретить настройку файлов cookie в вашем конкретном домене. Таким образом, вы можете иметь отдельные сессии из отдельных вкладок. Скажем, вы запрещаете куки с этого домена: www.xyz.com. Вы открываете Tab 1, авторизуетесь и начинаете просмотр. Затем вы открываете Tab 2, и вы можете войти в систему как тот же пользователь или другой; в любом случае у вас будет сеанс, отдельный от Tab 1. И так далее.

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


0

вам нужно будет сделать

1- сохранить куки для списка аккаунтов

2 - опционально хранить куки для файлов по умолчанию

3 - хранить для каждой учетной записи с индексом, таким как acc1, acc2

4 - введите в URL-адрес что-то, представляющее индекс учетных записей, и если нет, вы выберете индекс по умолчанию, например, gmail mail domain.com/0/some-url >> 0, здесь представлен индекс учетной записи, также вам может понадобиться узнать, как использовать urlwrite

5 - при выборе файла cookie выберите его в соответствии с вашим URL-адресом, представляющим индекс учетной записи.

С уважением


0

Я вижу много реализаций, в которых есть изменения на стороне клиента для манипулирования куки-файлами идентификатора сессии. Но в общем случае куки с идентификатором сессии должны быть HttpOnly, чтобы java-скрипт не мог получить к ним доступ, иначе это может привести к перехвату сессии через XSS


0

Если это связано с тем, что на каждой вкладке будет выполняться отдельный поток в вашем приложении, а смешивание обоих потоков вызывает проблемы, то лучше «регионализировать» объекты сеанса, чтобы каждый поток использовал свою область сеанса.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.