問題タブ [lambda-authorizer]

S3 に画像をアップロードする別のラムダ関数を呼び出す API ゲートウェイをセットアップしようとしています。この機能は、POSTMAN などのアプリを使用している場合はうまく機能しますが、React を使用してブラウザーを実行すると、次のエラーが発生します。

私のAPIゲートウェイには、そのメソッド用に次の構成があります

この API はオーソライザーを使用します。私はAuth0 が提供するものを使用しており、コードをまったく編集していません。

そして、オーソライザーが呼び出す関数は、以下のような応答を返します (例: ハッピー パス):

ラムダ関数、認証プロバイダー、API ゲートウェイの両方を設定するのはこれが初めてなので、明らかな何かが欠けている可能性があります。また、フェッチ POST リクエストに追加しようとしましmode: no-corsたが、それでも非常によく似た方法で失敗します。

オーソライザーと画像をアップロードするラムダ関数のログを見ると、それらが呼び出されていないことがわかります。そのため、CORS エラーは API Gateway にあるようです。

いくつかのチュートリアルで、aws テンプレート yaml ファイルにオプションを追加することを見てきましAddDefaultAuthorizerToCorsPreflightたFalse。これは API Gateway コンソールのどこにも表示されません。

更新:カスタムオーソライザーをオフにして機能をテストしましたが、機能します。したがって、CORS は options メソッドと、ラムダ関数で返されるリクエストに対して機能することがわかっています。問題なのはカスタムオーソライザーです。

現在の流れは次のとおりです。

1. メソッドリクエスト - 認証: my-auth-0-authorizer
2. 統合リクエスト - タイプ: Lambda_proxy
3. ラムダ関数
4. 統合応答 - [グレー表示されたプロキシ統合は、応答を変換するように構成できません]
5. メソッドの応答: HTTP ステータス: プロキシ (Access-Control-Allow-Origin応答ヘッダーに含まれる)

オーソライザーが CORS 構成を尊重できるようにするには、何を変更するか、変更する必要がありますか?

更新: API ゲートウェイを 1 日放置した後、成功した応答が機能するようになりました (上記のフローを使用)。システムに不具合があったのか、予期せぬ事態が発生したのかはわかりませんが、現在は機能しています。まだ CORS の問題が発生していますが、現在は応答が悪いだけです。

カスタムオーソライザーが失敗しreturn context.fail("Unauthorized");、これが発生すると、ブラウザーで CORS エラーが発生します。4XX 応答に対して特別なゲートウェイ応答をセットアップする必要がありますか?

私は正常に動作する API Authorizer を持っていますが、ラムダ関数 (Python で記述) で取得した principalId にアクセスしたいと考えています。テンプレートマッピングの使用を提案している他の回答を見てきましたが、それを機能させることはできません。以下を使用して簡単なマッピングを作成しました。

Content-Type の場合: application/json そして、次の 2 つのオプションを試してください。

• リクエストの Content-Type ヘッダーに一致するテンプレートがない場合
• テンプレートが定義されていない場合 (推奨)

しかし、いずれにせよ、関数の変数にアクセスしようとすると、keyError が返されます。また、デフォルトで「コンテキスト」を介してアクセスするマッピングを試してみましたが、keyErrorも発生します。

それにアクセスするには、次を使用します。

また

しかし、どちらの場合もkeyErrorが発生します。

更新 1: これは参照用のコードです。関数とオーソライザーの両方が API で正常に動作します。唯一の問題は、関数で principalId を取得しようとするときです。

ラムダ関数コード:

承認者コード:

私のプロジェクトでは、現在、次のような方法で機能するレガシー認証があります。

1. API serviceコンテナで実行されているカスタム アプリケーションである と通信するクライアント (スタンドアロン) があります。
2. PKCE による OAuth をサポートするクラウド ID プロバイダー (IdP) が使用されます。ユーザーがログインページに移動し、コールバックにリダイレクトされると、通常のログインプロセスを介してトークンを提供します。
3. API service コールバックの受信者として機能します。したがって、ID プロバイダーtoken-1を取得してキャッシュに格納します。これに基づいて、変更されたtoken-2「計算された」token-1が異なるものをクライアントに返します。
4. クライアントが REST 呼び出しを行う必要がある場合、token-2JWT トークンで装飾します。呼び出しは、一致する API サービスに送られ、token-1IdP に対して検証できます。

API serviceクラウドネイティブのメカニズムを取り除く必要があります。AWS HTTP API ゲートウェイは、 JWT Authorizer 機能を使用して IdP と直接統合できると想定しています。残念ながら、機能を維持しなければならない現在のレガシー フローに影響を与えることはできません。

ただし、JWT オーソライザーと、クライアント向けトークンを IdP トークンに交換するクライアント エンドポイントの間に Lambda を挿入したいと考えています (実行していたことAPI serviceを実行します)。それは可能でしょうか、どうすればこれにアプローチできますか?