REST APIを無効にできますか?
REST APIを無効にするべきではありません。そうすると、APIがアクティブであることに依存するWordPress管理機能が壊れてしまいます。ただし、フィルターを使用してAPIの消費者が認証されることを要求することができ、これにより匿名の外部アクセスを効果的に防ぐことができます。詳細については以下を参照してください。
すべてのリクエストに認証を要求する
すべてのREST APIリクエストに認証を要求するには、rest_authentication_errors
フィルターにis_user_logged_in
チェックを追加します。
注意:受信するコールバックパラメータは、null
、WP_Error
、またはブール値のいずれかである可能性があります。パラメータのタイプは認証の状態を示します:
null
:まだ認証チェックが行われておらず、フックコールバックはカスタム認証ロジックを適用する可能性があります。- ブール値:以前の認証方法チェックが行われたことを示します。ブール値
true
はリクエストが正常に認証されたことを示し、ブール値false
は認証が失敗したことを示します。 WP_Error
:何らかのエラーが発生しました。
add_filter( 'rest_authentication_errors', function( $result ) {
// If a previous authentication check was applied,
// pass that result along without modification.
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}
// No authentication has been performed yet.
// Return an error if user is not logged in.
if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_not_logged_in',
__( 'You are not currently logged in.' ),
array( 'status' => 401 )
);
}
// Our custom authentication check should have no effect
// on logged-in requests
return $result;
});
プラグイン内でPHPからAPIリクエストを行うことはできますか?
はい、できます!他のWordPressコード内でAPIリクエストを行うには、https://developer.wordpress.org/reference/functions/rest_do_request/を使用します:
$request = new WP_REST_Request( 'GET', '/wp/v2/posts' );
// Set one or more request query parameters
$request->set_param( 'per_page', 20 );
$response = rest_do_request( $request );
_embedパラメータを内部リクエストで使用するにはどうすればよいですか?
リクエストオブジェクトに_embed
パラメータを設定しても機能しません。
$request = new WP_REST_Request( 'GET', '/wp/v2/posts' );
$request->set_param( '_embed', 1 );
$response = rest_do_request( $request );
代わりに、WP_REST_Server::response_to_data
関数を手動で呼び出します。
$request = new WP_REST_Request( 'GET', '/wp/v2/posts' );
$response = rest_do_request( $request );
$data = rest_get_server()->response_to_data( $response, true );
var_dump( $data['_embedded'] );
?filter=クエリパラメータはどうなりましたか?
REST APIがWordPressコアに統合されたとき、?filter
クエリパラメータは将来の互換性とメンテナンスの問題を防ぐために削除されました。?filter
クエリパラメータを使用してAPIに任意のWP_Query引数を渡す機能は、REST APIプロジェクトの初期段階で必要でしたが、ほとんどのAPIレスポンスフィルタリング機能は、?categories=
、?slug=
、?per_page=
のようなより堅牢なクエリパラメータによって置き換えられました。
可能な限りファーストパーティのクエリパラメータを使用するべきです。ただし、https://github.com/wp-api/rest-filterプラグインは、必要に応じてAPIリクエストに任意の?filter
値を渡す機能を復元します。
クエリパラメータが機能していません
もし?page=2
や?_embed
のようなクエリパラメータが効果を持たない場合、サーバーがそれらを正しく検出するように構成されていない可能性があります。Nginxを使用してウェブサイトを提供している場合は、サイト構成内にtry_files
行を探してください。それが次のように見える場合:
try_files $uri $uri/ /index.php$args;
これを次のように変更します:
try_files $uri $uri/ /index.php$is_args$args;
<a name="why-is-authentication-not-working"></a>
## なぜ認証が機能しないのですか?
認証ヘッダーを送信しているのにリクエストが受け入れられない場合、CGI環境を使用していると、ウェブサーバーがヘッダーを削除している可能性があります。これを解決するために、以下の適切な構成を追加してみてください。
<a name="apache"></a>
### Apache
構成ファイルまたは.htaccessに次の内容を追加します:
``````bash
<IfModule mod_setenvif>
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
</IfModule>
`
Nginx
サーバー構成のfastcgiセクションに次の内容を追加します:
fastcgi_pass_header Authorization;
なぜREST APIは受信したOriginヘッダーを検証しないのですか?これにより、私のサイトがCSRF攻撃にさらされるのですか?
クロスオリジンリソースシェアリング(CORS)は、ウェブサイトがどのオリジン(外部サイト)に自サイトのデータへのアクセスを許可するかを制御できるメカニズムです。CORSは、クロスサイトリクエストフォージェリ(CSRF)として知られる特定のタイプの攻撃を防ぎます。ただし、WordPressにはノンスを使用した既存のCSRF保護メカニズムがあります。CORS制限を厳しくすると、一部の認証方法が妨げられるため、WordPress REST APIはCORSの代わりにCSRF保護のためにノンスを使用します。
WordPress REST APIは受信リクエストのOriginヘッダーを検証しないため、公開REST APIエンドポイントは任意のサイトからアクセス可能です。
これは意図的な設計決定ですが、未知のオリジンからのアクセスを防ぎたい場合は、デフォルトのrest_send_cors_headers
関数をrest_pre_serve_request
フィルターフックから解除し、その同じフィルターに自分の関数をフックして、より厳格なCORSヘッダーを指定することができます。