「WordPressにAPIで投稿する」
この簡単なはずの作業が、なぜかできません。
ログイン情報が間違っていると表示されるけれど、何度確認しても正しい。何が悪いのか、なかなかわかりませんでした。
もしあなたが今、WordPressのAPI連携で原因不明のエラーに遭遇しているなら。この記事は、てくてくコンサルの失敗談から、解決のヒントをお届けします。
―――
セキュリティ対策は、大企業に限らず、小さな会社でも大切です。特にサーバーやWebサイトの管理となると、思わぬ落とし穴があるもの。
まさに、私が先日ハマったWordPressのAPI連携トラブルがそうでした。
「ログインしていません」の魔物
ブログの自動投稿を試そうと、WordPressのREST APIを使いました。
ユーザー名とパスワードを設定し、いざテスト投稿。
APIからの返答は「ログインしていません」。
私「（え？なんで？パスワード、合ってるはず…）」
もう一度、パスワードを確認。打ち直す。コピペも試す。
APIからの返答は「ログインしていません」。
私「（ぐぬぬ…）」
ひょっとして、パスワードを間違えているのか？
念のため、わざと間違ったパスワードで試してみます。すると…
APIからの返答は「ログインしていません」。
私「Whaaaat!?」
正しいパスワードでも、間違ったパスワードでも、存在しないユーザー名でも、APIからの返答は常に同じ「ログインしていません」でした。
これはつまり、WordPressに認証情報が届いていない可能性が高い、ということです。
ログインという最初の関門で、すでに足止めを食らっていました。😅
凡人の疑心暗鬼、そして迷走
パスワードが悪いのではない。ユーザー名でもない。
となると、疑うべきはAPI設定そのものです。
私は、まるでレベル上げをするかのように、考えられる原因を一つずつ潰していきました。
- .htaccessの設定：APIアクセスを許可する記述があるか？ → 確認、問題なし。
- ヘッダーを通すスニペット：認証情報を正しく渡せているか？ → 様々なコードを試すも変化なし。
- テーマの変更：テーマが干渉している可能性は？ → デフォルトテーマに変更するも、やはり「ログインしていません」。
- 全プラグインの停止：プラグインの競合は？ → 全て停止しても、状況は変わらず。
WordPressの「サイトヘルス」を確認すると、「認証ヘッダーは動作中」と表示されています。
私「（ほら見たことか！ちゃんと動いてるじゃないか！）」
しかし、これはサーバーが自分自身に送るテストパスで、外部からの通信とは経路が違うのです。この時私は、その決定的な違いに気づいていませんでした。
試すたびに、私のまばたきの回数は通常運転ではなくなっていきました。⏰
このままでは、ブログ自動投稿どころか、API連携の魔物に時間を吸い取られてしまいます。
突破口は「XML-RPC」
ふと、昔ながらのWordPress APIである「XML-RPC」を思い出しました。
REST APIが認証情報をヘッダーで渡すのに対し、XML-RPCは認証情報をリクエストの本文に含めます。
同じユーザー名とパスワードで、XML-RPCを使ってテストリクエストを送ってみると…
ピロン。
なんと、あっさり認証が通りました。
私「通った…！」
この瞬間、私は確信しました。問題は、パスワードやWordPressの設定ではなく、外部からの「ヘッダー認証」が何らかの理由でブロックされていることにある、と。
そして、その原因は一つしかありません。
サーバーに設定された「ファイアウォール」です。
ファイアウォールのログ、そして自爆
サーバーのファイアウォールログを確認しました。
すると、そこに鮮明に記録されていました。
コードの断片（スニペット）を保存する操作がSQLインジェクション対策のルールに、削除のリクエストが別のルールに引っかかっていたのです。⚠️
私「（えぇぇ…！まさか、こんなところに落とし穴が…！）」
サーバーの手前にある仕組みで、認証の情報（ヘッダー）が途中で落ちていたのです。サーバー環境によっては、こうしたことが起きます。
サイトヘルスでは「認証ヘッダーは動作中」と表示されていましたが、それはあくまでサーバー内部のチェック。外部からの通信は、ファイアウォールという別の関所を通っていたのです。
私「…大変失礼いたしました。」
またしても、WordPressでもなく、原因は私の確認不足にありました。まるでブログ下書きで無限修正ループにハマった時のようです。
パスワードを疑い、WordPressの設定を疑い続けたこのクエスト。
ファイアウォールのログを、もっと早く読むべきだったのです。📝
―――
API連携トラブルで無駄な時間を減らす3つのステップ
今回の失敗から、API連携でつまずいたときに、無駄な時間を減らすための教訓を得ました。
1. エラーメッセージを深読みしない
「ログインしていません」「認証失敗」といったメッセージは、表面的な情報に過ぎません。今回のケースのように、認証情報がそもそもWordPressに届いていない可能性もあります。メッセージが示す内容に囚われすぎず、「なぜこのメッセージが出たのか」を疑いましょう。
2. まずはファイアウォールログを確認する
WebサーバーやCDN、ロードバランサーなど、WordPressサイトの前に位置するセキュリティ関連のログを真っ先に確認します。外部からの通信が、どこでブロックされているのかを特定するためです。特に、REST APIはヘッダー認証を使うため、ファイアウォールが誤検知しやすいことがあります。
3. 変数を1つずつ切り分けて検証する
問題の切り分けは、まるで実験です。パスワード、ユーザー名、APIエンドポイント、リクエスト形式など、疑わしい要素を1つずつ変えて試しましょう。今回はXML-RPCで認証が通ったことで、ヘッダー認証がブロックされているという仮説が立てられました。これにより、ファイアウォールという真の原因にたどり着くことができました。✅
今日からできる、APIトラブル回避の一歩
API連携は、便利な魔法ですが、使いこなすには魔物の潜む森を歩くようなもの。
今日15分、あなたのWebサイトやサーバーで、ファイアウォールやアクセスログの場所を確認してみませんか？いざという時に、どこを見ればいいかを知っているだけで、解決までの時間は劇的に短縮できます。
パスワードを疑う前に、ファイアウォールのログを読むべきだったのです。🐸
