Closed dinvlad closed 6 years ago
@dinvlad
I wouldn't rely on the AWS.Signers.V4
object in production right now. We have talked about refactoring the signers for public use, but I don't have an idea of when that work would be done. If you are trying to sign requests for APIs the SDK doesn't currently support, then a 3rd-party library would be a better choice for now.
Can I ask what your use case is? I'm just curious about where the need is outside of making requests to service APIs that the SDK supports, and more data could help us prioritize this work.
Thanks - this is mainly for signing requests to 'execute-api' on API Gateway.
While we can indeed generate an SDK for that API using the AWS console or this SDK's getSdk() call, it seems less convenient to do that every time we make a change to the API, especially during development and testing. It would be extremely useful to rely on an existing generic library to make direct calls to IAM-protected methods on the API Gateway instead of generating a custom one. In addition, we could use existing Typescript definitions for making those calls.
Completely agreed requesting this be part of the public API! I'm adapting AWS.SIgners.V4 to add signing to SwaggerJS for use with my API Gateway AWS_IAM APIs and it would be nice to know that this will be stable. https://github.com/prestomation/swagger-ui/blob/master/dist/client_authorization-sigv4.js
FWIW with regards to Swagger, I ended up switching to JWT authentication in part because of this issue. It is much easier to auto-generate a Typescript client (for Angular) from a Swagger spec than to generate SDK from API Gateway and create the bindings manually. As a side benefit, JWT allows for more flexibility both in terms of dynamic permissions and clients (no need for special software, e.g. Curl can now be used); and we can also use third-party authentication solutions, e.g. Auth0 or Stormpath (Cognito is unfortunately severely lacking in graphical clients, IMO).
This would be very helpful for elastic search service queries too.
Since then we've moved to Cognito User Pool Auth with JWT authorizer, since Cognito UP has improved substantially in the past half-year. Still, it has a few annoying issues that make it not completely fluent to use (e.g. linking multiple accounts). I wish everything was open-source and extensible out of the box. IAM/SigV4 is a hard dependency to bring around.
+1 to have a public signer (that can produce both signed query strings as well as signed headers. This will reduce a lot of headache..
Use cases: IoT, Neptune, APIs and other stuff without an SDK...
+1 I haven't found reliable, intuitive third-party signer yet.
I have no idea if these are official examples but this is so much better than the mess I have right now: https://github.com/aws-samples/amazon-elasticsearch-lambda-samples/blob/master/src/s3_lambda_es.js
https://github.com/mhart/aws4 is current a gold standard, couldn't run production without it
@adjourn
AWS Samples is an official AWS organizaion on GitHub. Hopefully it's a useful resource for you.
Refer to SignatureV4 in v3 of the SDK. It's still in preview, but is worth checking out now.
We have an application where it would be convenient to use the private aws.Signers.V4 object to sign AWS requests. Is it safe to rely on this API in production, even if it's not part of the official documentation? Or should we use a 3rd-party library (e.g. mhart/aws4) that relies on the officially publicized description of the algorithm (assuming we don't want to sign it semi-manually with Crypto according to the official docs)?
Thanks