ошибка с переменной сеанса в ASP.NET ?
https://stackoverflow.com/questions/92052
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Возможно ли для ASP.NET перепутать, какой пользователь связан с какой переменной сеанса на сервере?Являются ли переменные сеанса неизменно привязанными к исходному пользователю, который их создал, во времени, пространстве и измерениях?
Решение
Чтобы ответить на ваш первоначальный вопрос:Сеансы привязываются к идентификатору, который помещается в файл cookie.Этот идентификатор генерируется с помощью некоторых криптографических процедур со случайными числами.Его уникальность не гарантируется, но крайне маловероятно, что он когда-либо будет продублирован в течение срока действия сеанса.Даже если ваши сеансы длятся полные рабочие дни.Вероятно, действительно популярному сайту потребовались бы годы, чтобы даже сгенерировать дубликат ключа (никакой статистики или фактов, подтверждающих это).
Сказав все это, не похоже, что ваша проблема связана с перепутыванием значений сеанса.Первое, на что я бы начал обращать внимание, - это объединение в пул соединений.ADO объединяет соединения по умолчанию, но если вы запрашиваете соединение с именем пользователя / паролем, которого нет в пуле, оно должно предоставить вам новое соединение.Подсказка: это может стать узким местом в производительности в будущем, если ваш сайт очень большой.Прошло некоторое время с тех пор, как я работал с SQL Server, в Oracle есть вызов, который может быть выполнен для переключения идентификатора пользователя.Я был бы удивлен, если бы в SQL Server не было эквивалента.Вы могли бы попробовать подключиться к своей базе данных с помощью общего имени пользователя / пароля, а затем выполнить этот вызов identity switch, прежде чем вернуть соединение с остальной частью вашего кода.
Другие советы
Это зависит от вашего поставщика сеансов, если вы переопределили генерацию ключа сеанса способом, который больше не является уникальным, то несколько пользователей могут получать доступ к одному и тому же сеансу.
Какое поведение вы наблюдаете?И вы уверены, что с переменными, о которых вы говорите, нет никаких помех?
пока возможно все....
Нет, если только вы не сохраняете состояние сеанса в sql server или каком-либо другом внепроцессном хранилище, а затем не возитесь с ним...
Сеанс привязан к пользовательскому файлу cookie, вероятность того, что это приведет к сбою в обычном сценарии, очень маловероятна, однако при использовании распределенного состояния сеанса могут возникнуть проблемы.
Это невозможно.Сеансы привязаны к создателю.
Вы хотите что-то перепутать, или у вас есть случай, когда это выглядит как перепутанное?
Дополнительная информация:
У меня есть приложение, которое берет идентификатор пользователя / пароль со страницы входа в систему и сохраняет его в переменной сеанса.Я вставляю его в свою строку подключения для выполнения вызовов SQL Server.
Когда таблица обновляется, мы используем 'system_user' в базе данных для идентификации пользователя, который был "последним обновлен".Мы наблюдаем какое-то странное поведение, при котором пользователь, которого мы ожидаем увидеть в списке, неверен, и он показывает кого-то другого.
Можете ли вы запустить отладчик и посмотреть, действительно ли в этой строке подключения передается правильное значение?Это быстро помогло бы вам определить, на чьей стороне проблема.
Также убедитесь, что ни один из кодов подключения не имеет статических свойств для подключения или пользователя, иначе у одного пользователя может быть заменено соединение на соединение с самым последним пользователем до завершения обновления.
Я предполагаю, что вы повторно используете статическое поле в классе для хранения строки подключения.Эти статические поля повторно используются в нескольких запросах IIS, поэтому вы, вероятно, видите только самого последнего вошедшего в систему пользователя в поле "последнее обновление от".
Кстати, если у вас нет ДЕЙСТВИТЕЛЬНО веской причины для этого, вам не следует подключаться к базе данных подобным образом.Вы запрещаете себе использовать пул подключений, что может снизить производительность при высоких нагрузках.
