Добавьте это в файл web.config в системе.веб-раздел:
<machinekey validationkey="xxx" decryptionkey="xxx" validation="SHA1" decryption="AES" />
Ссылка [здесь] - 404. Сайт Microsoft: https://support.microsoft.com/en-us/kb/2915218#bookmark-appendixa
Обратите внимание на их комментарий: "есть много веб-сайтов, которые будут генерировать элемент "machinekey" для вас одним нажатием кнопки. Никогда не используйте элемент "machinekey", полученный с одного из этих сайтов."
Для использования скопируйте функцию PowerShell в скрипт, добавьте строку "Generate-MachineKey" внизу (они забыли вызвать функцию) и запустите ее.
Обратитесь к следующей теме для обсуждения этого вопроса:
http://forums.asp.net/t/955145.aspx[^]
Вы можете исправить это, установив EnableViewStateMAC свойство значение false. См. более подробную информацию о компании EnableViewStateMAC по ссылке приведенной ниже:
http://msdn.microsoft.com/en-us/library/system.web.ui.page.enableviewstatemac.aspx[^]
Предоставленная вами ссылка MSDN гласит: "Этот атрибут никогда не должен иметь значения false на рабочем веб-сайте, даже если приложение или страница не используют состояние просмотра. Состояние представления MAC помогает обеспечить безопасность других ASP.NET функции в дополнение к просмотру состояния."
Короче говоря, если вы отключите ViewStateMAC, вы больше не сможете доверять всему, что отправляется по почте, включая все элементы управления страницами, включая те, которые не видны.
В расширенных настройках AppPool -> Веб-сайта убедитесь, что вы не изменили максимальный рабочий процесс на значение больше 1.
Я сделал модификацию, надеясь, что мой сайт с некоторым трафиком будет более отзывчивым, и начал иметь проблемы с переменными сеанса, которые теряются и появляются позже, а также сообщение о неудачной проверке ViewState.
Я следовал различным советам, EnableViewStateMAC и т. д.... безуспешно, пока не вспомнил, что я увеличил это значение несколько дней назад и что это должно быть причиной.
Поставив его обратно на 1, который был установлен по умолчанию, ситуация вернулась в нормальное русло, и мои состояния просмотра Больше не являются недействительными, а мои сеансы-потерянными.
<machinekey validation="SHA1" validationkey="A1B2C3D4E5F6F6E5D4C3B2A1A1B2C3D4E5F6F6E5D4C3B2A1A1B2C3D4E5F6F6E5D4C3B2A1A1B2C3D4E5F6F6E5D4C3B2A1A1B2C3D4E5F6F6E5D4C3B2A1B2C3D4E5" decryption="Auto" decryptionkey="A1B2C3D4E5F6F6E5D4C3B2A1A1B2C3D4E5F6F6E5D4C3B2A1" />
очень поздно человек
Я сделал это, но получил следующую ошибку
Раздел конфигурации "machinekey" не может быть прочитан, поскольку в нем отсутствует объявление раздела.
Изменен 'ключей' к 'ключей' решена разделе декларации ошибки.
все еще предыдущая ошибка
просто поместите приведенный ниже код внутри тега конфигурации в файле web.config
<system.web> <machineKey validationKey="52B3217F9A9F7B8CE24DEFBD3EDF2B698E37B2ADE33257FAD329A242C11579D0EEDDB67F94CCF27143DCA4BBF9667DDAE78EBEDDD9EABB7C7AB874B5EC443954" decryptionKey="8A3AD1DD400FF3A09F3F5CB27C0411D2E8C7792CE523FD7B" validation="SHA1"/> </system.web>
Откройте Настройки пула приложений, измените значение "загрузить профиль пользователя" на true. Это сработало для меня.
Одна вещь, с которой я столкнулся, которая вызывает эту проблему, связана с интервалами рециркуляции пулов приложений на веб-сервере.
Я нашел это, просмотрев информацию о событии в журналах Eventviewer/Application и "категорию задач" под названием "веб-событие". Затем в течение периода времени, когда это событие имело место, я посмотрел, были ли какие-либо переработанные события, которые имели место непосредственно перед этим (Eventviewer/системные журналы и "источник" под названием "был".
По умолчанию пул приложений будет перерабатываться каждые 1740 минут (29 часов). Если эта рециркуляция произошла, когда пользователь занят на сайте и отправляет сообщение обратно на сервер, сервер больше не распознает сеанс/состояние просмотра и отклоняет то, что отправляется обратно.
Чтобы преодолеть это, с нашей точки зрения, нужно установить событие рециркуляции в определенное время дня, когда мы не ожидаем активности на сайте. В нашем случае 3 часа ночи.
Надеюсь, это кому-то поможет.
&ЛТ;страниц controlrenderingcompatibilityversion="4.0" enableeventvalidation="false" - в viewstateencryptionmode следующим образом="всегда"и GT;enableViewStateMac="false">
Ужасный способ исправить это. Вы должны установить validationkey и decryptionkey и не делать этот хак.
"Этот атрибут никогда не должен быть установлен в false на рабочем веб-сайте, даже если приложение или страница не используют состояние просмотра. Состояние представления MAC помогает обеспечить безопасность других ASP.NET функции в дополнение к просмотру состояния."
Ни одно из решений, упомянутых выше, не сработало для меня. В конце концов я потратил уйму времени, чтобы разобраться в этом вопросе.
Виновником стало печенье. Я попытался сделать файл cookie защищенным, который работает там, где установлен SSL. Но он не будет работать там, где не установлен SSL. Итак, всякий раз, когда вы хотите создать файл cookie и хотите сделать его безопасным, вот правильный метод.
Dim responseCookie = New HttpCookie(AntiXsrfTokenKey)
With responseCookie
.HttpOnly = True
.Value = _antiXsrfTokenValue
End With
If FormsAuthentication.RequireSSL AndAlso Request.IsSecureConnection Then
responseCookie.Secure = True
End If
Большое вам спасибо - как раз мой случай!
Проверка состояние вида Mac не удалась. Если это приложение размещено в веб-ферме или кластере, убедитесь, что в конфигурации machinekey указан один и тот же ключ проверки и алгоритм проверки. Автоматически заполнять не может использоваться в кластере
Как я выяснил, там был один человек.
<base ..../>тег в верхней части моей главной страницы, который я добавил в последнем галстуке и перед публикацией. Этот тег указывает URL-адрес по умолчанию и цель по умолчанию для всех ссылок на странице. На этот раз это было главной причиной неисправности.
Если ни одно из вышеперечисленных решений не работает для вас проверьте следующее решение:
если вы используете F5 и ваш сеанс липкий, проверьте тайм-аут липкого сеанса. Ваш тайм-аут сеанса приложения и тайм-аут липкого сеанса F5 должны быть одинаковыми, а тайм-аут липкого сеанса должен быть не меньше тайм-аута сеанса приложения.
STICKY SESSION TIMEOUT работает для меня, и я решил проблему MAC FAILED.