This is the third of four scenarios, covered by the post series:
"HTTPS tracing and debugging: A simple way "
In this third example, we will consider a very common scenario that can sometimes present tracing difficulties. I will introduce a new application "mitmweb" and we will see how to operate our proxy in reverse mode.
For this third example, we will assume that the connection between the cloud and our onprem system will be through the Cloud Connector (you can always use SSH tunnels ;-)) The Cloud Connector has the option of using a proxy to connect to SCP, but currently (and I hope not to be wrong), it doesn't have a way to use a proxy for local connections as we did in the two previous examples.
To overcome this difficulty, we will configure the proxy to operate in reverse mode. A reverse proxy performs the call on behalf of the client, we could say that it "supplants" the identity of the sender. In this case, the request must be directed directly to the proxy, as if this were the target system. The proxy will then generate a second connection while keeping the client waiting. When the proxy receives the response, it finally delivers it to the client it was on hold until now.
1.- Launch our local echo service
Note that the echo server will be receiving request on port 8085
2.- Run "mitmweb" in reverse mode
In this case, in the command line we will indicate that it must operate as a reverse proxy (-m reverse) redirecting the connections to our localhost port 8085 (where our echo service is - step 1).
3.- Configure the cloud connector
Note two things: a) the cloud connector is pointing to the port of the proxy, not to the port of the echo service and b) we have enabled the cloud connector for the root path, including all sub-paths.
4.- Create a Simple Iflow in CPI
The Iflow simply has to send some kind of information to the echo service. In this example, the content is added by a "Content Modifier" and the iflow executed by a timer.
Notice that the communication channel sends data through my own cloud connector (which we configured in the previous step).
5.- Run the scenario
6.- Confirm the proxy execution
The biggest difference between mitmproxy and mitmweb, is that the UI is based on a web page and although this still works in beta/aplha mode, it is a much more flexible and easy way to access the information. By default, mitmweb builds a web service on port 8181 that can be consumed directly from our browser.
The flows will appear in a list, then, by clicking on one of the interceptions we can see its details. In the example we can see that everything was processed correctly.
We can also check the option that we include in the command line: Options->Edit Options->Mode.
As in the previous cases, stop and think about what happened:
Perfect! We already know about reverse proxies and mitmweb, let's see now the most challenging case of this series of blogs:
Ariel Bravo Ayala
"HTTPS tracing and debugging: A simple way "
In this third example, we will consider a very common scenario that can sometimes present tracing difficulties. I will introduce a new application "mitmweb" and we will see how to operate our proxy in reverse mode.
Consumption of a local echo service from CPI
For this third example, we will assume that the connection between the cloud and our onprem system will be through the Cloud Connector (you can always use SSH tunnels ;-)) The Cloud Connector has the option of using a proxy to connect to SCP, but currently (and I hope not to be wrong), it doesn't have a way to use a proxy for local connections as we did in the two previous examples.
To overcome this difficulty, we will configure the proxy to operate in reverse mode. A reverse proxy performs the call on behalf of the client, we could say that it "supplants" the identity of the sender. In this case, the request must be directed directly to the proxy, as if this were the target system. The proxy will then generate a second connection while keeping the client waiting. When the proxy receives the response, it finally delivers it to the client it was on hold until now.
1.- Launch our local echo service
Note that the echo server will be receiving request on port 8085
2.- Run "mitmweb" in reverse mode
In this case, in the command line we will indicate that it must operate as a reverse proxy (-m reverse) redirecting the connections to our localhost port 8085 (where our echo service is - step 1).
mitmweb -m reverese:localhost:80853.- Configure the cloud connector
Note two things: a) the cloud connector is pointing to the port of the proxy, not to the port of the echo service and b) we have enabled the cloud connector for the root path, including all sub-paths.
4.- Create a Simple Iflow in CPI
The Iflow simply has to send some kind of information to the echo service. In this example, the content is added by a "Content Modifier" and the iflow executed by a timer.
Notice that the communication channel sends data through my own cloud connector (which we configured in the previous step).
5.- Run the scenario
6.- Confirm the proxy execution
The biggest difference between mitmproxy and mitmweb, is that the UI is based on a web page and although this still works in beta/aplha mode, it is a much more flexible and easy way to access the information. By default, mitmweb builds a web service on port 8181 that can be consumed directly from our browser.
The flows will appear in a list, then, by clicking on one of the interceptions we can see its details. In the example we can see that everything was processed correctly.
We can also check the option that we include in the command line: Options->Edit Options->Mode.
As in the previous cases, stop and think about what happened:
- The client (CPI), sent a request via the cloud connector directly to our proxy - not to the echo service.
- The proxy, keeps CPI waiting, while in a different process, makes a call, with the same data to the URL assigned for the reverse proxy.
- When the proxy receives the response from the server (echo), it returns to the pending connection with CPI and delivers the response.
Perfect! We already know about reverse proxies and mitmweb, let's see now the most challenging case of this series of blogs:
4th scenario: Coud to Cloud
Ariel Bravo Ayala
- SAP Managed Tags:
