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

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

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

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

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

Ответ 1

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

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

http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineJuly2006en-us.chm (статья называется Keep Sites Running Smoothly, избегая этих 10 общих ошибок ASP.NET Jeff Prosise в июле 2006 г. издание журнала MSDN)

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

Удачи.

Ответ 2

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

Ответ 3

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

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

Изменить - добавлено

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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