Смешивание сеансов ASP.NET с использованием StateServer (SCARY!)
Мы храним два объекта в сессии. Каким-то образом один из объектов другого пользователя был загружен в сеанс другого пользователя. У пользователя не должно было быть доступа к этим конкретным данным, и как только они увидели его, они поняли, что что-то не так.
У нас есть визуальное подтверждение данных, которые были ему предоставлены, и, конечно же, это не могло бы произойти, если бы сессии не были перепутаны. Это очень страшная ситуация, которую мы не можем понять (мы не можем ее воспроизвести). Единственный ответ для нас - это обвинить ASP.NET StateServer в смешивании переменных сеанса, что совершенно неприемлемо и ставит нас в плохое положение.
Наши приложения - это приложения ASP.NET 2.0, работающие на Windows Server 2003 с IIS6 с использованием StateServer cookieless="false" режим сеанса и проверка подлинности с помощью форм.
Кто-нибудь еще имел эту проблему? Как мы можем решить это?
6 ответов
Мы столкнулись с этой проблемой в моей предыдущей компании и потратили 3 недели на ее устранение. ASP.NET давал пользователю чье-либо состояние сеанса. Это было действительно невозможно дублировать в среде отладки.
Исправление, когда мы обнаружили, что это было просто что-то в web.config. Я не до конца помню, поэтому потратил некоторое время на поиски в интернете. Я считаю, что проблема была связана с кэшированием вывода. Взгляните на эту статью в разделе "Сеансы и выходное кэширование".
/questions/25655018/preobrazovat-desyatichnuyu-v-dvojnuyu/25655034#25655034 (статья называется "Обеспечивайте бесперебойную работу сайтов, избегая этих 10 распространенных ASP.NET"). Подводные камни Джеффа Просиза в июле 2006 года, выпуск журнала MSDN)
Если это похоже на ваш сценарий, то исправление может просто отключить параметр enableKernelOutputCache в web.config.
Удачи.
Сначала ищите ошибки в своем собственном коде - это наиболее вероятное объяснение. Например, используя статические поля или другую разделяемую память, такую как кэш ASP.NET для пользовательских данных.
Возможный ответ - аналогичная проблема сообщается с использованием состояния сеанса без файлов cookie.
сеанс показывает что-то не так
Редактировать - Добавлено
Еще один возможный ответ:
Сколько раз это происходило? Вы проверяли пользователей, использующих браузер назад или отправляющих ссылки друг другу с идентификаторами сеансов?
Один из способов убедиться в ошибке State Server - это переключиться на другой диспетчер сеансов, если вы можете использовать резервный сервер, или использовать SQL Server, но было бы лучше сначала найти способ воспроизвести ошибку, чтобы вы могли проверить ее.
Если бы эта проблема, оказалось, является атрибутом OutputCache в частичном представлении.
Могут ли оба скрещенных пользователя использовать один и тот же прокси-сервер для кэширования? Если это так, то один пользователь может увидеть данные, которые были кэшированы для другого пользователя, если URL-адреса совпадают, особенно если прокси-сервер работает неправильно.
Разве это не было главной проблемой в проекте Google Web Accelerator (в настоящее время прекращено)?