Proxy endpoint with path enhancement #146
Proxy endpoint with path enhancement #146jaiswal-sumit wants to merge 5 commits intoaws-samples:mainfrom
Conversation
…hake, hence this change ensure that SNI is set for next_layer() which is client hello call. Test and working fine.
|
@HarshGandhi-AWS & @RogerZhongAWS please check this enhancement. this is working in our integration test and need for our customer to use in this way. As mentioned in detail description it does not break any functionality and in normal condition it works well. @abeytr Kindly put your notes on integration test result. |
| /** | ||
| * The reverse proxy tunnel endpoint path. | ||
| */ | ||
| std::string url_path { }; |
There was a problem hiding this comment.
can you add details about this in readme?
| ("access-token,t", value<string>()->required(), "Client access token") | ||
| ("client-token,i", value<string>(), "Optional Client Token") | ||
| ("proxy-endpoint,e", value<string>(), "Endpoint of proxy server with port (if not default 443). Example: data.tunneling.iot.us-east-1.amazonaws.com:443") | ||
| ("endpoint-path,p", value<string>()->default_value("/tunnel"), "Endpoint path of proxy server if need extra path. Example: reverse-proxy.domain.com/aws-data-service/tunnel, so you connect with -e reverse-proxy.domain.com -p /aws-data-service/tunnel") |
There was a problem hiding this comment.
please set the endpoint default value in an global variable in header file and set it as default over there. It would be easier to maintain it that way. Also add about this default endpoint value in readme.
There was a problem hiding this comment.
for Harsh's point, add to: https://github.com/aws-samples/aws-iot-securetunneling-localproxy/blob/main/src/LocalproxyConfig.h
|
@jaiswal-sumit Can you address the open comments so that we can move ahead with the request. |
|
@jaiswal-sumit Are we still intended on merging this PR, in the case of which, kindly address the open comments? |
4 participants
Motivation
In the case of proxy-endpoint at our side which we maintain and route the data tunnel request via our proxy-endpoint.
We introduced two type of routing on our proxy-endpoint service
Example:
subdomain based routing: tenant-datatunnel.ourdomain.com request will be routed to data.tunneling.iot.eu-west-1.amazonaws.com
subpath based routing: ourdomain.com/tenant-datatunnel request will be routed to data.tunneling.iot.eu-west-1.amazonaws.com
we found subpath based routing does works with localproxy as it tries to bind HOST with complete url to 443
[info] Attempting to establish web socket connection with endpoint wss://ourdomain.com/tenant-datatunnel:443
Hence this PR is to enhance localproxy code so it can work with subpath based request and for this added new arg variable (-p [ --endpoint-path ] arg (=/tunnel) )
./localproxy -d 22 -v 6 -e ourdomain.com -p "/tenant-datatunnel/tunnel"With this it able to bind HOST correctly like this wss://ourdomain.com:443 and make call to GET /tenant-datatunnel/tunnel?local-proxy-mode=source HTTP/1.1 to the HOST
This change will work for all types of connection and does not contain any breaking change. -p is Made option with default value of "/tunnel".
Modifications
Change summary
3 files are modified.
main.cpp to handle -p argument value
LocalProxyConfig.h to carry path value
TcpAdapterProxy.cpp to use path variable for making GET call to service
Testing
**Is your change tested?
Yes, tested with following commands arguments for both source and destination
Please list your testing steps and test results.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.