WordPress中CSRF Token重复生成：如何确保代码仅执行一次？

你的核心问题是：generate_csrf_token函数被多次触发（比如页面的子请求、AJAX请求、甚至误路由的静态资源请求），每次触发都会强制覆盖$_SESSION['token']，导致表单提交时的token与session中存储的不匹配。以下是两种可行的解决方案：

方案1：优先使用WordPress原生CSRF防护机制（推荐） #

WordPress内置了成熟的CSRF工具，无需手动实现token生成逻辑，原生机制已自动处理请求重复触发的问题：

生成CSRF Token（用于表单） #

在短代码或模板中调用wp_create_nonce()生成专属场景的token：

function myprofile_form_shortcode() {
    // 生成对应"更新个人资料"动作的nonce
    $csrf_nonce = wp_create_nonce('myprofile_update_action');
    
    ob_start();
    ?>
    <form method="post" action="<?php echo esc_url(get_permalink()); ?>">
        <!-- 隐藏域存储CSRF Token -->
        <input type="hidden" name="myprofile_csrf" value="<?php echo esc_attr($csrf_nonce); ?>">
        <!-- 其他表单字段 -->
        <input type="text" name="user_name" placeholder="用户名">
        <button type="submit">保存修改</button>
    </form>
    <?php
    return ob_get_clean();
}
add_shortcode('myprofile_form', 'myprofile_form_shortcode');

验证CSRF Token（处理表单提交） #

在表单提交逻辑中用wp_verify_nonce()验证：

function handle_myprofile_submit() {
    // 判断是否是表单提交请求
    if (!isset($_POST['myprofile_csrf']) || !isset($_POST['user_name'])) {
        return;
    }

    // 验证CSRF Token
    if (!wp_verify_nonce($_POST['myprofile_csrf'], 'myprofile_update_action')) {
        wp_die('CSRF验证失败，请重试');
    }

    // 这里处理表单提交逻辑，比如更新用户资料
    $user_name = sanitize_text_field($_POST['user_name']);
    wp_update_user(['ID' => get_current_user_id(), 'display_name' => $user_name]);
    
    wp_redirect(get_permalink());
    exit;
}
add_action('template_redirect', 'handle_myprofile_submit');

方案2：修复自定义Token的生成逻辑 #

如果一定要保留自定义session token的实现，需要添加两个关键限制：仅主请求执行、仅无有效token时生成：

修改后的functions.php代码：

function generate_csrf_token() {
    // 排除AJAX、后台、子请求，仅处理页面主请求
    if (!is_main_query() || wp_doing_ajax() || is_admin()) {
        return;
    }

    if (is_page('myprofile')) {
        // 检查session状态，避免重复启动
        if (session_status() === PHP_SESSION_NONE) {
            session_start();
        }

        // 仅当session中无有效token时才生成，避免覆盖已有值
        if (!isset($_SESSION['token']) || empty($_SESSION['token'])) {
            $token = md5(uniqid(mt_rand(), true));
            $_SESSION['token'] = $token;
        }
    }
}
add_action('template_redirect', 'generate_csrf_token', 1);

关键修改点说明 #

• is_main_query()：确保只在页面的主查询请求中执行，排除插件、主题发起的子请求
• wp_doing_ajax()：排除AJAX请求，避免异步调用时重复生成token
• session_status()检查：防止重复调用session_start()引发PHP报错
• token存在性判断：仅当session中无有效token时才生成，不会每次请求都覆盖原有值

排查重复触发的根源 #

如果想确认是哪个请求触发了函数，可以临时添加日志排查：

function generate_csrf_token() {
    // 写入日志到wp-content/debug.log（需开启WP_DEBUG_LOG）
    error_log(
        "CSRF函数触发：请求URI=" . $_SERVER['REQUEST_URI'] 
        . " | 是否主查询=" . (is_main_query() ? '是' : '否')
        . " | 是否AJAX=" . (wp_doing_ajax() ? '是' : '否')
    );
    
    // 原有逻辑...
}

查看日志即可定位重复触发的请求来源（比如/favicon.ico被误路由到myprofile页面，或某插件的定时请求）。

内容的提问来源于stack exchange，提问作者Creepy