2014-01-03 2 views
4

У меня есть атрибут MVC4 [ValidateAntiForgeryToken], который отлично работает. Однако я не понимаю, что я вижу в Fiddler. Куки отправляются сервером в браузер устанавливается на это значение:Почему существует разница в значении cookie validateantiforgerytoken и скрытой форме?

__RequestVerificationToken=FVcmfj07ZEuBdjGuqWu14KIzolxr0ArLgvbNdnq0c4DFywxSA31yIHbm2IzgTPMVhMl4STEh2re8oGmwsSjKtSBTolCsmyGGRnLE1qurUqA1 

но скрытая форма ввода устанавливается на это значение:

OxjO3NjS1ly-bqP9RnYK9Vx8ZJyLGVCuTQEuSCAQWofVmuJaRkEcnHAHWcDurXaH6DhUiZ6XY5wCgi70u19mPy9sydMrkuS9qlWMXxGL_401 

т.е. они появляются разные, где они должны совпадать. Я не правильно понимаю файлы cookie, и, возможно, первая строка не является фактическим значением «cookie» в зашифрованном виде?

+1

Это вызывает ошибку или работает должным образом, и вы не понимаете, почему значения разные? –

+1

Возможный дубликат [Почему скрытое поле AntiForgeryToken не совпадает с его файлами cookie на моей машине?] (Http://stackoverflow.com/questions/7186253/why-is-antiforgerytokens-hidden-field-not-same-as-its -cookies-на-мой-машины) – Liam

ответ

3

Pro ASP.NET MVC 3 Framework Источник:

Скрытое поле __RequestVaerificationToken содержит случайную составляющую (соответствие один в куки), но это еще не все. Если пользователь вошел в систему, то значение скрытого поля также будет содержать свое имя пользователя (полученное от HttpContext.User.Identity.Name, а затем зашифрованное).

[ValidateAntiForgeryToken] проверяет, что это соответствует зарегистрированному пользователю. Это добавляет защиту в маловероятном сценарии, когда злоумышленник может каким-то образом писать (но не читать) куки в вашем домене в браузер жертвы и пытается повторно использовать токен, созданный для другого пользователя.

Смежные вопросы