mirror of
https://github.com/gosticks/DefinitelyTyped.git
synced 2025-10-16 12:05:41 +00:00
53c3baddff
* [aws-lambda] Deprecate CustomAuthorizer*, new APIGateway*Authorizer* Noticed this testing #42419. When integrating a custom authorizer, you actually have two options, creating a token or a request authorizer, which changes what payload you will get. You nearly certainly know which you will be called with! Just deprecating the old version as it's kinda broken in a way thats hard to fix without breaking someone, but we want to guide devs to the new version. It is possible to fix the existing type by adding a bunch of `foo?: never` fields to each alternative so existing accesses don't, error but this makes things more complex, and confusing for the common case. Other ideas welcome! * [aws-lambda] Add api-gateway authorizer parameters. Fixes #34069, #42418 Ended up a bit messy, might be a bit much. * [aws-lambda] Bump minimum typescript to 3.0 Required to fix failing $ExpectError in tests. Surely nobody is still using pre-3.0? * [aws-lambda] Enforcea API Gateway authorizer context narrowing And implement the changes that API gateway does on the proxy request context for it. Also rename TAuthorizer to TAuthorizerContext to be more clear that they should be the same type across both authorizer and proxy. Some cleanups and fixes for names. |
||
|---|---|---|
| .. | ||
| alb.d.ts | ||
| api-gateway-authorizer.d.ts | ||
| api-gateway-proxy.d.ts | ||
| cloudformation-custom-resource.d.ts | ||
| cloudfront-request.d.ts | ||
| cloudfront-response.d.ts | ||
| cloudwatch-events.d.ts | ||
| cloudwatch-logs.d.ts | ||
| codepipeline-cloudwatch-action.d.ts | ||
| codepipeline-cloudwatch-pipeline.d.ts | ||
| codepipeline-cloudwatch-stage.d.ts | ||
| codepipeline-cloudwatch.d.ts | ||
| codepipeline.d.ts | ||
| cognito-user-pool-trigger.d.ts | ||
| dynamodb-stream.d.ts | ||
| kinesis-firehose-transformation.d.ts | ||
| kinesis-stream.d.ts | ||
| lex.d.ts | ||
| s3-batch.d.ts | ||
| s3.d.ts | ||
| sns.d.ts | ||
| sqs.d.ts | ||