Мы храним два объекта в сессии. Каким-то образом один из объектов от другого пользователя загрузился в сеанс другого пользователя. У пользователя не должно быть доступа к этим конкретным данным, и как только они их увидят, они поймут, что что-то не так.
У нас есть визуальное подтверждение данных, которые были ему представлены, и определенно не могло быть, чтобы это могло произойти, если бы сеансы не перепутались. Это очень пугающая ситуация, которую мы не можем понять (не можем воспроизвести). Единственный ответ для нас - обвинить ASP.NET StateServer в смешивании переменных сеанса, что совершенно неприемлемо и ставит нас в плохое положение.
Наши приложения - это приложения ASP.NET 2.0, работающие на Windows Server 2003 с IIS6, использующие StateServer cookieless="false" режим сеанса и FormsAuthentication.
У кого-нибудь еще была эта проблема? Как мы можем это решить?
Ответ 1 · рейтинг 15 · Linus
Мы столкнулись именно с этой проблемой в моей предыдущей компании, и на ее устранение потребовалось 3 недели. ASP.NET давал пользователю чужое состояние сеанса. В отладочной среде действительно невозможно было продублировать.
Исправление, которое мы обнаружили, было просто кое-чем в web.config. Я не совсем его помню, поэтому немного погуглил. Я считаю, что проблема связана с кешированием вывода. Взгляните на эту статью в разделе "Сеансы и кэширование вывода".
http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineJuly2006en-us.chm (статья называется Обеспечьте бесперебойную работу сайтов, избегая этих 10 распространенных Подводные камни ASP.NET Джеффа Просиза в июльском выпуске журнала MSDN 2006 г.)
Если это похоже на ваш сценарий, возможно, исправление просто отключило параметр enableKernelOutputCache в web.config.
Удачи.
Ответ 2 · рейтинг 6 · Joe
Сначала ищите ошибки в собственном коде - это, безусловно, наиболее вероятное объяснение. Например. использование статических полей или другой общей памяти, такой как кеш ASP.NET, для пользовательских данных.
Ответ 3 · рейтинг 3 · David
Возможный ответ - аналогичная проблема сообщается с использованием состояния сеанса без файлов cookie.
сеанс показывает что-то не так
Изменить - добавлено
Другой возможный ответ:
Страница ASP.NET сохраняется в кэше ядра HTTP.sys в IIS 6.0, когда страница ASP.NET создает заголовок HTTP, содержащий ответ Set-Cookie
Ответ 4 · Wagner
Сколько раз это повторялось? Проверяли ли вы, что пользователи используют браузер или отправляют друг другу ссылки с идентификаторами сеанса?
Один из способов точно проверить ошибку State Server - переключиться на другой диспетчер сеансов, вернуться к внутреннему процессу, если вы можете, или использовать SQL Server, но было бы лучше сначала найти способ воспроизвести ошибку, чтобы вы могли ее протестировать.
Ответ 5 · GBegen
Могут ли два перекрестных пользователя использовать один и тот же прокси-сервер кеширования? Если это так, то один пользователь может увидеть данные, которые были кэшированы для другого пользователя, если URL-адреса совпадают, особенно если прокси-сервер плохо себя ведет.
Разве это не основная проблема проекта Google Web Accelerator (сейчас прекращенного)?
