Смешивание сессий ASP.NET с использованием StateServer (SCARY!)

Question

Мы храним два объекта в сессии. Каким-то образом один из объектов другого пользователя был загружен в сеанс другого пользователя. У пользователя не должно было быть доступа к этим конкретным данным, и как только они увидели его, они поняли, что что-то было очень неправильно.

У нас есть визуальное подтверждение данных, которые были ему предоставлены, и , конечно, никак не могло бы произойти, если бы сессии не были перепутаны. Это очень страшная ситуация, которую мы не можем понять (мы не можем ее воспроизвести). Единственный ответ для нас - это обвинить ASP.NET StateServer в смешивании переменных сеанса, что совершенно неприемлемо и ставит нас в плохое положение.

Наши приложения - это приложения ASP.NET 2.0, работающие на Windows Server 2003 с IIS6 с использованием режима сеанса StateServer cookieless="false" и FormsAuthentication.

Кто-нибудь еще имел эту проблему? Как мы можем решить это?

Answer 1

Мы столкнулись с этой проблемой в моей предыдущей компании и потратили 3 недели на ее устранение. ASP.NET давал пользователю чье-либо состояние сеанса. Это было действительно невозможно скопировать в среде отладки.

Исправление, когда мы обнаружили, что это было просто что-то в web.config. Я не полностью помню это, поэтому я потратил некоторое время на поиск в Google. Я считаю, что проблема была связана с кэшированием вывода. Взгляните на эту статью в разделе «Сеансы и выходное кэширование».

http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineJuly2006en-us.chm (статья называется Обеспечьте бесперебойную работу сайтов, избегая этих 10 распространенных ошибок ASP.NET Джеффом Просисом в выпуске журнала MSDN в июле 2006 года)

Если это похоже на ваш сценарий, то исправление может просто отключить опцию enableKernelOutputCache в web.config.

Удачи.

Answer 2

Сначала найдите ошибки в своем собственном коде - это, безусловно, наиболее вероятное объяснение. Например. использование статических полей или другой разделяемой памяти, такой как кэш ASP.NET для пользовательских данных.

Answer 3

Возможный ответ - аналогичный вопрос сообщается с использованием состояния сеанса без файлов cookie.

сеанс, показывающий что-то не так

Редактировать - Добавлено

Другой возможный ответ:

Страница ASP.NET сохраняется в кэше ядра HTTP.sys в IIS 6.0, когда страница ASP.NET создает заголовок HTTP, содержащий ответ Set-Cookie

Answer 4

Если бы эта проблема оказалась атрибутом OutputCache в частичном представлении.

Answer 5

Могут ли оба скрещенных пользователя использовать один и тот же прокси-сервер для кэширования? Если это так, то один пользователь может увидеть данные, которые были кэшированы для другого пользователя, если URL-адреса совпадают, особенно если прокси-сервер работает неправильно.

Разве это не было главной проблемой в проекте Google Web Accelerator (в настоящее время прекращено)?

Answer 6

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

Один из способов убедиться в ошибке State Server - это переключиться на другой менеджер сеансов, если вы можете использовать in-proc или использовать SQL Server, но лучше было бы сначала найти способ воспроизвести ошибку, чтобы вы могли проверить это.