查看弃用消息：
“此方法已弃用。请改用 AntiForgeryToken() 方法。要为生成的 cookie 指定自定义域，请使用配置元素。要指定要嵌入到令牌中的自定义数据，请使用静态 AntiForgeryConfig.AdditionalDataProvider 属性。”
它告诉我们，只要读回伪造令牌，我们就可以验证其他参数。所以即使我们不能在cookie中设置路径，我们也可以将路径设置为token内部的属性。稍后验证它，例如：
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的代码，如果应用程序在虚拟目录中运行，它将默认将该虚拟目录添加到cookie的名称中：
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 vs
_RequestVerificationToken_L2RIdjAz0
意思是 App2 虽然可以从 App1 接收令牌，但它无法读取它们，因为它总是只寻找 App2 验证令牌。
HTH