登录
首页 >  文章 >  前端

AJAX传递AntiForgeryToken方法

时间:2026-01-17 10:06:43 257浏览 收藏

今日不肯埋头,明日何以抬头!每日一句努力自己的话哈哈~哈喽,今天我将给大家带来一篇《AJAX 传递 AntiForgeryToken 的正确方法》,主要内容是讲解等等,感兴趣的朋友可以收藏或者有更好的建议在评论提出,我都会认真看的!大家一起进步,一起学习!

如何在 AJAX 请求中正确传递 AntiForgeryToken

本文详解 ASP.NET MVC 中通过 AJAX 调用 POST 接口时传递防伪令牌(AntiForgeryToken)的两种标准方式:以表单字段形式提交或通过自定义请求头传递,并指出常见错误及修复方案。

在 ASP.NET MVC 应用中,[ValidateAntiForgeryToken] 特性用于防止跨站请求伪造(CSRF)攻击。它要求每个受保护的 POST 请求必须携带一个名为 __RequestVerificationToken 的有效令牌。该令牌通常由 @Html.AntiForgeryToken() 生成并嵌入页面 HTML 中(如 <input name="__RequestVerificationToken" type="hidden" value="..." />)。然而,当使用 jQuery AJAX 发起请求时,开发者容易误将令牌放入请求头(headers)而非请求体(data),或错误设置 contentType: 'application/json',导致服务端无法解析令牌,最终抛出 “The required anti-forgery form field '__RequestVerificationToken' is not present” 错误。

✅ 正确做法一:作为表单字段提交(推荐)

这是最兼容、最稳妥的方式,适用于默认的 application/x-www-form-urlencoded 编码格式:

$('#confirmActionBtn').on('click', function () {
    var token = $('[name="__RequestVerificationToken"]').val();
    var url = actionConfirmModal.attr("data-actionUrl");

    $.ajax({
        url: url,
        type: 'POST',
        // ⚠️ 不要设置 contentType: 'application/json'
        // ⚠️ 不要将 token 放入 headers
        data: { 
            __RequestVerificationToken: token,
            id: /* 你的实际 ID,例如从 data-id 属性获取 */
        },
        success: function (response) {
            setupModal('result');
            if (response.success) {
                var redirectUrl = response.redirectUrl;
                if (redirectUrl) {
                    var targetPlaceHolder = actionConfirmModal.attr("data-targetPlaceHolder");
                    if (targetPlaceHolder) {
                        $(targetPlaceHolder).load(redirectUrl);
                    } else {
                        window.location.href = redirectUrl;
                    }
                }
            } else {
                $('#resultMessage').text("Error: " + response.message);
            }
        },
        error: function (xhr, status, error) {
            setupModal('result');
            $('#resultMessage').text("Error: " + error);
        }
    });
});

✅ 优势:无需额外服务端配置;与 MVC 默认模型绑定完全兼容;支持 id 等其他参数自然合并。

✅ 正确做法二:通过自定义请求头传递(需服务端配合)

若坚持使用 application/json 或需要更严格的 API 风格,可将令牌放入请求头,但必须确保服务端启用对应验证器配置(ASP.NET MVC 5.1+ 支持):

前端代码:

$.ajax({
    url: url,
    type: 'POST',
    contentType: 'application/json',
    headers: {
        'RequestVerificationToken': token  // ⚠️ 注意:此处应为 '__RequestVerificationToken'(双下划线)
    },
    data: JSON.stringify({ id: /* your id */ }),
    success: function (response) { /* ... */ }
});

后端配置(Global.asax 或 Startup.cs):

// 在 Application_Start() 中添加(MVC 5.1+)
AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;
// 并确保控制器方法使用以下特性(注意命名一致性):
[ValidateAntiForgeryToken(AdditionalFields = "__RequestVerificationToken")]
public ActionResult Delete(int id) { ... }

⚠️ 关键注意点

  • 请求头名称必须严格为 "__RequestVerificationToken"(含两个前导下划线),否则服务端无法识别;
  • 若使用 contentType: 'application/json',则 data 必须是字符串(JSON.stringify(...)),且服务端需手动读取 HttpContext.Request.Headers["__RequestVerificationToken"] 并调用 AntiForgery.Validate() —— 这会显著增加复杂度,不推荐普通场景使用。

? 常见错误排查清单

错误现象原因修复建议
__RequestVerificationToken is not presentcontentType: 'application/json' + data 未序列化,或 headers 键名拼写错误改用 data: { __RequestVerificationToken: token },移除 contentType 和 headers
400 Bad Request / 500 Internal Server Errorid 参数未传入,导致模型绑定失败在 data 中显式包含 id 字段(如 data: { __RequestVerificationToken: token, id: 123 })
页面刷新后令牌失效多次调用 @Html.AntiForgeryToken() 或缓存了旧视图确保每个页面仅渲染一次 @Html.AntiForgeryToken(),AJAX 成功后如需局部刷新,应重新加载含新令牌的 Partial View

✅ 总结

对于绝大多数 ASP.NET MVC 项目,将 __RequestVerificationToken 作为普通表单字段(data 对象属性)提交是最简洁、可靠且符合框架设计意图的方式。避免混合使用 application/json 与传统 MVC 表单验证机制;如确有 JSON API 需求,建议升级至 ASP.NET Core 并采用其现代化的 [ValidateAntiForgeryToken] 与 [FromBody] 协同机制。始终确保前端获取的令牌值非空,并与服务端 @Html.AntiForgeryToken() 输出一致——这是 CSRF 防护生效的前提。

以上就是《AJAX传递AntiForgeryToken方法》的详细内容,更多关于的资料请关注golang学习网公众号!

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>