問題タブ [serverless-framework]

フロントエンドとして反応するSPAを構築し、サーバーレス（AWSラムダ）フレームワークにはバックエンドがあります。

React アプリは S3 にデプロイされています。このアプリは、AWS API Gateway を介してラムダ関数 (サーバーレス) と通信します。

S3 ドメインとバックエンド (AWS API Gateway、AWS ラムダ、DynamoDB) にある反応アプリは別のドメインにあるためです。CORS の問題が発生します。

CORS の問題を修正するために、Access-Control-Allow-Originヘッダーを反応アプリのドメイン URLとしてハードコーディングしました。したがって、バックエンドは発信元が既知のソースからのものであることを理解し、origin-CORS エラーを解決します。

ただし、リクエストのCookieにアクセスするには、「Access-Control-Allow-Credentials」と呼ばれる別のヘッダーがtrueである必要があります。

IF Access-Control-Allow-Originが "*" の場合、プライバシーの懸念からAccess-Control-Allow-Credentialsをfalseにする必要があります。

そのため、Access-Control-Allow-OriginをReact の domainに設定した場合、Access-Control-Allow-Credentialsは trueになる可能性があります。

API ゲートウェイの応答メソッドと統合の応答メソッドにAccess-Control-Allow-Credentialsヘッダーを追加しました。問題は、応答としてクライアント側でAccess-Control-Allow-Credentialsヘッダーを取得していないことです。これ以外のすべてのヘッダーを取得しています。API Gateway コンソールをテストするとヘッダーが表示されますが、postman とブラウザーでテストすると、上記のヘッダーが表示されません。

クライアントのヘッダーは

しかし、AWS API Gateway をテストすると、これが得られます。

問題は、Access-Control-Allow-Credentialsヘッダーがブラウザーとポストマンで応答として取得されず、AWS API Gateway コンソールでテストすると表示されることです。何が問題なのですか?

サーバーレスにいくつかの AWS Lambda 関数があり、同じ sendEmail 関数を何度も書いていることがわかりました。クライアントをセットアップし、いくつかの微調整を加えて SES 応答を作成するだけです。これを、他の関数によって呼び出される単一の関数に抽象化するのが最善であると判断しました。私のフォルダー構造は次のようになります。

私の質問は、他の展開からこの電子メール機能を呼び出すにはどうすればよいですか? 呼び出し元の関数の serverless.yml ファイル (既に適切な SES IAM 権限を持っています) に完全修飾パスを含めるのと同じくらい簡単ですか、それともイベント スケジュールの代わりにトリガーを持つ独自の serverless.yml ファイルが必要ですか? ? 独自の展開に属している場合、他の機能から利用することはできますか? 明らかに、私は前者を好みますが、それをどのようにまとめるべきかについては混乱しています.

NodeJS プロジェクトを API Gateway に移行中ですが、Lambda からファイルをダウンロードする方法がわかりません。

これは、私のローカル Node プロジェクトの応答コードのスニペットです。

応答へのパイピングで、PDF を取得できました。

これは、サーバーレスを使用したラムダ関数のスニペットです。

これが私のserverless.ymlのエンドポイントです

パイプする Lambda の応答オブジェクトへの参照を取得する方法がわかりません。それは可能ですか？別の方法はありますか？

アップデート

最終的に、base64 でエンコードされた PDF バイナリを JSON 応答で返し、クライアントでデコードすることで、この問題を解決しました。注: 応答マッピング テンプレートで base64 デコードを使用しても機能しませんでした。

サンプルコード:

302 http ステータスを使用してリダイレクト Web ページの応答テンプレートを作成したいと考えています。awsラムダユーザーインターフェイスを使用して手動で実行できますが、サーバーレスフレームワークバージョンv1で実行する必要があります.

次のコードを試しました。

しかし、それは機能していません。ステータスコード付きのレスポンステンプレートの書き方.?

Dynamodb へのアクセスを失うことなく、サーバーレス フレームワーク (v 0.5.6) を使用して Lambda 関数から AWS Elasticache クラスターにアクセスしようとしています。このGistを使ってみましたが、うまくいきませんでした。Lambda 関数内で、最初に行うことは Redis インスタンスに接続することですが、タイムアウトが発生し続けます。関数内の CloudFormation 出力変数とその可視性と VPC の Lambda ロール/ポリシーを再確認しましたが、まだ何もありません...ここで提案されているように、パブリックおよびプライベートサブネット、NAT、およびインターネットゲートウェイを作成するために、CloudFormation およびサーバーレスで VPC およびセキュリティグループを作成する方法に関するガイドも見つかりませんでした。誰でも助けることができますか？

最近、サーバーレス プロジェクトを更新しましたが、ここ数回の更新で多くのことが変更されていることがわかりました。

https://serverless.com/

複数のラムダ関数と API ゲートウェイ エンドポイントを同じプロジェクトに関連付ける正しい方法を完全には理解していません。古いサーバーレスでは、すべてのラムダとエンドポイントを完全に独立した関数として持っていますが、これは私にとってはうまくいきました。

おそらく、両方の「サービス名」が同じであるため、2番目のラムダ関数が最初のラムダ関数をオーバーライドしようとすると、これ以上できないようです。API Gateway の同じ API に両方の残りのエンドポイントが必要なため、サービス名は同じです。サーバーレスはサービス名に基づいて API 名を作成するため。

そこで、両方の機能を同じ「サービス」に追加しようとしました。これはほとんどの部分で機能しましたが、すべての関数のカスタム ロール ステートメントを同じロールに含める必要があることを除いて (この 1 つのロールがすべての関数にリンクされているため)。個々の機能に必要以上の権限を効果的に付与する。もう 1 つの問題は、さまざまな関数のすべてのハンドラー ファイルが各関数展開バンドルに配置されていることです。

したがって、基本的に、同じプロジェクトに関連しているが機能が異なる複数の機能を持つ正しいアプローチが何であるかはわかりません。以前は意味がありましたが、今は意味がありません。

誰かが私にいくつかの指針を与えることができれば

ありがとう