問題タブ [aws-http-api]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
0 に答える
92 参照

amazon-web-services - AWS::Serverless::HttpApi Cors 設定は POST では機能しますが、OPTIONS では機能しません

私はしばらく CORS と戦ってきましたが、アイデアが尽きてしまいました。私はAWS::Serverless::HttpApiSAMを介して展開しています。この API には現時点でエンドポイントが 1 つしかなく、 への POST リクエストを受け取ります/auctions。PostMan でテストすると動作しますが、もちろん他の場所でテストすると恐ろしいpreflight failedエラーがスローされます。過去数日間、私はさまざまなことを試してきましたが、何もうまくいきませんでした. これが私の現在の状態ですtemplate.yaml

このテンプレートには DynamoDb テーブルを作成する兄弟テンプレートがありますが、その部分は正常に機能しているため省略します。オプションラムダハンドラーは次のとおりです(ボディを追加してもヘッダーには影響しませんでした):

そして、POST ハンドラーから送信する成功応答:

オプション ラムダ ハンドラーを追加する前は204、allow-origin ヘッダーなしで OPTIONS リクエストからの応答を受け取っていましたが、ハンドラーを追加したので、200期待どおりに取得しましたが、ヘッダーはまだありません。この構成では、PostMan を介して同じヘッダーを持つ要求を送信すると、POST にヘッダーが含まれますが、OPTIONS 要求では欠落します。

私が試したこと:

  1. CorsConfiguration: true
  2. オリジンのハードコーディング

私が読んだこと:

  1. AWS API ゲートウェイに存在しない CORS "Response to preflight..." ヘッダーを修正し、増幅する
  2. https://aws.amazon.com/premiumsupport/knowledge-center/no-access-control-allow-origin-error/
  3. https://www.serverless.com/blog/cors-api-gateway-survival-guide/
  4. https://aws.amazon.com/blogs/compute/configuring-cors-on-amazon-api-gateway-apis/
  5. https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-cors-errors/
  6. https://github.com/aws/aws-sam-cli/issues/2637
  7. https://forums.aws.amazon.com/thread.jspa?threadID=252972
  8. AWS Lambda HTTP API ゲートウェイ統合で CORS が不可能
  9. 私が見つけることができる他の aws cors の質問。

POST リクエストにヘッダーが存在するという事実は、何かが機能していることを示しています。あるリクエストでは機能するのに、他のリクエストでは機能しない理由がわかりません。

0 投票する
1 に答える
44 参照

amazon-web-services - モバイルアプリケーションに AWS HTTP API ゲートウェイを選択してもよろしいですか?

アプリケーションにどの aws apigateway バージョンを選択するかを決定しようとしています (HTTP と REST API ゲートウェイ)。

AWS HTTP API ゲートウェイを試して、ユースケースでうまく機能するかどうかを確認しています。

これらは私の要件です:

  1. 唯一のクライアントはモバイル アプリケーションです。
  2. 残りの API は、ログインしているユーザーのみがアクセスできます
  3. cognitoオーソライザーでcognitoを使いたい
  4. 私のバックエンドは、内部アプリケーション ロード バランサーを介して公開されるラムダ サービスと HTTP REST サービスの組み合わせです。

すべてがサポートされているようです。唯一の懸念は、API キーを使用したことですが、この機能は現在 HTTP API ゲートウェイではサポートされていません。

API キーなしで HTTP を使用する場合、セキュリティ上の懸念はありますか? モバイル アプリからのリクエストのみにアクセスを制限するにはどうすればよいでしょうか?