...
| Note | ||
|---|---|---|
| ||
HTTP traffic files recorded inVirtualize or SOAtest9in Virtualize 9.10.x cannot be used with Parasoft Virtualize 9.9.x verions and earlier. |
In this section:
| Table of Contents | ||
|---|---|---|
|
You will need Before you set basic HTTP connection options, you need to know the host, port, and path of the service you are testing or creating a virtual service forto set up basic HTTP connection options. Use for which you want to create a proxy. These are the settings you would normally use to directly message the service.
...
These settings specify where messages from the client should connect to Virtualize in order to communicate with the application under test.
...
| Listener | You can choose an HTTP listener that you defined when creating the proxy (see Creating Proxies) from the drop-down menu or use the default listener. You can add HTTP listeners in these section:
|
|---|---|
| Proxy listen path | Enter the path where the proxy should listen for incoming connections. No two message proxies can have HTTP connections with the same proxy path or with a path that matches an existing virtual asset’s HTTP path. See Service Forward Path and Proxy Listen Path for more details. |
| Proxy URL | Displays the URL that should be given to the AUT.See ; see Directing AUTs to Proxies for additional informationmore details. |
SSL Settings for Listener Ports
Enable the Use keystore option to configure server side SSL settings.
Configure the following settings:
...
Enable the Perform client authentication option to configure client side SSL settings.
Configure the following settings:
...
| 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 following fields. Updates made in one area will be propagated to the other (e.g., if you modify the port in the URL, 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 foward to a virtual asset on the local Virtualize server without consuming an HTTP connection, enter |
| 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, this defaults to the value in the Proxy listen path field. If the HTTP proxy is sending to messages localhost, you must enter a Service forward path because 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. See Service Forward Path and Proxy Listen Path for more details. |
...
Enable the Use secondary connection if primary fails option if you want traffic to be redirected to a secondary proxy endpoint when the primary connection fails or the responder is not available. The connection will be considered "failed" if the response status code is 400 level or higher.
For instance, you may might want to specify a secondary endpoint if you want a virtual asset to be used whenever the live endpoint is unavailable. If Or, if a virtual asset does not handle a given use case, you may also could use a secondary endpoint to redirect have that traffic redirected to the live endpoint and record the . You could then optionally record that live traffic for creating a new virtual asset to cover that use case.
...
The Service SSL section needs to be completed only if the service you are working with virtualizing uses SSL.
If theservice the service being virtualized and/or the application under testuses test use SSL and/or other authentication (basic/digest, Kerberos, NTLM), additional configuration may be required.
...
Proxy Server Tab Settings
You can This tab lets you specify a proxy server for at the message proxy in this tab, which enables you to configure a different proxy server for traffic to and from different message proxies. This configuration provides control over Virtualize message proxy level—so you can control which proxy server handles traffic between the application under test and a specific Virtualize message proxy. This allows you to configure different proxy servers for traffic to and from different Virtualize message proxies.
To specify proxy settings at this level, provide the appropriate details in the proxy’s Proxy Server tab.
SSL is not supported.
...
Using Wildcard Characters in Paths
You can use wildcard characters Wildcard characters can be used to specify dynamic path segments. For example, configuring the path as assume two requests were sent to Virtualize on the paths /path/1/service and /path/*2/service would enable the following paths to . To have both requests go to the same proxy:
/path/1/service
/path/2/service, configure the path as /path/*/service.
Wildcards can be used to replace an entire path segment. For example:
/path/*/service— valid/path/1*2/service— not valid
The wildcard can only be used for one segment of the path. A path configured ast Note that /path/*/service will NOT match /path/1/2/service. If you want your path to match both /path/1/2/service and /path/3/4/service, use the pattern /path/*/*/service.
...
In most cases, the proxy will pass all headers directly to and from the target service. Some content-length related headers may be changed to suit how the proxy server works. For example, the proxy server doesn't support responding with the "chunked" transfer encoding and will replace "host" headers sent to match its own host name (however, it does support receiving chunked requests and chunked responses from the target service).
...
Pointing to Virtual Assets or Actual Services
A proxy can use a virtual or test asset on a server Virtualize Server as its target service. To do this:
- Set the service host and port to that of the Virtualize Server where the virtual asset is deployed. If you want the proxy to foward to a virtual asset on the local Virtualize server without consuming an HTTP connection, enter enter
localhostor or127.0.0.1rather rather than the actual host name. - Set the proxy connection’s connection’s Service forward path to to the virtual asset’s path (found in the virtual asset’s asset’s Transports> HTTP tab tab, under under HTTP endpoint).
Chunking/Unchunking Behavior
...
- Create a plain text file and specify the properties you want to set (see HTTP Listener Message Proxy Performance Properties and HTTP Listener Message Proxy SSL Properties).
- Save the file to theVirtualAssets or TestAssets directory the VirtualAssets directory in your workspace and name it
embeddedServer.properties.
The file will be read every time a proxy with HTTP listeners is enabled.
...
In both cases, all traffic that goes to those paths (including sub paths) is sent to the service. In the second example, traffic sent to /SomeOtherPath/SubPath would be sent to /BookStore/SubPath. Because Since queries are preserved, /SomeOtherPath?param=value would be sent to /BookStore?param=value.
Forwarding Requests to Services that Require Case-sensitive Header Names
If you are using the Virtualize desktop's server, your message proxy headers will be lowercased and may fail to function properly when requests are forwarded to a service that requires case-sensitive HTTP header names.
...
| Code Block |
|---|
X-AUTHORIZATION ANOTHER-HEADER HEADER3 |
Example: Sending Traffic to a Virtual Asset
A proxy can also send traffic to a virtual asset. In that case, enter the host and port information for the Virtualize Server as if were just another service.
...
To send traffic to a virtual asset on a local server, you might use:
- Service host: localhost localhost
- Service port: 9080 9080
- Service forward path: /pva
The HTTP proxy makes no distinction between a virtual asset and an actual service. Both are configured the same way. However if the HTTP proxy is sending to localhost, you must specify specify Service forward path because because the proxy doesn't allow forwarding to itself.
| Info | ||
|---|---|---|
| ||
If you are using the Virtualize desktop's server, your message proxy headers will be lowercased and may fail to function properly when requests are forwarded to a service that requires case-sensitive HTTP header names. See Forwarding Requests to Services that Require Case-sensitive Header Names for details. |
...
- If the service to which you are forwarding the traffic uses SSL and/or access authentication, you need to perform proxyProxy-level configurationLevel Configuration (from the proxy’s UI controls).
- If the AUT uses SSL and/or access authentication, you need to perform serverServer-level Level Configuration (for the Tomcat-based serverVirtualize Server).
Depending Thus, depending on your configuration, you configure either security setting might perform server-level configuration, proxy-level configuration, or both.
| Anchor | ||
|---|---|---|
|
...
|
Proxy-level security configuration—which is relevant if the service to which you are forwarding the traffic uses SSL and/or access authentication—covers:
...
Additionally, you need to provide the information needed to use a specific key store and certificate so Parasoft Virtualize can determine which certificate to present to a server (e.g., for 2-way SSL).
SSL Configuration Panel Fields
| Scroll Table Layout | ||
|---|---|---|
|
| Option | Description |
|---|---|
| Use SSL when connecting to the service | Enables the SSL. |
| Trust all server certificates | If enabled, any certificate will be accepted. No validation will be performed. This option disables trust validation when the message proxy establishes the connection with the service; it makes it accept the connection with any certificate that is presented by the service. In general, this option should be enabled if certificate trust is not a focus for the environment where Virtualize is deployed. |
| Accept self-signed certificates | If enabled, certificates will be accepted as long as the validation method java.security.cert.X509Certificate.checkValidity() returns true on them, which effectively checks if the current date and time are within the validity period given in the certificate. The certificate trust path will not be evaluated and the provided Trust-store configuration will not be applied. This option determines if certificateswhether Virtualize should trust certificates that are presented by the service and that are not signed by a trusted certificate authority are trusted. In general, this option should be enabled if certificate trust is not a focus for the environment whereSOAtest or Virtualizeiswhere Virtualize is deployed. |
Note that the Truststore configuration (described below) is applicable only if Trust all server certificates and Accept self-signed certificates are both unselected.
...
After completing the keystore detail, click click the Load and choose button. Then, from the Certificate drop-down, select the certificate alias for Virtualize to present to the serverfrom the Certificate drop-down. If the Certificate dropdown is not populated when you click Load, you may have entered the incorrect password or keystore type.
Truststore Configuration Panel Fields
...
If your service requires Kerberos authentication, set the Kerberos Service Principal in the Kerberos Authentication section.
| Anchor | ||
|---|---|---|
|
...
|
Server-level security configuration—which is relevant if the AUT uses SSL and/or access authentication—can involve:
- Configuring the Virtualize Server
- Using NTLM with WAFFLE
- Using Unsupported Configurations (Kerberos with WAFFLE, JAAS)
| Anchor | ||||
|---|---|---|---|---|
|
...
|
You can The Virtualize Server uses port 9080 by default. If you want to change the default proxy port number (9080), enable SSL, and configure other server settings. See Server Configuration for details(e.g., to improve security by moving the server off common/well-known ports), see Using an Alternative Port for the Virtualize HTTP Server.
If the AUT uses SSL, you need to configure the Virtualize Server as described in Configuring SSL (HTTPS) for the Virtualize Server.
| Anchor | ||||
|---|---|---|---|---|
|
...
- Copy the following jar files into tomcat's
libdirectory:jna.jar, platform.jar, wafflejna.jar. Add the following to
tomcat/conf/server.xml.Code Block <Context> <Valve className="waffle.apache.NegotiateAuthenticator" principalFormat="fqn" roleFormat="both"/> <Realm className="waffle.apache.WindowsRealm" /> </Context>
Info title Where is server.xml? If you installed SOAtest but not Virtualize: Launch SOAtest, ensure that at least one responder has been created, then modify the server.xml file at [SOAtest install dir]/eclipse/plugins/com.parasoft.xtest.libs.web_[version]/root/tomcat/conf/server.xml
- If you installed Virtualize but not SOAtest: Launch Virtualize, ensure that at least one responder has been created, then modify the server.xml file at [Virtualize install dir]/eclipse/plugins/com.parasoft.xtest.libs.web_[versionVirtualize_ver]/root/tomcat/conf/server.xml
- If you installed Virtualize and SOAtest together: Launch Virtualize, ensure that at least one responder has been created, then modify the server.xml file at [SOAtest install dir]/eclipse/plugins/com.parasoft.xtest.libs.web_[SOAtest_ver]/root/tomcat/conf/server.xml
Add the following to
tomcat/conf/web.xml.Code Block <security-role> <role-name>Everyone</role-name> </security-role> <security-constraint> <display-name>Waffle Security Constraint</display-name> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>Everyone</role-name> </auth-constraint> </security-constraint>- Restart the server.
...