Як відрізняти сеанси у вкладках браузера?

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), введіть своє ім’я у введенні та подайте форму. Потім відкрийте нову вкладку в тому самому веб-переглядачі, і тоді ви зможете побачити своє ім’я (отримати з сеансу) на новій вкладці. Будьте обережні з кешем браузера, іноді здається, що цього не відбувається, але це в кеші, оновіть другу вкладку.

Дякую.

jsp  servlets  browser  web-applications  sessionid 
— Оріол Террадас
джерело
— Bozho
1
Користувач повинен зробити це: відкрити IE, натиснути "Файл-> Нова сесія"
— Stefan Steiger
3
@ Quandary, ваше рішення не є загальним рішенням (в інших браузерах не працює) і, головне, це не є зручним для користувачів (користувачі не знають про сеанси).
— Оріол Террадас
2
Деякі люди, здається, не можуть уявити, яка мета цього. Проблемний домен - це найбільше будь-яка ситуація, в якій ви хочете дозволити різні "погляди" вашого веб-сайту. Після того, як користувач може мати більше одного перегляду вашого веб-сайту, він неминуче довго (або випадково намагається) отримати доступ до двох різних переглядів одночасно. Приклади включають: тимчасову версію (перехід на перегляд веб-сайту таким, який він існував у певний момент минулого); пісочниця (внесення змін до веб-сайту інші ще не бачать); погляди на основі ролей (дивіться, як веб-сайт виглядає менш привілейованому користувачеві); пр.
— Рон Берк

Відповіді:

92

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

Дані, що зберігаються за допомогою sessionStorage, не зберігаються на вкладках веб-переглядача, навіть якщо обидва вкладки містять веб-сторінки одного і того ж походження домену. Іншими словами, дані всередині sessionStorage обмежуються не лише доменом та каталогом сторінки, що викликає, а вкладкою браузера, в якій міститься сторінка.

— Гонсало Галлотті
джерело
7
З документів: "Дані, що зберігаються за допомогою sessionStorage, не зберігаються на вкладках браузера, навіть якщо обидві вкладки містять веб-сторінки одного і того ж походження домену. Іншими словами, дані всередині sessionStorage обмежуються не лише доменом і каталогом сторінки, що викликає, але й вкладку браузера, в якій міститься сторінка. На противагу цьому файли cookie сеансу, які зберігають дані з вкладки на вкладку. Просте тестування підтверджує таку поведінку в Chrome та FF.
— jswanson
21
Зауважте, ідентифікатор буде дублюватися при використанні функції "Дублікат вкладки" Chrome. Зазвичай це не проблема, але це слід продумати.
— JosiahDaniels
За винятком випадків, коли ви "копіюєте" вкладку в Chrome або Firefox. У цьому випадку копіюється SessionStorage.
— Тіаго Фрейтас Ліал
@Gonzalo Gallotti: І як це допоможе мені, якщо сеанс буде на сервері? )))
— Стефан Штайгер
@StefanSteiger. Потім ви можете надіслати ідентифікатор BrowserTab (збережений у сховищі сеансів) за допомогою Ajax Call. На стороні сервера вам потрібна спеціальна логіка, оскільки WebSession - це те саме. Але ви можете створити HashMap з об’єктами сесії за вкладками.
— Гонсало
23

Ви повинні усвідомити, що сеанси на стороні сервера - це штучне доповнення до HTTP. Оскільки HTTP не має статусу, сервер повинен якось визнати, що запит належить певному користувачеві, якого він знає і для якого є сеанс. Є два способи зробити це:

  • Печиво. Чистіший і популярніший метод, але це означає, що всі вкладки та вікна браузера одним користувачем діляться сеансом - IMO це насправді бажано, і я був би дуже роздратований на сайті, який змусив мене ввійти в кожну нову вкладку, оскільки я користуйтеся вкладками дуже інтенсивно
  • Переписування URL-адрес. До будь-якої URL-адреси веб-сайту додається ідентифікатор сеансу. Це більше роботи (вам потрібно щось робити скрізь, коли у вас є посилання на сайт), але це дозволяє проводити окремі сеанси на різних вкладках, хоча вкладки, відкриті через посилання, все ще поділяться сеансом. Це також означає, що користувач повинен завжди входити в систему, коли він заходить на ваш сайт.

Що ти все-таки намагаєшся зробити? Чому ви хочете, щоб вкладки мали окремі сеанси? Може бути, є спосіб досягти своєї мети, не використовуючи сеансів взагалі?

Редагувати: для тестування можна знайти інші рішення (наприклад, запуск декількох екземплярів браузера на окремих ВМ). Якщо одному користувачеві потрібно одночасно діяти в різних ролях, то в додатку слід обробляти концепцію "ролі", щоб один логін міг мати кілька ролей. Вам доведеться вирішити, чи це, використовуючи перезапис URL-адрес, або просто жити в поточній ситуації, є більш прийнятним, оскільки просто не можна обробляти вкладки браузера окремо за допомогою сеансів на основі файлів cookie.

— Майкл Боргвардт
джерело
6
Це для великого додатка, який зберігає інформацію про користувачів та навколишнє середовище. Коли хтось входить із різними користувачами на вкладки "різні", для тестових або для різних ролей, він пересилає інформацію з вкладок.
— Оріол Террадас
Просто дуже пізнє доповнення, чому: тому що мені потрібно це знати, щоб знати, ЯКА сторінка на моєму веб-сайті, наприклад, зосереджений користувач, а не лише те, що вони перейшли зі сторінки на сторінку ( замість цього вони перейшли від вкладки до вкладки).
— Олівер Вільямс
16

Властивість JavaScript.name window.name - це єдине, що зберігатиметься протягом всієї вкладки, але може залишатися незалежним (замість URL-адреси guff).

— Дейв Біш
джерело
3
window.sessionStorage робить також
— felickz
3
обережно, оскільки зберігання сеансу копіюється на нову вкладку, коли користувач вибирає "відкрити в новій вкладці" ... хочете, щоб у мене було посилання для деталей, але дивіться: bugzilla.mozilla.org/show_bug.cgi?id=818389
— felickz
2
Майте на увазі, що те, що ви зберігаєте в налаштуваннях window.name, все одно буде доступне в інших доменах, коли користувач перейде на інші сторінки на тій самій вкладці.
— nakib
15

Ви не повинні.Якщо ви хочете зробити таке, вам або потрібно змусити користувача використовувати один екземпляр вашої програми, записуючи URL-адреси на льоту, використовуйте ідентифікатор sessionID (не сесійний він не буде працювати) і передавати його в кожну URL-адресу

Я не знаю, навіщо вам це потрібно, але якщо вам не потрібно зробити абсолютно непридатну програму, не робіть цього.

— лікар. зло
джерело
9
Це для великого додатка, який зберігає інформацію про користувачів та навколишнє середовище. Коли хтось входить із різними користувачами на вкладки "різні", для тестових або для різних ролей, він пересилає інформацію з вкладок.
— Оріол Террадас
38
стара відповідь Я знаю, але пошта Google дозволяє вам мати різні облікові записи на вкладці, і це не "абсолютно непридатний додаток"
— Джордж
2
@George, Відповідь все-таки правильна, і для вашого прикладу ви побачите, що в URL-адресі відображається індекс облікових записів, що зберігаються у файлах cookie, Google Mail просто зберігає всі файли cookie та вибираєте його відповідно до URL-адреси.
— Mhmd
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 для входу на масив, а потім на зберігання та перед тим, як надсилати новий запит на вхід, скасуйте всі поточні запити.

Остання зміна, на яку слід звернути увагу, - оновлення вікон. Якщо хтось оновлює вікно, поки у вас активний запит на вхід у AJAX, але не завершено, воно буде оновлено від імені невірної особи. У цьому випадку ви можете використовувати нестандартну подію перед завантаженням, щоб попередити користувача про потенційну суміш і попросити їх натиснути Скасувати, тим часом повторно видавши запит на вхід у AJAX. Тоді єдиний спосіб їх отримати - це натиснути кнопку "ОК" до завершення запиту (або випадково натиснувши клавішу введення / пробіл, тому що ОК - на жаль, для цього випадку - за замовчуванням.) Є й інші способи вирішення цього випадку, наприклад виявлення натискань F5 і Ctrl + R / Alt + R, які працюватимуть у більшості випадків, але можуть бути порушені переналаштуванням комбінації клавіш користувача або альтернативним використанням ОС. Однак це насправді є кращим випадком, і найгірші сценарії випадків ніколи не такі погані: у конфігурації системи честі ви входите в систему як неправильна особа (але ви можете зробити очевидним, що це так, персоналізуючи сторінки з кольорами, стилями, помітними іменами, тощо); у конфігурації пароля onus є останньою особою, яка ввела свій пароль, щоб вийти або поділитися своїм сеансом, або якщо ця особа фактично є поточним користувачем, порушень немає.

Але врешті-решт у вас є програма "один користувач на вкладку", яка (сподіваємось) просто діє як слід, без необхідності встановлювати профілі, використовувати IE або переписувати URL-адреси. Переконайтеся, що ви робите це очевидним у кожній вкладці, хто увійшов у цю конкретну вкладку, хоча ...

— Кев
джерело
6
+1, тому що ви знайшли час, щоб по-справжньому продумати це! :-) Дивлячись на всі застереження, ти просто знаєш, що це погана ідея. Мої уроки, отримані з цього матеріалу, - це по-справжньому зрозуміти, які дані слід переходити на сеанси, а які - не.
— Пітер
10

У нас була ця проблема, і ми її вирішили дуже легко. Я маю на увазі просто, тому що програмування не бере участь. Ми хотіли зробити це - дозволити користувачеві увійти до кількох облікових записів у одному вікні браузера, не суперечивши сеансам.

Тож рішенням були випадкові субдомени.

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

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

— користувач3534653
джерело
3
Це здається розумною альтернативою переписування URL-адрес. Ви отримуєте потрібну змінну (ідентифікатор сеансу) у відповідному HTTP-місці, яке видно, але не нав'язливо. Ніти, які ведуть на думку: 1) потрібна підстановка на DNS, очевидно, 2) весь ваш веб-сайт повинен уникати абсолютних URL-адрес, які б перенаправляли користувача до (наприклад, "субдомену" www ", 3), ймовірно, хочуть уникнути веб-сканерів. , але це, мабуть, ситуація в приватному Інтернеті, щоб це вже було зроблено. Дякуємо, що поділилися цим!
— Рон Берк
@ user3534653: Мені подобається підхід. Але ви сказали, що "програмування не пов'язане" Потім ви продовжуєте говорити "з невеликою зміною коду". Так дійсно, невелика зміна коду - це не програмування? ;) Крім того, такий підхід може не працювати, якщо у вас є кілька додатків з канонічними посиланнями, де домен жорстко закодований / налаштований (канонічно).
— Стефан Штайгер
5

Я буду чесним тут. . . все вище може бути, а може і не бути правдою, але все це здається ДОБАВНО занадто складним, або не звертається до відома, на якій вкладці використовується сторона сервера.

Іноді нам потрібно застосувати бритву Occam.

Ось підхід Occam: (ні, я не Оккам, він помер у 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
Мені дуже подобається ваша спрощена відповідь та посилання на бритву Occam. Просто хотів ще раз перевірити, чи це рішення все ще працює для вас.
— Джефф Маріно
1
Варто зауважити, що якщо оновлення сторінки буде продовжено сеанс, такий підхід не буде працювати. Інший запропонований підхід в іншій відповіді про використання window.sessionStorage мені здається більш розумним.
— rosenfeld
@quijibo Все ще прекрасно працює в моєму додатку, так. Що стосується оновлення сторінки, можливо, це стосується деяких браузерів, використовуючи window.sessionStorage може вирішити проблему, не пробували
— Майк А.
3
Що таке функція "se_appframe ()"?
— AndreMiranda
Що таке se_appframe ?
— Кікенет
2

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

— Бомбе
джерело
2
Я вважаю, що переписування посилань для кодування сеансів є втомливим та схильним до помилок. У мене великий додаток, з великою кількістю посилань, мені потрібно прозоре рішення або просте втілення.
— Оріол Террадас
2

Я думаю, що вам, мабуть, хочеться підтримувати стан навігації на вкладках, а не спеціально створювати один сеанс на вкладку. Це саме те, що досягається рамкою Шва за допомогою їхньої сфери / контексту розмови. Їх реалізація покладається на те, що ідентифікатор розмови поширюється з кожним запитом і створює поняття розмови на стороні сервера, що лежить між сеансом і запитом. Це дозволяє здійснювати управління потоком навігації та управління державою.

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

— lsoliveira
джерело
2

Як у javascript можна однозначно ідентифікувати одне вікно браузера від іншого, яке знаходиться під тим самим cookied-базі sessionId

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

— аккішор
джерело
1

Інший підхід, який працює - це створити унікальний ідентифікатор вікна та зберегти це значення разом із ідентифікатором сеансу в таблиці бази даних. Ідентифікатор вікна, який я часто використовую, є цілим числом (зараз). Це значення створюється, коли вікно відкривається та присвоюється йому в тому ж вікні, якщо вікно оновлено, перезавантажено або подано до себе. Значення вікон (входи) зберігаються в локальній таблиці за допомогою посилання. Коли потрібне значення, воно отримується з таблиці бази даних на основі ідентифікатора вікна / ідентифікатора сесії. Хоча цей підхід вимагає локальної бази даних, він практично захищений від дурня. Використання таблиці баз даних було для мене легко, але я не бачу причини, щоб локальні масиви не працювали так само добре.

— Стівен
джерело
1

Нещодавно я розробив рішення цієї проблеми за допомогою файлів cookie. Ось посилання на моє рішення. Я також включив зразок коду рішення за допомогою ASP.NET, ви повинні мати можливість адаптувати це до JSP або Servelets, якщо вам потрібно.

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.
  • По суті захищає від КСФР .
  • Не покладається на файли cookie, тому захищає від POODLE .
  • Не вразливий для фіксації сеансу .
  • Може запобігти використанню кнопки "Назад", що бажано, коли ви бажаєте, щоб користувачі дотримувались встановленого шляху через ваш сайт (а це означає, що логічні помилки, які іноді можуть бути атаковані запитами поза замовленням, можуть бути уникнені).

Деякі недоліки:

  • Функція кнопки "Назад" може бути бажаною.
  • Не дуже ефективний при кешуванні, оскільки кожна дія - це ПОСТ.

Додаткову інформацію тут .

— SilverlightFox
джерело
1

Я вирішив це таким чином:

  • Я призначив ім'я вікну, це ім'я є тим самим ресурсом з'єднання.
  • плюс 1, щоб позбутися збереженого в файлі cookie для з'єднання приєднання
  • Я створив функцію для збору всієї відповіді xmloutput та призначення sid та rid cookie у форматі json. Я роблю це для кожного window.name.

тут код:

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/javatators/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. Таким чином, ви можете мати окремі сеанси з окремих вкладок. Скажімо, ви забороняєте cookie з цього домену: www.xyz.com. Ви відкриєте Tab 1, увійдете в систему та розпочніть перегляд. Потім ви відкриєте Tab 2, і ви можете увійти або як той самий користувач, або інший; в будь-якому випадку, у вас буде сеанс окремо від вкладки 1. І так далі.

Але звичайно це можливо, коли ви маєте контроль над стороною клієнта. В іншому випадку повинні застосовуватися розчини, прописані людьми.

— Кінгз
джерело
0

вам потрібно буде зробити

1- зберігати файл cookie для списку облікових записів

2- необов'язково зберігати файл cookie за умовчанням

3- зберігати для кожного облікового запису з його індексом, як acc1, acc2

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

5- Коли ви вибираєте файл cookie, виберіть його відповідно до вашого URL-адреси, що представляє індекс облікового запису

З повагою

— Mhmd
джерело
0

Я бачу багато реалізацій, які мають зміни на стороні клієнта для маніпулювання файлами cookie-сеансів. Але загалом файли cookie id сесії повинні бути HttpOnly, тому java-скрипт не може отримати доступ, інакше це може призвести до сеансу Hijack через XSS

— vasa.v03
джерело
0

Якщо це стосується того, що кожна вкладка буде виконувати різний потік у вашій програмі, а змішування обох потоків спричиняє проблеми, тоді краще "регіоналізувати" об'єкти сеансу, щоб кожен потік використовував іншу область сеансу

Цей регіон може бути реалізований так само, як і різні префікси для кожного потоку, або об’єкт сеансу буде містити кілька карт (по одному для кожного потоку), і ви використовуєте ці карти замість атрибутів сеансу, найкраще було б розширити свій клас сеансу та використовувати замість цього.

— hussein.g
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.