クッキー認証
クッキー認証は、WordPressに含まれる標準的な認証方法です。ダッシュボードにログインすると、これによりクッキーが正しく設定されるため、プラグインやテーマの開発者はログインしたユーザーがいるだけで済みます。
しかし、REST APIにはノンスと呼ばれる技術が含まれており、CSRFの問題を回避します。これにより、他のサイトがあなたに明示的に意図せずにアクションを実行させることを防ぎます。これにはAPIのための少し特別な処理が必要です。
組み込みのJavaScript APIを使用している開発者にとって、これは自動的に処理されます。これは、プラグインやテーマのためにAPIを使用する推奨方法です。カスタムデータモデルは、wp.api.models.Base
を拡張して、カスタムリクエストに対してこれが正しく送信されることを保証できます。
手動でAjaxリクエストを行う開発者は、各リクエストにノンスを渡す必要があります。APIは、アクションがwp_rest
に設定されたノンスを使用します。これらは、_wpnonce
データパラメータ(POSTデータまたはGETリクエストのクエリ内)を介してAPIに渡すことができます。または、X-WP-Nonce
ヘッダーを介して渡すこともできます。ノンスが提供されない場合、APIは現在のユーザーを0に設定し、リクエストを未認証リクエストに変換します。たとえWordPressにログインしていてもです。
注意: 最近まで、ほとんどのソフトウェアはDELETE
リクエストのサポートが不十分でした。たとえば、PHPはDELETE
リクエストのリクエストボディをスーパーグローバルに変換しません。そのため、ヘッダーとしてノンスを提供することが最も信頼性の高いアプローチです。
この認証方法はWordPressのクッキーに依存していることを念頭に置くことが重要です。そのため、この方法はREST APIがWordPress内で使用され、現在のユーザーがログインしている場合にのみ適用されます。さらに、現在のユーザーは実行されるアクションを実行するための適切な権限を持っている必要があります。
例として、組み込みのJavaScriptクライアントがノンスを作成する方法は次のとおりです:
<?php
wp_localize_script( 'wp-api', 'wpApiSettings', array(
'root' => esc_url_raw( rest_url() ),
'nonce' => wp_create_nonce( 'wp_rest' )
) );
これは基本モデルで使用されます:
options.beforeSend = function(xhr) {
xhr.setRequestHeader('X-WP-Nonce', wpApiSettings.nonce);
if (beforeSend) {
return beforeSend.apply(this, arguments);
}
};
以下は、jQuery AJAXを使用して投稿のタイトルを編集する例です:
$.ajax( {
url: wpApiSettings.root + 'wp/v2/posts/1',
method: 'POST',
beforeSend: function ( xhr ) {
xhr.setRequestHeader( 'X-WP-Nonce', wpApiSettings.nonce );
},
data:{
'title' : 'Hello Moon'
}
} ).done( function ( response ) {
console.log( response );
} );
カスタムエンドポイント内でノンスが有効であることを確認する必要はないことに注意してください。これはrest_cookie_check_errors()
で自動的に行われます。
アプリケーションパスワードによる基本認証
5.6以降、WordPressにはアプリケーションパスワードが搭載されており、ユーザーの編集ページ(wp-admin -> ユーザー -> ユーザーの編集)から生成できます。
資格情報は、https://経由で提供されるREST APIリクエストに基本認証 / RFC 7617を使用して渡すことができます — cURLでの使用方法に関するドキュメントはこちら。
シンプルなコマンドラインスクリプトの例では、USERNAME、PASSWORD、HOSTNAMEをそれぞれの値に置き換えるだけです:
curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit
認証プラグイン
プラグインは、リモートアプリケーションから動作する代替の認証モードをサポートするために追加できます。いくつかの例としては、OAuth 1.0aサーバーやJSON Webトークンがあります。
また、基本認証プラグインもあります。
このプラグインは、すべてのリクエストにユーザー名とパスワードを送信する必要があり、開発およびテストのためにのみ使用すべきであり、つまり本番環境では使用すべきではありません。アプリケーションパスワードを使用すること(上記参照)が推奨されます。