This topic explains how to configure message proxies that send and receive messages over an HTTP Proxy that routes traffic based on the “Host” header. HTTP Forward proxies are best used with Mobile applications where the backend service endpoint is not configurable or in applications under test when there is no configuration option available to change the host and port used to connect to a backend service.
In this section:
Connection Settings
To specify HTTP Forward proxy connection options, set the following service and listening details.
Proxy Settings (incoming)
These settings specify where messages from the client should connect in order to communicate with the application under test.
Forward proxy | You can choose a Forward Proxy HTTP Listener that you defined when creating the proxy (see Creating Proxies) from the menu or add a new Forward Proxy HTTP Listener. To add Forward Proxy HTTP Listeners from this dialog:
|
---|---|
Host | Enter the host name of the service whose traffic you want to monitor. This determines which hosts are recorded, sent to the live service, or sent to a virtual asset. To allow monitoring for all traffic, choose [All] from the menu. |
Path | Enter a path that you want to monitor on the resource. This works in conjunction with what has been entered in the Host field to match incoming requests. Wild cards are not allowed. To match all paths on the host, leave this field blank or choose [All] from the menu. In the event that there are multiple proxy connections configured that could match to an incoming request, the one with the combination of best host match and longest matching path is selected, with the host match being the more heavily weighted factor. For example, suppose there was an incoming target URL of
In such a situation, proxy #4 would be selected because, even though #2 has the more exact Path match, #4 has the better Host match and, unlike #3, at least a partial Path match. |
Primary Connection (outgoing) & Secondary Connection (outgoing)
Service URL | Contains the full URL for the target application (comprising the service host, service port, and forward path). You can enter a complete URL here and/or edit specific components in the associated fields. Updates made in one area will be propagated to the other (for example, if you modify the port in the Service URL field, the value in the Service port field will be updated automatically). |
---|---|
Service host | Enter the host name of the machine where the service resides. This is the machine to which the proxy will send messages. If you want the proxy to forward to a virtual asset on the local server without consuming an HTTP connection, enter host.virt.internal, localhost, or 127.0.0.1 rather than the actual hostname. When using localhost or 127.0.0.1, the service port must match the port Virtualize is deployed on; when using host.virt.internal the service port is not used. For example, a virtual asset deployed on The Service host may also be set to [Passthrough], which will route the request to the original host requested by the client, or [Virtualize], which will instead route the request to Virtualize to be handled by a Virtual Asset or Message Proxy. Select either option from the menu. |
Service port | Enter the port where the service is listening. This is the port to which the proxy will send messages. |
Service forward path | (Optional) Enter the path to which the proxy should forward the messages that it receives. If blank, the proxy will forward messages along the original incoming path without modification. If the proxy is sending messages to localhost, you must enter a Service forward path as the proxy doesn't allow forwarding to itself. If the Service forward path sends a redirect, the proxy will follow the redirect and then respond back. It will not pass the redirect back to the client. |
Options
Mode: Allows you to set the active forwarding connection when a primary and secondary connection exist. For example, during a recording session, a message proxy may forward to the live service as the primary connection and fall back to a virtual service as a secondary connection. In this case, you can set the HTTP mode to Primary and enable Use other connection if selected mode fails.
Once recording is complete and new virtual assets are generated, you may want to re-configure the proxy to forward to the virtual service first and fall back to the live service if a failure occurs. This change can be quickly applied by right-clicking the proxy and switching the HTTP mode to "secondary". The failover will be adjusted accordingly at runtime.
Use other connection if selected mode fails: Enable this option if you want traffic to be redirected to the backup proxy endpoint when the active connection (as determined by the Mode selected above) fails. The connection will be considered "failed" if the response status code is 400 level or higher.
Bypassing proxy failover
Message Responders can be configured to bypass this proxy failover for internally routed messages by enabling Skip message proxy failover.
If this option is not enabled, the active connection will be used for recording.
If this option is enabled, select a recording option from the Record menu:
- Both connections: Records traffic for both the primary and secondary connections. Error messages from the active connection will not be recorded; instead, the messages will be sent to the backup connection and the responses will be recorded. Errors reported by the backup will be recorded.
- Primary connection only: Records traffic for the active connection. Does not record errors.
- Secondary connection only: Records traffic for the backup connection, including errors.
Learn responses: Enable this option if you want your internal endpoint to learn to emulate the responses recorded from a live endpoint. The internal endpoint must have a files responder (see Request/Response Files for more information). This option is only available when Use other connection if selected mode fails is enabled (see above). You can easily enable/disable learning by the proxy by right-clicking the proxy and switching the mode to Enable All or Disable All.
Example: Sending Traffic to a Service
Assume that we want to create a message for a service that is normally accessed at http://parabank.parasoft.com
. We could create an HTTP Forward proxy with the settings:
- Host: parabank.parasoft.com
- Service host: [Passthrough]
This configuration will watch for traffic sent to host parabank.parasoft.com
and pass traffic to the live service as usual.
If we wanted to redirect traffic to a different service host and port, we could change the configuration of the proxy as follows:
- Service host: coyote.parasoft.com
- Service port: 8080
- Service forward path: [empty]
This will route traffic intended for parabank.parasoft.com to a different service on coyote.parasoft.com:8080
.
Example: Sending Traffic to a Virtual Asset
A proxy can also send traffic to a virtual asset. By using a local virtual host like host.virt.internal
or the built-in "[Virtualize]" option as the Service host, we can forward to a virtual asset on the local server without consuming an HTTP connection (see Primary Connection (outgoing) & Secondary Connection (outgoing) above for more information).
One way to do this is to change the primary outgoing connection to host.virt.internal
to send traffic to a virtual asset on a local server:
- Service host: host.virt.internal
- Service port: 9080
- Service forward path: /path
Alternatively, since the secondary connection is configured to point to a local virtual asset by default, another option would be to simply change the Mode from Primary to Secondary.
- Service host: [Virtualize]
- Service forward path: /path
- Mode: Secondary
Installing the Parasoft Root Certificate Authority
Before you can use an HTTP forward proxy on a mobile emulator, the Parasoft Root Certificate Authority must be installed as a trusted certificate. If the certificate authority is not installed, the browser will not consider the connection secure and may refuse to allow the connection.
Android Emulator
This procedure assumes that you are using Android Studio/Android Sdk and that you have created an Android Virtual Device (AVD) on a non-production build. Additionally:
- The AVD's proxy settings have been configured for Parasoft. See https://developer.android.com/studio/run/emulator-networking#proxy for more information about using the emulator with a proxy.
- The Android Sdk emulator and adb executables have been added to the $PATH variable.
Because CA certificates in Android are stored by their hashed name with the file extension .0, you will need to copy and rename the Parasoft certificate. To do that, open a command prompt and navigate to <VIRT-INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/lib
then run the following command:
hashed_name=`openssl x509 -inform PEM -subject_hash_old -in parasoft.cer | head -1` && cp parasoft.cer $hashed_name.0
You need to place the hash.0 version of the CA certificate in the system certificate store in the Android filesystem, found at /system/etc/security/cacerts/
. The /system
partition is mounted as read-only by default, however, so you will first need to change permissions to it. Exactly how you do that depends on what version of the emulator you are using.
API Level 29 or higher
Starting with API Level 29, you can't mount the "/" partition with read-write permissions normally. Google has provided a workaround (see https://android.googlesource.com/platform/system/core/+/master/fs_mgr/README.overlayfs.md for more information), but some users find that this results in their emulator getting stuck in a boot loop. If that's the case, you can try the workaround detailed below:
You have to start the emulator using the -writable-system
option in order to use the certificate, otherwise Android will load a “clean” system image.
Start your AVD:
emulator -avd <AVD_NAME> -writable-system
- If you're not sure of the name of your AVD, run
emulator -list-avds
to pull up a list of all your AVDs.
- If you're not sure of the name of your AVD, run
Restart adb as root:
adb root
Disable secure boot verification:
adb shell avbctl disable-verification
Reboot the device and restart adb as root:
adb reboot adb root
Remount the partitions as read-write:
adb remount
If adb indicates that you need to reboot, run
adb reboot
andadb remount
again.
Push the hash.0 version of the certificate:
adb push <PATH_TO_CERT> /system/etc/security/cacerts
Set certificate permissions:
adb shell chmod 664 /system/etc/security/cacerts/<NAME_OF_HASH.0_CERT>
Reboot the device again:
adb reboot
API Level 28 or less
You have to start the emulator using the -writable-system
option in order to use the certificate, otherwise Android will load a “clean” system image.
Start your AVD:
emulator -avd <AVD_NAME> -writable-system
- If you're not sure of the name of your AVD, run
emulator -list-avds
to pull up a list of all your AVDs.
- If you're not sure of the name of your AVD, run
Restart adb as root:
adb root
Remount the partitions as read-write:
adb remount
If adb indicates that you need to reboot, run
adb reboot
andadb remount
again.
Push the hash.0 version of the certificate:
adb push <PATH_TO_CERT> /system/etc/security/cacerts
Set certificate permissions:
adb shell chmod 664 /system/etc/security/cacerts/<NAME_OF_HASH.0_CERT>
Reboot the device again:
adb reboot
iOS Emulator
- Host the parasoft.cer file on a file server or email parasoft.cer to an address the iOS emulator can receive. You will find parasoft.cer in
<VIRT_INSTALL_DIR>/plugins/com.parasoft.ptest.libs.web_<version>/root/lib.
- Open a browser to the URL of the parasoft.cer file or open the email and follow the dialog prompts and accept the configuration profile.
- Go to
Settings > General > Device Management
and choose Parasoft Root Certificate Authority. Click through the installation dialogs leaving the default settings in place.
On recent iOS versions, you also need to enable full trust for the Parasoft Root Certificate. To do so:
- Go to
Settings > General > About > Certificate Trust Settings
. - Under Enable full trust for root certificates, turn on trust for the Parasoft Certificate.