Путаница в сеансе ASP.NET с использованием StateServer (СТРАШНО!)

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

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

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

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


security asp.net session iis-6 stateserver
person Josh Stodola    schedule 29.10.2009    source источник
comment
Я видел это, но в .Net 1.1. t предположительно был исправлен в 2.0. У меня есть несколько вопросов, прежде чем я попытаюсь опубликовать ответ. Первый вопрос: вы используете сеанс без файлов cookie?   -  person David    schedule 29.10.2009
comment
Спасибо! Да, без cookie (это сказано в вопросе).   -  person Josh Stodola    schedule 29.10.2009
comment
Извини ... Не читал. Поскольку использование сеансов без файлов cookie означает, что идентификатор сеанса включен в URL-адрес в качестве параметра строки запроса, удостоверились ли вы, что параметр строки запроса идентификатора сеанса URL-адреса отличается у двух пользователей, когда это происходит?   -  person David    schedule 29.10.2009
comment
Боже. Мне жаль. Это НЕ без файлов cookie. Наши сеансы основаны на файлах cookie. Блин двойные негативы !!!   -  person Josh Stodola    schedule 29.10.2009
comment
В ПОРЯДКЕ. Я не могу найти свои оригинальные ссылки. Я знаю, что однажды подобная ошибка была исправлена ​​Microsoft. Кажется, я больше не могу найти документацию. Конечно, он устарел на несколько лет.   -  person David    schedule 30.10.2009
comment
Был обменен весь сеанс или всего несколько переменных сеанса?   -  person wtaniguchi    schedule 30.10.2009
comment
Вы можете сказать «Перехват сеанса»? Довольно легко сделать. Вы кодируете весь пользовательский ввод?   -  person mxmissile    schedule 30.10.2009
comment
Есть ли у вас какие-либо данные регистрации? Вы не можете понять подобные вещи с точки зрения пользователей. Вам нужно увидеть заголовки, что было отправлено, когда на какой IP ... и т. Д. Я сомневаюсь, что это имеет какое-либо отношение к StateServer.   -  person rick schott    schedule 30.10.2009
comment
@wtanguchi Только одна переменная в сеансе, а не весь сеанс. Если это важно, переменная была .NET Structure с примерно 6 строковыми свойствами.   -  person Josh Stodola    schedule 30.10.2009
comment
@_rick_schott К сожалению, нет. Наш системный администратор помешан на эффективности и ненавидит идею о том, что журналы IIS становятся большими. Я знаю, это смешно.   -  person Josh Stodola    schedule 30.10.2009

Ответы (6)


arrow_upward
15
arrow_downward

Мы столкнулись именно с этой проблемой в моей предыдущей компании, и на ее устранение потребовалось 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.

Удачи.

person Linus    schedule 29.10.2009
comment
Я считаю, что вы правы! Фактически у нас было включено кэширование вывода для одной веб-формы, и именно эта форма отвечала за заполнение нашей несоответствующей переменной сеанса. Вы святой, ученый, джентльмен, гений, и я не могу вас отблагодарить !! - person Josh Stodola; 30.10.2009
comment
+1. Хотя Джош сказал, что была заменена только одна переменная, а не весь сеанс, как указано в вашей ссылке. - person wtaniguchi; 30.10.2009
comment
Чтобы прояснить, у меня есть только доказательство того, что одна переменная была заменена местами. - person Josh Stodola; 30.10.2009
comment
Спасибо за то, что помогли мне определить, что я не сумасшедший. Я боролся с подобной проблемой в течение нескольких недель, и я был в тупике. Наконец, я добавил достаточно подсказок для отладки к своим сообщениям об исключениях, из которых я сделал вывод, что сеансы пересекаются. Я был рад найти быстрый ответ, когда пришел к такому выводу. - person Jeff Handley; 17.09.2010
comment
Я также сталкивался с этой (или очень похожей) проблемой в IIS 7.5. В управляемом модуле HTTP существует рекомендация явно отключить кеширование ядра в ответе Response.DisableKernelCache(). - person jasper; 07.08.2013
comment
@JoshStodola: Я столкнулся с той же проблемой. Не могли бы вы поделиться своим кодом? - person Jacob Phan; 19.01.2016

arrow_upward
6
arrow_downward

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

person Joe    schedule 29.10.2009
comment
Я просто провожу последние десять дней, занимаясь этим. Я подчеркнул это слово в своем вопросе не без причины. Поверьте, наш код пуленепробиваемый. - person Josh Stodola; 29.10.2009
comment
Кроме того, это приложение работает в течение многих лет, и мы столкнулись с этой проблемой только один раз. - person Josh Stodola; 29.10.2009
comment
+1 Каждый раз, когда я вижу что-то похожее на то, что описывает Джош, виноват в этом. - person kemiller2002; 29.10.2009
comment
Поверьте, наш код пуленепробиваемый. Факты говорят об обратном! И тот факт, что состояние гонки произошло только один раз, не обязательно удивляет. - person Joe; 29.10.2009
comment
Я понимаю вашу точку зрения и ценю вашу проницательность. Если бы я подошел к этому вопросу, мой ответ был бы таким же, как и ваш. Тем не менее, поверьте, я потратил больше времени, чем вы когда-либо могли себе представить, пытаясь найти ошибку в нашем коде, которая позволила бы этому случиться. Там ничего нет, это не слишком сложное приложение, и я на 100% (да, мне так же сложно выкинуть эту цифру, как и вам) уверен, что проблема не в нашем коде. - person Josh Stodola; 29.10.2009
comment
Я на 100% уверен - я уверен, что вы в это верите, но я уверен, что вы поймете, что вам придется убеждать кого-то еще, не показывая им полный исходный код. - person Joe; 29.10.2009
comment
Я знаю, Джо. Вот почему я копал, копал и копал около 2 недель, прежде чем, наконец, выбросил полотенце и опубликовал этот вопрос. - person Josh Stodola; 30.10.2009
comment
Я пытался помочь решить проблему на сайте, на котором возникла такая же проблема. Я могу понять разочарование Джоша - я тоже потратил бесчисленные часы на отладку, чтобы прийти к выводу, что Select здесь не работает. - person Jeff Handley; 17.09.2010

arrow_upward
3
arrow_downward

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

сеанс показывает что-то не так

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

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

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

person David    schedule 29.10.2009

arrow_upward
0
arrow_downward

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

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

person Wagner    schedule 29.10.2009
comment
Это произошло только однажды. Браузер обратно определенно не так, потому что аутентификация пользователей не позволит получить доступ к этим данным в любой момент. У них тоже нет возможности сделать что-то вроде взлома идентификаторов сеансов, наши пользователи - пожилые бизнесмены, которые даже не знают, что такое сеанс. - person Josh Stodola; 29.10.2009

arrow_upward
0
arrow_downward

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

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

person GBegen    schedule 29.10.2009

arrow_upward
0
arrow_downward

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

person stuartdotnet    schedule 24.02.2014