WordPressユーザープロフィールにApplication Passwordが表示されない

アシスタントが使用するURLが実際にはHTTPSで配信されていません。

変更前にWordPress、プラグイン、クライアント、コネクター、サーバーのバージョンを記録します。

考えられる原因

• アシスタントが使用するURLが実際にはHTTPSで配信されていません。
• ブラウザーはHTTPSですが、オリジン側のWordPressが安全なリクエストとして認識していません。
• セキュリティプラグイン、must-useプラグイン、またはカスタムフィルターがApplication Passwordを全体で無効にしています。
• 連携が選択したWordPressユーザーではApplication Passwordを利用できません。
• 認証情報がクライアントの想定とは異なるWordPressユーザーに属しています。

診断手順

1. 変更前にWordPress、プラグイン、クライアント、コネクター、サーバーのバージョンを記録します。
2. アシスタントが使用する正確なURLが有効なHTTPSで開くことを確認します。
3. 現在の環境でApplication Passwordが全体として利用可能か確認します。
4. 対象のWordPressユーザーでApplication Passwordを利用可能か確認します。
5. 現在の管理者が所有者だと決めつけず、候補となる全ユーザーを確認します。
6. 秘密情報を表示せず、対象プロフィールのApplication Password欄を確認します。

最小限の修正を適用する

1. Application Password認証を有効にする前に、正確なWordPress URLとREST URLをHTTPSで提供します。
2. 信頼済みプロキシとオリジンの処理を修正し、WordPressが元のHTTPSリクエストを認識できるようにします。
3. 意図したセキュリティ方針を確認した後にのみ、Application Passwordを無効にするフィルターを削除または限定します。
4. 連携が必要な専用ユーザーだけにApplication Passwordを許可します。
5. 人間の管理者を再利用せず、専用のWordPress IDを作成します。

結果を検証する

• すべての認証情報に所有者、目的、作成者、状態、取り消し判断があります。
• 認証済みリクエストが意図した専用WordPressユーザーに対応します。
• RESTインデックスが正規HTTPS URLから応答し、期待するnamespaceを公開します。
• 最終記録にバージョン、証拠、変更、検証、ロールバックが含まれ、秘密情報はありません。

避けるべき対応

• 接続テストを通す目的だけで管理者権限を付与しないでください。
• Application Password、Authorizationヘッダー、トークン、Cookieをプロンプト、チケット、ログ、画像に含めないでください。
• 最初の診断手順としてWordPressコアや第三者プラグインのファイルを編集しないでください。
• 信頼経路を確認する前に、未検証の恒久的なプロキシ回避策を追加しないでください。
• 所有者、目的、最終使用を記録する前に未知の認証情報をすべて削除しないでください。

関連ガイド

• WordPressのApplication Passwordが無効な場合の原因と確認
• AI接続のためのWordPressアプリケーションパスワード
• WordPressでWAPのApplication Passwordを確認する方法
• AIアシスタントが使用するWordPressユーザーを特定する方法
• Cloudflareまたはリバースプロキシ経由でWordPressがHTTPSを検出しない