Ошибка проверки состояния просмотра при первой отправке формы новых сеансов

#asp.net #forms #session #iis #viewstate

#asp.net #формы #сеанс #iis #состояние просмотра

Вопрос:

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

 Event code: 4009 
Event message: Viewstate verification failed. Reason: The viewstate supplied failed integrity check. 
Is authenticated: False 
Authentication Type: Forms 
Thread account name: IIS APPPOOL.NET v4.5 
Exception message: Invalid viewstate.
  

Об этом сообщалось / демонстрировалось в Edge и Chrome, но не в Firefox или Internet Explorer.

РЕДАКТИРОВАТЬ: оказывается, мы смогли определить, что Edge и Chrome не имеют сеансового файла cookie ASP.NET_SessionId при первоначальном просмотре сайта. После обратной передачи идентификатор сеанса отображается в файлах cookie, и форма снова работает. Этого не происходит в Firefox, в Firefox есть .ЧИСТЫЙ идентификатор сеанса при первой загрузке страницы. Этот идентификатор сеанса используется в качестве ViewStateUserKey, и это, вероятно, объясняет причину ошибки, но не причину. Почему Chrome не имеет идентификатора сеанса до окончания обратной передачи?

Я уже прочитал все, что смог найти в Интернете по этой ошибке, поэтому позвольте мне отметить несколько вещей, основанных на других предложениях, которые я видел:

  • Добавление машинного ключа в файл веб-конфигурации не помогает. Мы уже пробовали это. Кроме того, этот сайт не находится на ферме серверов, он работает на одном веб-сервере.
  • Я видел предложения о том, что может быть задействована переработка пула приложений или ограничения памяти на сервере, но рассматриваемый сервер работает далеко от пределов своих ресурсов, и ошибка может быть воспроизведена последовательно; если бы это было связано с событиями пула приложений или проблемами с памятью, я бы ожидал, что это будет более спорадическим.

Другая информация, если она актуальна:

  • на сервере запущен IIS 8 в Windows Server 2012 R2
  • настройка аутентификации в веб-конфигурации <authentication mode="Forms"><forms name="XXXXXXXXXX" loginUrl="SignIn.aspx" timeout="525600" /></authentication>
  • состояние сеанса в веб-конфигурации <sessionState mode="InProc" cookieless="false" timeout="20" />

Любые идеи будут высоко оценены!

РЕДАКТИРОВАТЬ: кто-то спросил о том, как отправляются формы. Вот пример кода формы с одной из страниц формы, на которой я могу воспроизвести ошибку, giftcard.aspx.

 <form name="aspnetForm" method="post" action="./giftcard.aspx" onsubmit="javascript:return WebForm_OnSubmit();" id="aspnetForm">
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/[gibberish]" />
</div>
<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['aspnetForm'];
if (!theForm) {
    theForm = document.aspnetForm;
}
function __doPostBack(eventTarget, eventArgument) {
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;
        theForm.submit();
    }
}
//]]>
</script>
<script src="/WebResource.axd?[gibberish]" type="text/javascript"></script>
<script src="jscripts/formvalidate.js" type="text/javascript"></script>
<script src="jscripts/core.js" type="text/javascript"></script>
<script src="/ScriptResource.axd?[gibberish]" type="text/javascript"></script>
<script src="/ScriptResource.axd?[gibberish]" type="text/javascript"></script>
<script src="/ScriptResource.axd?[gibberish]" type="text/javascript"></script>
<script src="/WebResource.axd?[gibberish]" type="text/javascript"></script>
<script type="text/javascript">
//<![CDATA[
function WebForm_OnSubmit() {
if (typeof(ValidatorOnSubmit) == "function" amp;amp; ValidatorOnSubmit() == false) return false;
return true;
}
//]]>
</script>
  

Мы используем элемент управления asp: Button для отправки, как показано ниже:

 <asp:Button ID="btnContinue" CssClass="btn-primary btn-GCcontinue" runat="server" Text="Continue" OnClick="btnContinue_Click" />
  

Этот пример был бы типичным для форм на сайте.

Комментарии:

1. Как вы размещаете форму на странице? Возможно ли отправить его автоматически при первом обращении к форме? Они несовместимы во время проверки на стороне сервера. Не могли бы вы описать, как вы публикуете форму и показываете код страницы?

2. Обновлено для включения примеров кода с одной из страниц формы.

3. Используете ли вы site.master на этой странице формы? или вы переписываете новую страницу site.master, из-за которой значение viewstate имеет проблему. Вам необходимо проверить процесс проверки состояния просмотра в site.master, похоже, вы изменили значение ввода.

4. Мы используем мастер-страницы, и форма находится на главной странице. Я не писал код формы, этот сайт изначально был готовым решением, и этот аспект, насколько я знаю, не был изменен. Если вы посмотрите на приведенный мной пример кода, похоже, что __doPostBack изменяется для отправки формы при любой обратной отправке. Как вы думаете, это часть проблемы?

5. Если вы используете site.master и не меняете его, я думаю, проблема может быть вызвана «<тип ввода =»скрытый» имя =»__VIEWSTATE» идентификатор =»__VIEWSTATE» значение =»/ [тарабарщина]» />». Пожалуйста, удалите его и протестируйте снова.

Ответ №1:

Оказывается, ответ был связан с файлами cookie Samesite. Недавно мы обновили наш файл cookie идентификатора сеанса, чтобы использовать samesite= none в попытке устранить проблемы с нашей обработкой платежей, которые, как мы подозревали, были связаны с изменениями samesite в Chrome. Когда мы это делали, мы не понимали, что нам также нужно указать Secure, и хотя я все еще не уверен, как отсутствие Secure привело к определенному поведению, которое мы наблюдали, обновление нашего файла cookie сеанса для использования SameSite=None; Secure; , похоже, исправило это, и Chrome теперь распознает ASP.NET_SessionId с первогозапрос.

Примечание, поскольку наша версия .NET очень старая, мы используем перезапись в конфигурации приложения, которую мы нашли здесь https://www.coderfrontline.com/chromes-samesite-cookie-changes-are-breaking-apps / и теперь, когда я смотрю еще раз, там полностью написано использовать Secure, но в то время мы этого не заметили, просто скопировали образец дословно. Поэтому убедитесь, что вы добавили Secure, если используете HTTPS.