Управление сеансом пользователя в asp.net

мой клиент прошел аудит безопасности системы, которую я построил для него.

Они хотят, чтобы это работало таким образом, что если пользователь входит в систему через Internet Explorer, то при входе в систему через Firefox на том же компьютере (или через IE на другом компьютере) первая сессия прерывается.

По сути, это означает сохранение информации о сеансе в БД, которую я мог бы представить, а затем установку для него активного/неактивного флага, поэтому идентификатор пользователя, идентификатор сеанса, статус, если у пользователя есть активный сеанс, затем убить первый сеанс и создать новый сеанс.

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

Большое спасибо,

Ed


asp.net session
person Ed Bloom    schedule 30.03.2009    source источник
comment
Можете ли вы уточнить, пожалуйста. Если пользователь входит в систему с другого компьютера/браузера, то его сеанс в других браузерах прекращается и продолжается в новом браузере?   -  person Dead account    schedule 30.03.2009
comment
да правильно - пользователь входит в систему с другого компьютера/браузера, и его сеанс в других браузерах прекращается и продолжается в новом браузере   -  person Ed Bloom    schedule 30.03.2009
comment
@Ian: Я согласен, что спецификация слишком свободна, что, если используется другой экземпляр IE? IOW мы говорим, что только один процесс браузера может иметь активный сеанс для пользователя?   -  person AnthonyWJones    schedule 30.03.2009
comment
@Ed, пожалуйста, отредактируйте свой вопрос, чтобы ужесточить требование.   -  person AnthonyWJones    schedule 30.03.2009
comment
@Anthony - если используется другой экземпляр IE, то я бы посчитал, что это один и тот же сеанс - это если серверу трудно различать сеансы из одного и того же контейнера браузера (т. Е. Несколько окон IE).   -  person Ed Bloom    schedule 30.03.2009
comment
@Anthony. Кроме того, пользователь может щелкнуть «Открыть в новом окне» и т. д., что имеет смысл для поддержания сеанса. Рекомендация предназначена для того, чтобы запретить пользователям совместно использовать свои учетные данные для входа на разных компьютерах и позволить 2 пользователям одновременно входить в систему с одним и тем же логином.   -  person Ed Bloom    schedule 30.03.2009
comment
@ Эд, посмотри мой комментарий к ответу для Криса. Я думаю, вы найдете, что его ответ сделает то, что вам нужно. Если пользователь запускает новый экземпляр IE и входит в систему, в этом сценарии было бы разумно заблокировать более старый экземпляр.   -  person AnthonyWJones    schedule 30.03.2009

Ответы (2)


arrow_upward
2
arrow_downward

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

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

Это не помешает пользователю использовать несколько вкладок в IE 7, потому что IE7 использует один и тот же экземпляр для каждой вкладки; но это не позволит им использовать несколько экземпляров браузера.

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

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

ОБНОВЛЕНИЕ

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

person NotMe    schedule 30.03.2009
comment
спасибо за предложение - это может сработать, но я бы хотел, чтобы новый сеанс переопределял старый, чтобы пользователь не был исключен. Но если они вернутся к исходному браузеру/компьютеру и обновятся или попытаются получить доступ к чему-либо, они будут возвращены к логину. - person Ed Bloom; 30.03.2009
comment
Это именно то, что это сделает. Каждый раз, когда они входят в систему, просто обновляйте таблицу пользователей последним идентификатором сеанса. Когда старый сделает получение или публикацию, он увидит, что он не актуален, и вы перенаправитесь на экран входа в систему. - person NotMe; 30.03.2009
comment
Эд, это в основном то, что я сделал. Выигрывайте последними, в противном случае вам придется дождаться тайм-аута их сеанса, прежде чем позволить им снова войти в систему. - person JoshBerke; 30.03.2009
comment
@Chris: изменить запретить им использовать несколько окон браузера на несколько экземпляров браузеров, несколько окон, запущенных из текущего экземпляра браузера, будут использовать один и тот же сеанс. - person AnthonyWJones; 30.03.2009
comment
@Chris - да, этот последний в выигрыше подход, кажется, правильный путь. Что еще порекомендуете, чтобы остановить захват сеанса? @ Энтони - ааа, да, старые экземпляры браузера по сравнению с каштановыми окнами браузера - сбили с толку многих веб-разработчиков. - person Ed Bloom; 30.03.2009

arrow_upward
0
arrow_downward

Я записал в блоге о том, как я справляюсь с этим. В основном идея заключается в том, что мы создаем непостоянный файл cookie, который имеет Guid.

Затем мы сохраняем это, привязанное к идентификатору пользователя, в каком-то месте на сервере (кэш приложений, БД и т. д.). Затем у нас есть опросчик, который обращается к серверу каждые пару минут, и если cookie не соответствует значению, мы выходим из системы.

person JoshBerke    schedule 30.03.2009
comment
@Josh - хороший подход - определенно дал мне пищу для размышлений - person Ed Bloom; 30.03.2009