晚了，但可能对其他读者有帮助，因为我根据这个问题专门为 fetch() 承诺添加了代码。
我发现，WordPress 自动在其 cookie 中使用 nonce。
解决方案：权限回调函数检查cookie
WordPress：5.7.2 版
PHP：7.4 版
主机：hostmonster.com
客户端：Windows 10
浏览器：在 Chrome、Firefox、甚至 Edge 上测试 ? 工作
代码（您安装的主题的function.php中的PHP代码）：
add_action('rest_api_init', function() {
/**
* Register here your custom routes for your CRUD functions
*/
register_rest_route( 'my-endpoint/v1', '/upload/', array(
array(
'methods' => WP_REST_Server::READABLE, // = 'GET'
'callback' => 'get_data',
// Always allow, as an example
'permission_callback' => '__return_true'
),
array(
'methods' => WP_REST_Server::CREATABLE, // = 'POST'
'callback' => 'create_data',
// Here we register our permissions callback
// The callback is fired before the main callback to check if the current user can access the endpoint
'permission_callback' => 'prefix_get_private_data_permissions_check',
),
));
});
// The missing part:
// Add your Permission Callback function here, that checks for the cookie
// You should define your own 'prefix_' name, though
function prefix_get_private_data_permissions_check() {
// Option 1: Password Protected post or page:
// Restrict endpoint to browsers that have the wp-postpass_ cookie.
if ( !isset($_COOKIE['wp-postpass_'. COOKIEHASH] )) {
return new WP_Error( 'rest_forbidden', esc_html__( 'OMG you can not create or edit private data.', 'my-text-domain' ), array( 'status' => 401 ) );
};
// Option 2: Authentication based on logged-in user:
// Restrict endpoint to only users who have the edit_posts capability.
if ( ! current_user_can( 'edit_posts' ) ) {
return new WP_Error( 'rest_forbidden', esc_html__( 'OMG you can not create or edit private data.', 'my-text-domain' ), array( 'status' => 401 ) );
};
// This is a black-listing approach. You could alternatively do this via white-listing, by returning false here and changing the permissions check.
return true;
};
function create_data() {
global $wpdb;
$result = $wpdb->query(...);
return $result;
}
function get_data() {
global $wpdb;
$data = $wpdb->get_results('SELECT * from `data`');
return $data;
}
确保在您的 HTTP 请求中包含您的 HTML 页面 credentials: 'same-origin'，如上面之前的答案和 cmets 中正确说明的那样。
代码（HTML内嵌<script> ... </script>）：
<script>
// Here comes the REST API part:
// HTTP requests with fetch() promises
function getYourData() {
let url = 'https://example.com/wp-json/my-endpoint/v1/upload/';
fetch(url, {
method: 'GET',
credentials: 'same-origin', // <-- make sure to include credentials
headers:{
'Content-Type': 'application/json',
'Accept': 'application/json',
//'Authorization': 'Bearer ' + token <-- not needed, WP does not check for it
}
}).then(res => res.json())
.then(response => get_success(response))
.catch(error => failure(error));
};
function insertYourData(data) {
let url = 'https://example.com/wp-json/my-endpoint/v1/upload/';
fetch(url, {
method: 'POST',
credentials: 'same-origin', // <-- make sure to include credentials
headers:{
'Content-Type': 'application/json',
'Accept': 'application/json',
//'Authorization': 'Bearer ' + token <-- not needed, WP does not check for it
},
body: JSON.stringify(data)
}).then(res => res.json())
.then(response => create_success(response))
.catch(error => failure(error));
};
// your Success and Failure-functions:
function get_success(json) {
// do something here with your returned data ....
console.log(json);
};
function create_success(json) {
// do something here with your returned data ....
console.log(json);
};
function failure(error) {
// do something here ....
console.log("Error: " + error);
};
</script>
最后的想法：
'Authorization': 'Bearer ' + token 必须在 HTTP 请求的头部吗？
经过一些测试，我意识到 Permission Callback 中的if ( !isset($_COOKIE['wp-postpass_'. COOKIEHASH] )) { ... 不仅检查 Cookie 是否设置在客户端浏览器上，而且似乎还检查了它的值（JWT令牌）。
因为我像使用初始代码一样进行检查，传递了一个错误的令牌，消除了 cookie，或者让会话保持打开状态，但在后端更改了站点的密码（因此 WordPress 会创建一个新的令牌，因此设置的值wp_postpass_ cookie 会改变）并且所有测试都正确 - REST API 被阻止，不仅验证 cookie 的存在，而且验证它的价值（这很好 - 感谢 WordPress 团队）。
来源：
我在FAQ section 中找到了有关上述想法的以下资源：
Why is the REST API not verifying the incoming Origin header? Does this expose my site to CSRF attacks?
因为 WordPress REST API 不验证 Origin 标头
传入请求，因此可以访问公共 REST API 端点
从任何网站。这是一个有意的设计决策。
然而，WordPress 有一个现有的 CSRF 保护机制，它
使用随机数。
根据我目前的测试，WP 身份验证方式运行良好。
为 WordPress 团队点赞?
来自 WordPress REST API 手册的另外 2 个来源：
REST API Handbook / Extending the REST API / Routes and Endpoints
REST API Handbook / Extending the REST API / Adding Custom Endpoints
以及关于rest_cookie_check_errors()函数的WordPress 代码参考的1个源代码：
Reference / Functions / rest_cookie_check_errors()
对于那些对我的发现的完整故事感兴趣的人，请点击我的帖子链接，其中包含答案、代码 sn-ps 和其他发现。
How to force Authentication on REST API for Password protected page using custom table and fetch() without Plugin