-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a trait SignWith
for signing HTTP requests
#3455
Conversation
This commit addresses #3441 (comment)
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
|
||
// If this is an event stream operation, set up the event stream signer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why remove the comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh removal was by mistake. Will restore it.
fn sign_with( | ||
&mut self, | ||
package: &SigningPackage<'_>, | ||
) -> Result<SigningOutput<SigningInstructions>, BoxError>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs its own error type.
This commit addresses #3455 (comment)
Overall I think that a better API for signing is truly needed and this is directionally good. However, I think we need to work backwards from customer use cases. For example: We should work backwards from a customer who wants to sign an API Gateway request (and write the example!) and handle this that way. If this code is needed urgently for S3 Express, we could consider putting it in I'm not totally sure about the trait API either. On the surface, it seems like it allows for an implementation on foreign types but I don't think it does in practice due to orphan trait rules. At the very least we should compare with other API designs. |
As Russell commented, we need more iterations at a design level, and this PR will most likely be irrelevant when that design is settled. So closing this. For S3 Express, there is a PR created to inline |
…ugin` (#3457) ## Motivation and Context In response to #3455 (comment), it's clear that we need to iterate more on the potential signing API. This PR takes a different approach where `S3ExpressSigner` is dropped and a session token name override, if any, is placed into and retrieved from `ConfigBag`, which is used within `SigV4Signer::sign_http_request`. ## Testing Existing tests in CI A semver failure in CI can be ignored; A public API SigV4Signer::sign_http_request has been removed that only existed in the branch. ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
Motivation and Context
#3388 (comment)
Description
This PR attempts to provide more ergonomic API for request signing. As documented in
aws_sigv4
, customers need to follow these steps after creating anIdentity
and aSigningParams
:This PR allows them to call
SignWith::sign_with
trait method withSigningPackage
instead:Testing
Relied on existing tests in CI
Checklist
CHANGELOG.next.toml
if I made changes to the AWS SDK, generated SDK code, or SDK runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.