abutaha/aws-es-proxy

Invalid signature with ill formatted URL

Closed this issue · 3 comments

I am facing some issues when using aws-es-proxy with a client that generates ill formatted URLs. The signature is generated based on the original signature but then go http client sanitize the URL before sending the request to AWS Elasticsearch.

More specifically I am using aws-es-proxy to authenticate calls from Jaeger to Elasticsearch. The dependency job (https://github.com/jaegertracing/spark-dependencies) makes requests to Elasticsearch with a double / in the path.

E.g. This request from the job would fail:

curl -v localhost:9200/master:jaeger-span-2018-10-30//_mapping
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9200 (#0)
> GET /master:jaeger-span-2018-10-30//_mapping HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 02 Nov 2018 20:44:32 GMT
< Content-Length: 0
< 
* Connection #0 to host localhost left intact

But after correcting the URL it works just fine:

curl -v localhost:9200/master:jaeger-span-2018-10-30/_mapping
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9200 (#0)
> GET /master:jaeger-span-2018-10-30/_mapping HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Content-Length: 49
< Content-Type: application/json; charset=UTF-8
< Date: Fri, 02 Nov 2018 20:42:58 GMT
< 
* Connection #0 to host localhost left intact

I believe I am also running into #27 that swallows the original error and return a 200 instead.

One of the easy fix would be to clean the path before signing the same way the HTTP client will. E.g.

ep := *r.URL
ep.Host = p.host
ep.Scheme = p.scheme
ep.Path = path.Clean(ep.Path)

I tested that locally and it seems to do the job. Let me know if you would like me to submit a PR.

Hi,

Thanks for the tip. I saw a PR that is doing the clean as well. Will merge it soon and release a new version.

I just went through the issues and did not check the PRs before opening that issue.

I think #28 is only addressing one of the cases where the signature could be incorrect (i.e. when there is a double / in the path). However go http client does a lot more to sanitize the URL (e.g. remove ./ or resolve ../ in the path). Using path.Clean would be a much more generic way to tackle this issue than using a regex. I opened #39 for that.

This is fixed now by merging #39.