Include full path + querystring in APIGatewayProxyRequest
- Dominant language
- Go
- Stars
- 3.8k
- Forks
- 578
- Avg merge
- 8h 18m
- Merged PRs (30d)
- 1
Description
**Is your feature request related to a problem? Please describe.**
A common authentication scheme for webhooks involves generating a signature from the endpoint URI using a shared secret key. Typically the base URL is not included but any query parameters are. For example, a request to GET `https://api.myservice.com/foo?baz=1` would include a signature of the message `/foo?baz=1`.
Currently, API Gateway passes both the URI path and query string parameters as separate values. This is fine for requests with 0 or 1 query parameters, but becomes problematic for requests with multiple query parameters since the ordering information is lost. For example, it is impossible to distinguish a request to `/foo?a=1&b=2&c=3` from `/foo?b=2&c=3&a=1` or any other permutation of the parameters. This is problematic as it is necessary for both client and server to agree on the exact bytes in which to sign.
A related but minor issue is that it is unclear how technically legal requests with multiple colliding query parameters would be processed. I.e. a request URI to `/foo?a=1&b=2&a=3` would be impossible to reconstruct. The Go standard library handles such edge cases by using a `map[string][]string` instead of a `map[string]string` for query values: https://pkg.go.dev/net/url#Values
**Describe the solution you'd like**
A new attribute to the APIGatewayProxyRequest object that includes the full unprocessed URI path and query string. E.g. GET `https://api.myservice.com/foo?a=1&b=2&c=3` => RawPath = "/foo?a=1&b=2&c=3"
**Describe alternatives you've considered**
If an ordering is agreed between client and server with respect to query string values, then there is no problem - however such an ordering is hard to guarantee in general.
Of course, it would be possible for the server to generate signatures for all possible permutations of querystring values, but this quickly becomes problematic with O(n!) complexity...
**Additional context**
I'm aware that this is more of an improvement for API Gateway itself rather than the Go bindings in particular, so please let me know if there is somewhere else I should be raising this issue!
Contributor guide
Assessment
This issue has not been assessed yet.