Как установить путь cookie AntiForgeryToken

Question

Бывший метод HtmlHelper.AntiForgeryToken, который позволяет переопределить string path, устарел.

[ObsoleteAttribute("This method is deprecated. Use the AntiForgeryToken() method instead. To specify a custom domain for the generated cookie, use the <httpCookies> configuration element. To specify custom data to be embedded within the token, use the static AntiForgeryConfig.AdditionalDataProvider property.", 
    true)] 
public MvcHtmlString AntiForgeryToken(
    string salt, 
    string domain, 
    string path 
) 

Сообщает, что вы используете <httpCookies>. НО httpCookies Element не имеет настройки для PATH.

Является ли это надзором в устаревании этого метода? Каков наилучший способ переписать этот путь к файлу cookie? (вручную?) Запуск веб-сайта в виртуальном приложении неявно добавляет путь приложения к файлу cookie __RequestVeririfcation.

Answer 1

Глядя на сообщение устаревания:.

«Этот метод не рекомендуется использовать метод AntiForgeryToken() вместо того, чтобы указать пользовательский домен для созданного печенья, используйте элемент конфигурации Чтобы задать пользовательские данные.. быть встроенным в токен, использовать статическое свойство AntiForgeryConfig.AdditionalDataProvider. "

Он сообщает нам, что мы можем проверять дополнительные параметры всякий раз, когда токен подделки считывается. Поэтому, даже если мы не можем установить путь в cookie, мы можем установить путь как свойство внутри токена. Чтобы проверить это позже, например:

public class AdditionalDataProvider : IAntiForgeryAdditionalDataProvider 
{ 
    public string GetAdditionalData(HttpContextBase context) 
    { 
     return AdditionalData(context); 
    } 

    public bool ValidateAdditionalData(HttpContextBase context, string additionalData) 
    { 
     var currentData = AdditionalData(context); 
     return currentData == additionalData; 
    } 

    private static string AdditionalData(HttpContextBase context) 
    { 
     var path = context.Request.ApplicationPath; 
     return path; 
    } 
} 

Когда asp.net генерирует маркер, он будет хранить текущий путь (или любое другое уникальное значение, нужно проверить) для этого приложения и , если у вас есть другое приложение работая по другому пути, когда токен отправляется в это приложение (из-за отсутствия пути к файлу cookie), он будет проверять предыдущие свойства приложения на свойства этого приложения. Если это другой набор свойств, он будет терпеть неудачу и отклонит запрос.

Кроме того, глядя на код для AntiforgeryConfig.cs, если приложение работает в виртуальном каталоге, она будет добавить, что виртуальный каталог в имя куки по умолчанию:

private static string GetAntiForgeryCookieName() 
{ 
    return GetAntiForgeryCookieName(HttpRuntime.AppDomainAppVirtualPath); 
} 

// If the app path is provided, we're generating a cookie name rather than a field name, and the cookie names should 
// be unique so that a development server cookie and an IIS cookie - both running on localhost - don't stomp on 
// each other. 
internal static string GetAntiForgeryCookieName(string appPath) 
{ 
    if (String.IsNullOrEmpty(appPath) || appPath == "/") 
    { 
     return AntiForgeryTokenFieldName; 
    } 
    else 
    { 
     return AntiForgeryTokenFieldName + "_" + HttpServerUtility.UrlTokenEncode(Encoding.UTF8.GetBytes(appPath)); 
    } 
} 

Так что это будет так : _RequestVerificationToken против _RequestVerificationToken _L2RIdjAz0

Значение app2 хотя ча n получать токены из App1, он не сможет их прочитать, так как он всегда будет искать токен проверки App2.

HTH