Предотвращение нескольких сеансов браузера на той же сессии сервера
Я уверен, что мы все продолжили работать или знаем о веб-приложениях (особенно на предприятии), которые плотно связали себя с сессией сервера. В этих случаях возможно, что сессия станет поврежденной, если больше чем один сеанс браузера будет открыт и использовать те же сеансовые куки сервера. Мы исследовали все опции и нашли, что лучший способ продвинуться состоял бы в том, чтобы препятствовать использованию нескольких сеансов браузера, которые совместно используют сеансовые куки сервера.
Это - только действительно проблема, когда пользователь выполняется New Window - Ctrl+N в IE или эквиваленте "дублирующейся вкладки" в других браузерах. По существу мы заканчиваем с двумя активными сеансами браузера, совместно использующими те же cookie.
Так, для воспрепятствования этого (поскольку это, вероятно, будет непреднамеренным), я намеревался помещать некоторую систему предупредительной сигнализации на месте для предотвращения этого поведения. Теперь, наш код делает много проверки параллелизма для обеспечения целостности данных, но могут все еще быть проблемы с повреждением данных.
Мое решение, после нахождения, что общий ответ, "это невозможно", должен был полагаться на Ajax, чтобы отослать "ping" и измерить время между. Так, у нас есть общее правило: мы "проверяем с помощью ping-запросов" в определенном интервале и если дельта между последним ping в текущем ping является меньше, чем продолжительность ping, мы знаем, что у нас есть несколько активных сеансов браузера на единственной сессии сервера.
Так, где Pf частота отправки; Pc текущий ping; и Pl последний ping, затем у нас есть ошибка когда Pf > (Pc - Pl).
p1 p2 p3 p4
TAB1 0-----|-----|-----|-----|---...
: : :
: p1 : p2 : p3 p4
TAB2 0-----|-----|-----|-----|---...
^ ^ ^ ^ ^ ^ ^ ^
Deltas
----+---+------------ TAB | P | Delta (Pc - Pl) ----+---+------------ 1 | 1 | 5 1 | 2 | 5 2 | 1 | 2.5 -Error 1 | 3 | 2.5 -Error 2 | 2 | 2.5 -Error
Теперь, если будет перегрузка сети или другие факторы, то дельта будет больше, чем частота, исключая ложные положительные стороны.
У нас действительно есть проблема, если две вкладки открыты в том же самом momemnt. Но, так как частота отправки является просто частотой, на которой запросы выполнены, и не гарантируемое прошедшее время, мы можем предположить, что скоро эти два сеанса браузера начнут скользить из синхронизации.
В примере мне установили частоту отправки на каждые 5 секунд. Если существует 100 одновременных пользователей затем, мы смотрим на ~20 запросов/секунда на ping Servlet/HttpModule. Для уменьшения ненужного сетевого трафика, я думал, что частота отправки затухнет с течением времени, пока максимум 20 ping/секунда не был достигнут. Это составило бы ~5 запросов/секунда с 100 параллельными пользователями. Это - компромисс, тем не менее, поскольку он вызовет задержку обнаружения. Однако, после того как обнаружение происходит, сброс частоты к 5 ping/секунда, пока не разрешено. (Эти числа так же, как пример; они варьировались бы на основе среды),
Для уменьшения параллелизма и проблем масштабируемости последняя метка времени ping для сессии должна быть сохранена на самой сессии. Это позволит любой распределенной технологии сессии поддерживать доступность сессии через JVMs или домены приложения без нашего сервиса ping, бывшего должного знать о нем.
Я пытаюсь определить, является ли это звуковым подходом того, если я нахожусь в для мира вреда. Любой опыт с проблемой был бы полезен.
Править: Я знаю, что это походит на лейкопластырь, но это предназначено, чтобы быть временной мерой, пока мы не можем сорвать незаконную библиотеку.
4 ответа
Я работал над веб-приложением одного окна много лет назад (предварительно знакомства «Web 2.0»). Мы просто запустили новое окно без каких-либо панелей инструментов (нет кнопки назад, и т. Д.) и отключена правой кнопкой мыши. Мы позаботились, чтобы создать очень удобную навигационную систему в сессии. Этого было достаточно, чтобы предотвратить практически все случайные дублирующие просмотр. Это было приложение интрасети; Очевидно, я бы никогда не рекомендую ничего делать подобное на общем сайте.
Лично мне не нравится звук детектора Ping. Я бы просто убедился, что коррупция данных не может произойти. Несколько сеансов браузера не является действительным оправданием для этого ... хотя я понимаю, как это может быть проблематично. Но если вы хотите добавить детектор Ping на вершине идеально рабочего кода, то он может служить полезным напоминанием пользователю.
Вы можете добавить уникальный токен до конца каждой ссылки. Если уникальный токен используется более одного раза (например, открытие нового окна, закладки, обратно, вперед), то запрос можно отрицать. С надлежащим отслеживанием вы можете убедиться, что никогда не можно добраться от одной страницы другому, не принимая действительный путь. Этот подход более надежен, чем пинг (как он контролируется сервером), но может привести к очень раздражающему опыту пользователя.
Короче говоря: исправьте свое приложение, чтобы не повредить какие-либо данные. Я знаю, что это не может быть тривиальной вещью, и я не хочу сделать свет этого. Реализуя пинги и такое может помочь, чтобы проблема исчезла, но я гарантирую вам, что если что-то может пойти не так, это в конечном итоге будет. : -)
Если вы действительно находитесь в привязке и не можете исправить приложение, чтобы в здравом уме обрабатывать несколько экземпляров браузера, использующих один и тот же сеанс, то да, это разумный подход.
Для того, что бы это ни стоило, я использовал точно такую же концепцию, чтобы ввести в действие лицензионные ограничения на одновременное использование - так что оно будет обнаруживать несколько пользователей, разделяющих один и тот же "ключ", который в вашем случае является сеансом.
Я бы слегка изменил ваш подход, и чтобы ping-сообщение содержало дату/время клиента - так вы сможете вообще избежать сетевых задержек в ваших вычислениях.
Моя основная проблема - не будет ли это скомпрометировано при задержке сети. То есть, любые проблемы, вероятно, будут возникать из-за проблем, для решения которых обычно используется пинг.
Это идеальный случай для класса Package Worker в .NET. Он использует пул резьбы для выполнения потенциально длительных операций на заднем плане, поэтому вызывающий абонент не должен иметь дело с индивидуальным кодом создания потоков.
-121--5044540-Очень простое решение, которое вы можете или не сможете использовать, является одной страницей (т. Е. Один URL, такой как Home.whatever) для приложения AJAX. Если они просят эту же страницу во второй раз и уже есть действительная сессия, то вы знаете, что открыли новую вкладку или новое окно. Обратите внимание, что вы не сможете отличить это от обновления.
Ваше решение слишком сложное.