Идентификатор сеанса ASP.NET, общий доступ к вкладкам браузера

Question

Я недавно разрабатывал веб-сайт с использованием веб-форм asp.net, который используется в сеансах proc, и я заметил, что идентификаторы сеансов распределены между вкладками браузера. Так что мне было интересно, что вы могли бы сделать для следующих ситуаций:

Проблема: несколько логинов с различными пользователями в задаче один браузер

1. открывает пользователя вкладку браузера 1, логины с «user1» - магазин в сессии
2. Пользователь открывает вкладку браузера 2, логины с «user2» - магазин в сессии
3. на этом этапе информация сеанса теперь указывает на «user2» из-за того, как идентификатор сеанса разделяется утра ongst браузер вкладки
4. Пользователь пытается действие на вкладке 1 и вдруг у них есть «user2» информация

Как вы оповещает пользователя на вкладке 1, что пользователь изменил или как заставить пользователя Tab1 выйти из системы?

Моя первоначальная мысль состояла в том, чтобы сохранить список активных пользователей с идентификатором сеанса через базу данных или объект приложения, но проблема, с которой я сталкиваюсь, заключается в том, что на вкладке 1, что я буду сравнивать с этим списком, когда я делаю запрос HttpContext.Current.User будет обновляться с «user2» как я знаю вкладки браузера 1 изначально была для «user1»

Цените кто-нибудь дать мне знать о каких-либо альтернатив или наилучшей практики для вышеуказанной проблемы

с уважением DotnetShadow

Answer 1

Почему вы не предупреждаете, когда пользователь2 регистрируется? С сообщением типа «Вы уже вошли в систему как user1, вы уверены, что хотите снова войти в систему в качестве другого пользователя?»

Answer 2

Вот как это. Вы ничего не можете с этим поделать. Теперь пользователи привыкли к такому поведению, поскольку они совместимы с известными интернет-сайтами, такими как gmail и т. Д., Поэтому они не должны быть для них проблемой.

Answer 3

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

Answer 4

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

Затем, вместо того чтобы использовать сеанс непосредственно, я хранил строго типизированный объект в сеансах vars под случайным кодом в URL-адресе и использовал , что объект для хранения сессии. Если вы хотите сохранить его простым, вы можете использовать словарь. В дополнение к обычному тайм-ауту сеанса вы должны отслеживать последнее использование в каждом идентификаторе входа и вручную отключать сеанс, если он слишком стар, чтобы не допустить, чтобы новые пользователи не сохраняли старые логины.

По существу, каждый сеанс ASP.NET соответствует любому количеству сеансов входа в систему.

Это имеет следующие преимущества:

• Вы можете журнала в виде нескольких пользователей одновременно. Это удобно для многих сайтов.
• В общественных терминалах это помогает избежать случайного угона захвата. Когда пользователь покидает открытый терминал, закрывает вкладку webapp, но не браузер (что довольно распространено), и другой человек затем подходит к этому терминалу и открывает новое окно или вкладку на ваш сайт, этот новый пользователь не видит следов ранее зарегистрированных в пользователе. Конечно, пользователи должны выйти из системы, и каждый может проверить историю, но нет причин для пригласить.
• CSRF атаки на ваш сайт немного сложнее, поскольку URL-адрес без случайного идентификатора входа не имеет смысла.
• Реализация довольно проста, если вы используете хеш-таблицу - в конце концов, любой пользователь sessionstate-user уже написан для хранения и извлечения данных из хэш-таблицы, вам просто нужно изменить используемую хеш-таблицу и в идеале включить пользовательский тайм-аут.

Очевидным недостатком является то, что вам необходимо включить случайный код в URL-адрес; и что вам нужно немного дополнительной реализации. Вы можете скрыть дополнительный код, используя сайт iframe и/или javascript + XHR, но это гораздо более инвазивное изменение на сайте. Наконец, обратите внимание, что cookieless-сессии не совпадают; хотя их проще включить, они включают гораздо более менее дружелюбный URL-адрес URL-адреса, а также отсутствие обычного токена сеанса cookie также менее безопасны против захвата сеанса (так как внезапно любая другая программа или даже машина, которая обнаруживает идентификатор сеанса может претендовать на роль этого пользователя).

Answer 5

Некоторые из них предложили добавить в URL-адреса уникальные идентификаторы и отслеживать их на основе этих данных.

Если вы собираетесь это сделать, вы можете просто позволить ASP.Net сделать это для вас, включив cookieless sessions - он затем использует URL-адрес, чтобы содержать идентификатор сеанса.

Answer 6

Как насчет хранения данных в viewstate? Это было бы уникально для каждого окна.