В ASP.Net я могу узнать, существует ли другой сеанс или действителен по идентификатору сеанса?

Question

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

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

Спасибо

Answer 1

Вам необходимо сохранить сеансы в базе данных, чтобы найти их раньше.
Подробнее см. В КАК: настроить SQL Server для хранения состояния сеанса ASP.NET

Answer 2

Другой вариант, который у вас есть / имел :-), это использовать WeakReferences:

• a Dictionary<youruseridtype,WeakReference> хранится на уровне приложения как Application ["mySessionDictionnary"]
• при запуске сеанса вы сохраняете идентификатор пользователя и WeakReference для самого объекта сеанса в словаре
• когда пользователь хочет войти в систему, вы проверяете в Словаре его или ее идентификатор. Если существует непустая WeakReference для объекта Session, вы можете отказаться от () этого существующего объекта Session, гарантируя, что на пользователя не более одного активного сеанса.

WeakReference гарантирует, что вы не будете испытывать утечки памяти.

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

Надеюсь, что вы уже нашли правильный ответ на свою проблему; -)

Answer 3

Единственный способ, которым я могу думать, - это делать так, как говорит Neperz, и сохранять свои сеансы в базе данных, используя поставщика сеансов SQLServer, то есть вы можете использовать SQL-запрос, чтобы увидеть, что доступно.

Но нужно учесть несколько предостережений:

1. Я считаю, что идентификатор сеанса, хранящийся в таблице базы данных сеансов, не точно такой же, как идентификатор сеанса, который вы можетедоступ из кода.Я не могу точно вспомнить, где я это читал, но мне кажется, что я столкнулся с этой проблемой, когда делал что-то похожее для мониторинга всех активных сеансов.
2. Глобальное событие Session_End никогда не сработает при использовании SQLServer поставщик сессий.
3. Если вы явно не используете Session.Abandon() в своем коде для завершения сеанса (например, когда пользователь выходит из системы), ваши сеансы могут зависать, пока задание агента SQL не очистит все сеансы с истекшим сроком действия.Это означает, что если кто-то просто закроет окно своего браузера, его сеанс будет по-прежнему отображаться как «активный», что может усложнить вашу реализацию.

Answer 4

Не существует прямого способа проверки SessionId. Опции:

• Вы можете реализовать своего собственного поставщика состояний сеанса (или, может быть, достаточно ID-менеджера), чтобы предоставить доступ к этой информации (http://msdn.microsoft.com/en-us/library/aa479024.aspx).
• Просто попробуйте обмануть, установив файл cookie идентификатора сеанса на основе идентификатора, который, по вашему мнению, должен быть у текущего пользователя, и заново отрендерните страницу. За один второй запрос вы сможете увидеть, соответствует ли этот идентификатор действительному состоянию, и при необходимости повторно войти в систему.

Примечание. Я бы не стал использовать идентификатор сессии для этой цели, поскольку вы будете полагаться на детали реализации. Может быть, просто отклонение сеансов, которые не выглядят как последние для этого пользователя, будет работать. Сохранения свойства «мое текущее имя сеанса» в Session["someName"] и в пользовательской БД должно быть достаточно, чтобы отклонить рендеринг более старых сеансов.