Установка ViewStateUserKey выдает ошибку "Проверка MAC-адреса состояния при ошибке"
У меня есть следующее в моем BasePage
класс, из которого все мои ASPX-страницы происходят из:
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
ViewStateUserKey = Session.SessionID;
}
у меня тоже есть machineKey
установить в Web.config
, Я не думаю, что эта ошибка из-за веб-фермы, потому что это происходит и на моей машине разработчика.
Мой хост теперь обновлен до.NET 3.5 SP1. После этого обновления каждый раз, когда я компилирую ViewStateUserKey
При установке выше я постоянно получаю сообщение об ошибке "Проверка состояния MAC-адреса при сбое" при каждой обратной передаче.
Что я здесь не так делаю? Является ли этот параметр еще необходимым с последним обновлением платформы?
5 ответов
ОК - Я опоздал на разговор на год - но как это правильный ответ? Это применимо только в случае аутентифицированных пользователей и использования ViewStateUserKey
поскольку имя пользователя намного легче угадать, чем идентификатор GUID сеанса.
Кстати, если вы хотите "исправить" код сверху, используйте идентификатор сеанса, однако вы должны установить переменную сеанса, чтобы идентификатор сеанса не менялся каждый раз. Ex.Session["Anything"] = DateTime.Now
ViewStateUserKey = Session.SessionID;
Это, конечно, предполагает, что вы собираетесь использовать сеансы, в противном случае вам понадобится какой-то другой ключ, например имя пользователя или любой другой идентификатор, сохраненный в cookie.
Я искал вокруг довольно много, чтобы найти окончательную причину проблемы. Этот пост от Microsoft действительно помог объяснить все различные причины. http://support.microsoft.com/kb/2915218 Причина 4 - это то, что мы нашли, что является недопустимым ViewStateUserKeyValue
Установка ViewStateUserKey в Session.SessionID или User.Identity.Name не работает для нас.
Мы периодически получали ошибку проверки из-за следующего. Когда IIS сбрасывает пул приложений, сеанс возобновляется, что приводит к ошибке. Мы удаляем сессию при входе в систему, чтобы избежать фиксации сессии, что также приводит к ошибке при входе в систему.
Наконец, у нас получилось решение на основе файлов cookie, которое теперь доступно в VS2012.
public partial class SiteMaster : MasterPage
{
private const string AntiXsrfTokenKey = "__AntiXsrfToken";
private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
private string _antiXsrfTokenValue;
protected void Page_Init(object sender, EventArgs e)
{
//First, check for the existence of the Anti-XSS cookie
var requestCookie = Request.Cookies[AntiXsrfTokenKey];
Guid requestCookieGuidValue;
//If the CSRF cookie is found, parse the token from the cookie.
//Then, set the global page variable and view state user
//key. The global variable will be used to validate that it matches in the view state form field in the Page.PreLoad
//method.
if (requestCookie != null
&& Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
{
//Set the global token variable so the cookie value can be
//validated against the value in the view state form field in
//the Page.PreLoad method.
_antiXsrfTokenValue = requestCookie.Value;
//Set the view state user key, which will be validated by the
//framework during each request
Page.ViewStateUserKey = _antiXsrfTokenValue;
}
//If the CSRF cookie is not found, then this is a new session.
else
{
//Generate a new Anti-XSRF token
_antiXsrfTokenValue = Guid.NewGuid().ToString("N");
//Set the view state user key, which will be validated by the
//framework during each request
Page.ViewStateUserKey = _antiXsrfTokenValue;
//Create the non-persistent CSRF cookie
var responseCookie = new HttpCookie(AntiXsrfTokenKey)
{
//Set the HttpOnly property to prevent the cookie from
//being accessed by client side script
HttpOnly = true,
//Add the Anti-XSRF token to the cookie value
Value = _antiXsrfTokenValue
};
//If we are using SSL, the cookie should be set to secure to
//prevent it from being sent over HTTP connections
if (FormsAuthentication.RequireSSL &&
Request.IsSecureConnection)
responseCookie.Secure = true;
//Add the CSRF cookie to the response
Response.Cookies.Set(responseCookie);
}
Page.PreLoad += master_Page_PreLoad;
}
protected void master_Page_PreLoad(object sender, EventArgs e)
{
//During the initial page load, add the Anti-XSRF token and user
//name to the ViewState
if (!IsPostBack)
{
//Set Anti-XSRF token
ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey;
//If a user name is assigned, set the user name
ViewState[AntiXsrfUserNameKey] =
Context.User.Identity.Name ?? String.Empty;
}
//During all subsequent post backs to the page, the token value from
//the cookie should be validated against the token in the view state
//form field. Additionally user name should be compared to the
//authenticated users name
else
{
//Validate the Anti-XSRF token
if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue
|| (string)ViewState[AntiXsrfUserNameKey] !=
(Context.User.Identity.Name ?? String.Empty))
{
throw new InvalidOperationException("Validation of
Anti-XSRF token failed.");
}
}
}
}
Я исправил это сейчас, изменив код на:
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = User.Identity.Name;
}
Можно ли отключить MAC-кодирование ViewState с помощью атрибута EnableViewStateMac @Page?
ОЧЕНЬ странно, у меня тоже была подобная проблема в течение 3 дней, и теперь я решил ее. 1. Я включил проверку подлинности с помощью форм и имел ssl false
<forms defaultUrl="~/" loginUrl="~/Account/Login.aspx" requireSSL="false" timeout="2880" />
но в моем теге httpcookies у меня был requireSSL=true. Так как в Site.Master.cs он использует куки для установки ViewStateUserKey, у него были проблемы
следовательно я получаю ошибку.
Я изменил это на ложное и перезапустил веб-приложение, теперь все хорошо.