よくある問題 Edit Page

私達は REST API をできるかぎり簡単なものにしようと努めていますが、API はそもそも難しいものです。ここに私達が直面している一連の問題を挙げます。

`/users/me`での認証エラー

現在のユーザーを示すエンドポイントがユーザー情報を元に/users/{id}へと302ロケーションヘッダー付きでリダイレクトされてしまいます。

とりわけこれがよく起きるのは、ブラウザリクエストにおいてです。ブラウザはXMLHttpRequestを使うときにHTTPリクエストに自動的に従ってしまいます。このブラウザの挙動を防ぐことはできません。

これが起きてしまう理由は認証タイプによって異なります:

OAuth 1 ではそれぞれのリクエストが署名付きであり、なおかつその署名は送信されるリクエストごとに一意であることが求められます。リダイレクトによって同じ認証ヘッダーが送信される可能性がありますが、異なるリクエストデータでは署名の確認に失敗してしまいます。
クッキー認証 はリクエストにニンスを含めて送信します。URLに含めて送信する場合、このデータはリダイレクトURLに渡されません。

リダイレクトはやっかいですが、これは意図した挙動です。ロケーションヘッダーが意味すのは、現在のルート（users/me）がデータにとって正式なソースではなく、単なるデータへのポインターだということです。

ブラウザのような信頼出来ないクライアント上でこの問題をうまくこなすために、APIはリクエストを”envelope”（包む）機能を提供しています。これにより通常のステータスコードとヘッダーを受け取り、データはその代わりにレスポンスボディへと移されます。この結果、APIはステータスコード200を返し、追加ヘッダーはありません。

たとえば、このようなこのようなレスポンスにおいて……

HTTP/1.1 302 Found
Location: http://example.com/wp-json/wp/v2/users/42

{
	"id": 42,
	...
}

envelopeを実行するには、リクエストURLに_envelopeパラメータを含めます（例 /users/me?_envelope）。envelopeすることで代わりに次のようなレスポンスへと変更します。

HTTP/1.1 200 OK

{
	"status": 200,
	"headers": {
		"Location": "http://example.com/wp-json/wp/v2/users/42",
	},
	"body": {
		"id": 42,
		...
	}
}

メタへのアクセス

APIで投稿メタにアクセスしようとすると、あなたは問題に直面するかもしれません。これは私達がメタへアクセスするために少し複雑なルールを用いているからです。概要を説明します。

（注：私たちはこの動作の変更を検討しています。ご意見があればぜひ教えて下さい！）

シリアライズされたメタ

どんな形であれ、シリアライズされたデータはAPIで許可されていません。シリアライズされたデータが保存されたメタを読み取ること、シリアライズされたデータでメタを作成または更新すること、そしてシリアライズされた値を現在持っているメタを更新することも含めて許可されていません。

これにはいくつかの理由があります：

JSONは不可逆である - PHPが安全に保存できるデータのすべてをJSONが持てるわけではありません。特にカスタムオブジェクトは表現できませんし、連想配列とオブジェクトには違いがありません。
シリアライズされたデータはプライベートなデータを見えるようにしてしまう - シリアライズされたデータはオブジェクトのprotectedやprivateはプロパティを含むため、もしかしたらAPI上で晒すのは危険かもしれません。また、外部に晒してはならない内部的なクラス構造やプライベートなコードベースを晒してしまう可能性もあります。
シリアライズされたデータはセキュリティ上の問題がある - シリアライズされたデータを許可してしまうと、カスタムオブジェクトの入力を許すことになり、結果としてサーバーでオブジェクトが作られてしまうかもしれません。これは基本的にRemote Code Execution脆弱性の一種であり、セキュリティバグとしては最悪クラスです。

これらの理由からシリアライズされたデータはいかなる形でも許可されていません。

保護されたメタ

保護されたメタとは、キーが_文字から始まるか、その他の方法（例：フィルター）で保護されているすべてのメタのことです。これらのメタフィールドは内部的な利用のみを想定されており、その結果、APIで自動的にさらされることはありません。

その他のメタ

上記のいずれの基準にも適合しないメタは、APIで利用可能です。しかしながら、そのメタが付与された投稿の編集権限があるユーザーに認証された場合だけデータが利用可能になります。

これは直感に反するように思える（なぜならすでにプライベートなメタは除外しているから）かもしれませんが、これはWordPressの管理画面がカスタムフィールドのメタボックスを持っているからです。このおかげで誰でもメタを登録することなしにカスタムメタを投稿に付与でき、しばしばパワーユーザーによって編集過程の内部的なノートとして使われています。基本的には自由入力のテキストフィールドであることによって、それを晒すことがユーザーのプライバシーを侵害することになりうるのです。