Kinesisストリームの場合、AWS APIGatewayを使用してプロキシAPIを作成しました。プロキシにpython Lambdaを使用してカスタムオーソライザーを追加しました。ラムダ関数の公開とAPIのデプロイ後、ゲートウェイテスト機能を使用してAPIを正常にテストできました。ログを確認できました。カスタム認証ラムダ関数からの詳細なプリントを含むcloudwatch認証が成功した後、APIGatewayはレコードをKinesisストリームにプッシュしました
ただし、Chrome Postmanクライアントから同じAPIを呼び出すと、500 Internal Server Errorが表示され、応答ヘッダーにX-Cache)が含まれます。 →クラウドフロントからのエラー、x-amzn-ErrorType→AuthorizerConfigurationException
Lambda auth関数は、APIの実行要求を許可するポリシーを返します。返されるポリシードキュメントは次のとおりです。
{ "policyDocument":{ "Version": "2012-10-17"、 "Statement": { "Action": "execute-api:Invoke"、 "Resource": "arn:aws:execute-api:us-east-1:1234567:myapiId/staging/POST/* " 、 " Effect ":" Allow " } }、 " primaryId ":" Foo " }
リクエストがChromeまたはcurlから失敗するのに、同じAPIテストがAPI Gatewayから正常に機能するのはなぜですか?
問題の原因を突き止めました。 pythonラムダ関数から、json文字列インスタンスを返していました。代わりにjsonオブジェクトである必要があります。APIGateway "test"からAPIをテストしたときに、同じラムダ関数がエラーにならなかったのは奇妙なことです。機能。しかし、APIがインターネット(curlまたはchrome)から呼び出された場合、失敗しました。
#return policy_string ... this is incorrect.
return json.loads(policy_string)
AuthorizerConfigurationExceptionは通常、権限エラーのためにAPIGatewayが承認者を呼び出せなかったことを示します。
APIGatewayによって呼び出されるように関数が適切に構成されていることを確認してください。これをリセットするのは簡単ですが、関数を削除して承認者に再度追加することです。その後、コンソールは必要な権限を追加するように求めます。
同じエラーに直面していました。私の場合はnodejs関数で、1つのコンテキストキーを配列として追加していました。
{
policyDocument: {
Version: '2012-10-17',
Statement: [{
Action: 'execute-api:Invoke',
Effect: effect,
Resource: `${arn.split('/').slice(0, 2).join('/')}/*`,
}],
},
context: {
roles: ['admin']
}
Docが言うように:
$ context.authorizer.stringKey、$ context.authorizerを呼び出すことにより、マッピングテンプレート内のコンテキストマップのstringKey、numberKey、またはbooleanKey値(たとえば、「value」、「1」、または「true」)にアクセスできます。それぞれnumberKeyまたは$ context.authorizer.booleanKey。戻り値はすべて文字列化されています。 JSONオブジェクトまたは配列をコンテキストマップのキーの有効な値として設定できないことに注意してください。
役割キーを削除すると、機能します。
私の場合、適切にフォーマットされたIAMポリシードキュメントを返していませんでした。私のAuthorizer関数は、要求からいくつかのパラメーターを取得する方法について誤った仮定を行っていました。デフォルトの結果は適切なポリシーではありませんでした(これは私の特定のケースでした)。 CloudWatchログサービスを使用してデバッグすることができました。従来のロギング命令は関数コードから取得されました。