問題
- Digest Auth を使用している場合、7.1 でエンドポイントにアクセスすることはできません。これは、より高いバージョンで使用されているのと同じ構成を使用しています (この例では 7.3 を使用します)。
- 使用する再現手順については、次のとおりです。
- サービスを呼び出す方法で使用されているのと同じエンドポイント、つまり http://localhost:8080/o/headless-delivery/v1.0/sites/20127/blog-postings/,
- ダイジェスト認証を使用した POSTMAN。
- Liferay で、この設定を System Settings/API Authentication/Digest Authenticationに追加します。
- ダイジェスト認証を強制 (チェック)。
- 有効 (チェック)。
- URL には (/o/headless-delivery/v1.0/sites/[groupId]/blog-postings/) が含まれます - システムのグループ ID (この場合は 20127) を使用します。
-
Postman で、この画像に示すように新しい GET 要求を作成して送信します。
-
結果：
7.3: 成功:
7.1: エラー (403 禁止):
Environment
- このソリューションは 7.1 でテストされました。
解決策
-
ポータルにリクエストが送信されるたびに、フィルター チェーンを通過して AuthVerifierFilterに到達します。
AuthVerifierFilter 、 AuthVerifierPipelineを使用してリクエストを検証する AccessControlImpl によって実装された AccessControl を使用します。
AuthVerifierPipeline は、リクエストを検証するために次のワークフローを実装します。
- リクエストに応じて可能な authVerifierConfigurations を取得します
- 可能性のある AuthVerifierConfiguration を対応する AuthVerifier で確認して、リクエストの検証を試みます。
- 肯定的な検証がない場合は、リクエストをゲストとして行うことができるかどうかを後で確認するゲストの結果を作成します。
Digest Auth の特定のケースでは、7.3 と 7.1 の間で動作が変更され、DigestAuth が要求を検証する候補として選択されなくなりました。
これは、7.1 ではアプリケーションのコンテキストを削除するリクエストのパスを処理するためです。そのため、 /o/headless-delivery/v1.0/sites/20127/blog-postingsへのリクエストがある場合、 /o/headless-delivery 部分を残し、 /v1.0/sites/20127/blog-postings 残して、Digest Auth 構成を確認します。
-
7.1 では、URL が /v1.0/sites/20127/blog-postingsに含まれる Digest Auth 構成がある場合、正しく機能し、成功した応答と結果が返されます。
-
7.3 では、説明したように、代わりに Digest Auth 構成を完全なパス /o/headless-delivery/v1.0/sites/20127/blog-postingsにする必要があります。
追加情報