WordPress中determine_current_user过滤器回调未触发致API认证失败

Let's break down why your OAuth2 authentication is working locally but failing on your remote site, and walk through actionable fixes:

Core Problem Recap #

Your local tests with WP OAuth Server v3.1.9 work perfectly for WordPress REST API authentication, but on the remote site:

• wp_get_current_user() returns false
• The plugin's authentication filter (at wp-oauth-main.php line 53) never runs
• Even your custom determine_current_user debug filter (priority 5) doesn't trigger

Likely Causes & Fixes #

1. Plugin/Theme Conflicts #

Security plugins (like Wordfence, iThemes Security) or aggressive caching plugins often interfere with authentication flows. They might terminate requests early, override user authentication logic, or block filter hooks before they can fire.

How to test:

• Disable all plugins except WP OAuth Server, then test the REST API authentication again. If it works, re-enable plugins one by one to find the conflicting one.
• Switch to a default WordPress theme (e.g., Twenty Twenty-Four) to rule out custom theme code blocking the filter.

2. Server Configuration Blocking Auth Headers #

Remote servers (especially Apache with mod_security or Nginx) sometimes strip or block the Authorization header required for OAuth2 token validation. Poorly configured rewrite rules can also break REST API routing entirely.

Fixes:

• Apache: Verify your .htaccess has the standard WordPress rewrite rules:

  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
  </IfModule>
  

  Temporarily disable mod_security to see if it's blocking the token request.
• Nginx: Ensure your config passes the Authorization header to PHP:

  location ~ \.php$ {
      fastcgi_pass unix:/var/run/php/php8.2-fpm.sock; # Adjust to your PHP version
      fastcgi_index index.php;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      include fastcgi_params;
      fastcgi_param HTTP_AUTHORIZATION $http_authorization; # Critical line
  }
  

3. Corrupted Plugin Files or Permissions #

It's possible the WP OAuth Server files didn't upload fully to the remote site, or incorrect file permissions are preventing WordPress from loading the plugin's hook registrations.

Fixes:

• Re-download WP OAuth Server v3.1.9 and overwrite the plugin directory on your remote site to ensure file integrity.
• Set plugin file permissions to 644 and directory permissions to 755 (standard for WordPress files).

4. determine_current_user Filter Is Being Removed/Overridden #

Some code might be removing the determine_current_user filter before WP OAuth Server can register its callback, or a high-priority filter is returning a user (or false) early, skipping subsequent callbacks.

Debug step:
Add this code to your remote site's wp-config.php to log all registered determine_current_user filters:

add_action('init', function() {
    global $wp_filter;
    if (isset($wp_filter['determine_current_user'])) {
        error_log(print_r($wp_filter['determine_current_user'], true));
    } else {
        error_log('determine_current_user filter is not registered');
    }
}, 1);

Check your server's PHP error log to see if filters are being removed or overridden by other code.

5. Incorrect Token Delivery in Remote Requests #

Double-check that your remote REST API requests are correctly sending the token. Ensure you're using the Authorization: Bearer <your-access-token> header, not just passing the token as a GET parameter (unless you explicitly enabled that option in WP OAuth Server settings, which isn't recommended for production).

Final Tips #

Start with the simplest checks first (plugin/theme conflict testing) before moving to server config or code debugging. Always check your remote server's PHP error logs—they often reveal hidden issues like fatal errors that stop plugin code from running entirely.

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