(aws-sigv4) query param signing should also support signing that isn't a pre-signed url

[bretambrose]

Describe the feature

Currently, the low-level signing implementation in aws-sigv4 requires an expiration duration in the signing settings (as pre-signed URLs require this parameter). It makes sense that pre-signed URLs should require this parameter, but not all query parameter signing represents a pre-signed URL. The end result is that these uncommon query-param-signing use cases have to include X-Amz-Expires in their request despite it being completely irrelevant. This isn't a blocker for my particular use case, but it was a little annoying/worrisome until I got the request to pass signing checks.

Use Case

AWS IoT Core allows the user to connect to their MQTT broker over websockets. In order to do this, you must sign the websocket upgrade request with Sigv4. This is not a pre-signed URL with an expiration date; it is just an HTTP request that happens to need query param based signing.

I didn't have any interest in implementing Sigv4 for the second time in my life, so I used the rust SDK's implementation (which unexpectedly did everything I needed, including session token omission, nice work!)

Proposed Solution

Don't know the SDK or its patterns/philosophy well enough to suggest anything with any conviction. Perhaps a third option for signature location (query_params_with_??) that didn't apply the expect() on the expiration field (and didn't add X-Amz-Expires) would be reasonable.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

A note for the community

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue, please leave a comment

[rcoh]

interesting! We can make this field optional in the low-level API. I wasn't aware of this use case. For higher level APIs exposed to customers, I agree we would want to keep this field required but we should update the core library (in a backwards compatible way) to support this use case.

Happy to mentor on a PR if you're interested.