...

Browser Settings

The Browser panel lets you set options related to Web scenario recording. Available settings include:

• Firefox Executable Path: Specifies the path to the Firefox executable. On Windows machines, SOAtest and/or Virtualize will attempt to detect a Firefox installation automatically. Linux users will have to browse to the Firefox executable.

• Chrome Executable Path: Specifies the path to the Chrome executable. Paths set here will be used in web recording wizards and other applicable areas. On Linux, choose google-chrome (e.g. /opt/google/chrome/google-chrome)—not chrome.
• Safari Executable Path: Specifies the path to the Safari executable.

• Anchor
  proxy-port-field proxy-port-field

  Proxy port: Specifies the proxy port. See Proxy Configuration Details below for more information and tips.
• Browser communication port: Specifies the browser communication port.

• Browser Timeout Settings: Specifies the length of delay (in milliseconds) after which SOAtest and/or Virtualize should stop waiting for browser startup or a user action and consider it to be "timed out."

• Wait Condition Default Timeout Settings: Specifies the length of delay (in seconds) after which SOAtest and/or Virtualize should stop waiting for the activity specified in the wait condition to occur and consider it to be "timed out."

• Debug Options> Print debugging information: During recording of a web scenario, it is possible that an action taken is not recorded by SOAtest and/or Virtualize. Enabling this option will allow messages to be printed to the message console during recording, with information about what events SOAtest and/or Virtualize handled, any locators that may have been generated, and if applicable, any exceptions that took place during recording.

• Error Reporting> Report website's scripting errors: Configures SOAtest and/or Virtualize to report scripting errors that occur during scenario execution. In Internet Explorer, the Selenium Web-Driver framework will not report JavaScript errors on the page to SOAtest and/or Virtualize; this reporting is supported only for the legacy engine.

• Allowable Binary Files in Traffic Viewer and Outputs: Allows binary files with the specified extensions or MIME types to be used in the Traffic Viewer and output. By default, only text files will be allowed.

• Browser Contents Viewer Rendering Engine: Enables you to specify what browser is used for the Browsear Contents Viewer tool , which can be attached to the Browser Playback tool.

  • The default option (Same browser used for playback) is generally the recommended option because some web applications generate their pages differently based on the browser used. Using the same browser that was used during the playback can help ensure that pages display properly in the Browser Contents Viewer. Note that if the playback browser was Chrome, the Firefox rendering engine is used.

  • When Internet Explorer is selected, the version of IE that is used depends on what version of IE is installed on the machine running SOAtest and/or Virtualize. The Internet Explorer option is available only on Windows.

  • When Firefox is selected, the version of Firefox that is used depends on what Eclipse is being used to run SOAtest and/or Virtualize. It can range from Firefox 3.0.1 to Firefox 10, depending on what OS is being used.

  • If the particular web application being tested does not render properly in the Browser Contents Viewer, you could try configuring this option to use either Internet Explorer or Firefox specifically (rather than use the default Same browser used for playback option) to see if using a specific rendering engine will improve how the page is shown in the Browser Contents Viewer.

• HTML Content Fetch Mode: Enables you to determine whether the contents of hidden frames are displayed in the pre- and post-action HTML viewer. This can impact record and playback speed, as well as file size. It is possible to use one mode on some of your team’s SOAtest and/or Virtualize machines (e.g., desktop installation), and a different mode on others (e.g, the Server machine running in command-line mode).

  • Fetch all HTML content Choose this option if you want to see the contents of hidden frames in the pre- and post-action HTML viewer 

  • Fetch content for all content except hidden frames: Choose this option if you do not need to see the contents of hidden frames in the pre- and post-action HTML viewer.

Anchor
Proxy Configuration Details Proxy Configuration Details

Proxy Configuration Details

When you record or run web scenarios in a browser, the proxy settings in the browser are set to an internal proxy maintained by SOAtest and/or Virtualize. All communication to and from the browser during recording and playback goes through the internal proxy, which is an intermediary used to capture traffic and otherwise facilitate execution. During recording and playback, SOAtest and/or Virtualize temporarily creates this proxy on localhost using the port specified by the Browser Playback setting’s Proxy port option.

...

Global Data Source Settings

Global data sources Data Sources can be reused and shared across and shared outside of a single SOAtest project and across Virtualize deployments.  The The Global Data Source panel lets you determine how information about global data sources is saved. For information on how to configure global data sources, see Adding a Data Source at the Responder Suite, Project, or Global Level.

Technical Support Settings

Use the Technical Support interface If you are experiencing problems with Virtualize, the best way to remedy the problem is to create a zip archive containing the related files if you are experiencing issues. Send the , then send that zip file to Parasoft's support team so that they can assist you.Virtualize can automatically . To facilitate this process, you can have the product automatically create an archive when problems occur. Archives are approximately On average, these archives are about half a megabyte, and are created in about 60 secondsone minute.

By default, an archive is not created when problems occur. You can either manually prepare and send a support archive when needed, or you can modify Parasoft  archive creation options so that the product automatically prepares and sends an archive when problems occur.

...

When creating a support archive it is best to ensure that it contains all the info which is relevant to the  problem and does not contain any unrelated info. To ensure that detailed logs are sent to the standard output console, add the following argument to to virtualizecli:

-J-Dcom.parasoft.xtest.logging.config.jar.file=/com/parasoft/xtest/logging/log4j/config/eclipse.on.xml

...

• Character Encoding: You can enable System default to configure SOAtest and/or Virtualize to use the default character set for the particular system being used. Enable Custom to encode characters from the list of encodings available on the JVM being used.

• Save settings: Specifies what file format to use for saving project files (e.g., .pva, .pvn,  .changetemplate). See Understanding the Available Project File Formats.

• Default timeout (milliseconds): Allows you to enter the length of delay (in milliseconds) after which SOAtest should consider your FTP, telnet, or HTTP requests to be “timed out.” The default is 30000 milliseconds.
• Report each duplicate error that occurs on the same line: Tells SOAtest to show only the first instance of duplicate errors that occur for the same line of code.
• Reset Cookies: Allows you to clear the current global cookies so that next HTTP invocations start a new session.
• Enable the Automatically backup project files option and specify a file size threshold for .tst and/or .pva files in the Warn on file size large than (MB) field to be notified when the size of the file exceeds the threshold. You can then reduce the size (and prevent performance problems) by dividing it into smaller files.

Anchor
Proxy Settings Proxy Settings

Proxy Settings

The Proxy panel controls how SOAtest and/or Virtualize works with proxy servers. It does not control the separate intermediary proxy used for web scenarios (for details on this other proxy, seeProxy Configuration Details). 

...

• • Java: For Java, you can specify the Java home directory and the path to the javac compiler. You need to specify these parameters if you want to compile Java methods in the editor.   

    Note
    title Note
    The javac compiler is not included.

    • Java home: Specifies the Java installation directory.
    • Javac classpath: Specifies the Java classpath.
  • JavaScript: If you create scripts using Jython or JavaScript, you can specify a script template in the Script Template field.
    • Script Template: Whatever code is specified in this field will be used as the default code for inlined scripting in the language with which the field is associated. This is prmarily useful for setting default inputs and common global variables. Script templates apply to scripts used in Extension tools; they do not apply to JavaScript that runs in a browser context.

  • Jython: For Jython, you can specify the jython.home and jython.path variables. Both variables are used to locate Jython modules. Jython code that does not import any Jython modules can use the Jython scripting support without setting either variable. If you set the jython.home and jython.path variables, you need to restart SOAtest or Virtualize before the changes will take effect.

  • Jython Home: Specifies the Jython installation directory. This must be a single directory. Use a forward slash (/) or backslash (\) to escape special characters.
  • Jython Path: Used to add to your path modules that are not in your jython.home/Lib directory. Multiple paths can be listed. Use a forward slash (/) or backslash (\) to escape special characters.
  • Script Template:Jy thon code that does not import any Jython modules can use the Jython scripting support without setting either the jython.home or jython.path.

• Timeout Settings: Specify how many minutes SOAtest or Virtualize should wait before attempting to stop an unresponsive script and log an error message.

Security Settings

Anchor
Security Settings Security Settings

You can configure default security settings for Responders used in your projects. In most cases, the security settings can be overridden by configurations set locally in your suitesThe Security panel allows you to set the following security settings:

• Global HTTP Authentication Properties

...

• : Allows you to specify global HTTP authentication properties that can be used when configuring HTTP protocols within an applicable tool.

...

• Select the Perform Authentication

...

• check box and enter the Username and Password to authenticate the request

...

• , and select either Basic, NTLM

...

• , or Digest

...

• , from the Authentication Type drop-down list. For Kerberos, enter the Service Principal to authenticate the request. If the correct username and password, or the correct service principal, are not used, the request will not be authenticated.
• Kerberos realm: Specify the Kerberos realm associated with your network. By convention, this is typically your domain name in all caps (e.g. PARASOFT.COM).
• KDC server: Specify the hostname of your Key Distribution Center (e.g. kdc.parasoft.com).

• Check Ticket: This will execute a simple test to locate a cached Kerberos TGT (Ticket Granting Ticket) to grant access to the service. SOAtest and/or Virtualize will not be able to communicate with the service if it cannot first locate a valid TGT. For more information about Kerberos, see Configuring Kerberos Authentication.

About Kerberos Authentication

Kerberos authentication is known as a trusted third-party authentication mechanism. A client requests access to a service not directly, but from another service: the Key Distribution Center, which manages network-wide authorization. This mechanism facilitates Single Sign-On (SSO) so that a client need only provide authorization credentials once in a given time period (usually 8-10 hours). The authorization is granted in the form of a ticket which can then be cached and reused throughout the granted time period without re-authenticating.

Entities in a Kerberos-protected network, such as clients and servers, are known as principals. The network-space that Kerberos protects is known as a realm. Microsoft's IIS (Internet Information Services) Server provides HTTP-based services with Kerberos through the Negotiation protocol. Other server vendors provide their own implementations of Microsoft's Negotiate protocol.

The ticket that is received upon initial authentication is known as a Ticket Granting Ticket, or TGT. For example, in a Windows environment, the TGT is generated when first logging on to the workstation in the morning. SOAtest and/or Virtualize authorizes itself to use a Kerberos-protected service by retrieving a user's TGT from the system cache.

Configuring Kerberos Authentication for Tools

1. Select the tool for which you intend to use Kerberos authentication.
2. Select the Transport tab and select Security from the left pane of the Transport tab. 
3. Configure the following options from the security panel of the Transport tab:
   1. Perform Authentication: Select this option to activate authentication.
   2. Use Global Preferences: Select this option if you have authentication properties setup in Security Preferences.
   3. Type: Select Kerberos to perform Kerberos Authentication.
   4. Service Principal: Specify the name of the service/server as defined in the Kerberos database (e.g. HTTP/soatest.parasoft.com).

Now when you invoke your tool, the required Negotiate token will automatically be generated and send as an HTTP header. Kerberos provides a mechanism to prevent so-called "replay" attacks where a user tries to provide captured duplicate credentials for a service in order to gain access to them. 

Server Certificate Settings

Enable the Trust all certificates option to accept any certificate. This is useful if you want to load pages whose certificates are not "trusted."

Enable the Use default Java cacerts option to accept only certificates from the standard list of Java-trusted certificate vendors.

Client Key Store Settings

Enable the Use client keystore option to specify settings for both the server side and client side certificates for SSL through the Client Keystore options.

Keystores are specified at the test or responder suite level. If this option is selected, the following options are available in the Certificate and Private Key tabs:

Certificate Tab

• Use same key store for private key: Select if the Key Store contains private keys for the certificate.
• Key store file: Specify the key store file by clicking the Browse button and using the file chooser that opens. If you want the path saved as a relative path (for example, to facilitate project sharing), check the Persist as Relative Path option.
• Key store password: Specify the Key Store password.
• Key store type: Specify the type of Key Store being used (e.g. JKS, PKCS12, BKS, PEM, UBER)
• Load: Click to populate the aliases with the available certificates/keys if the path, type, and key store password are valid.
• Certificate alias: Specify the certificate alias.

Private Key Tab

• Key store file: (Only available if the Key Store Contains Keys option is unselected in the Certificate tab) Specify the key store file by clicking the Browse button and using the file chooser that opens. If you want the path saved as a relative path (for example, to facilitate project sharing), check the Persist as Relative Path option.
• Key store password: (Only available if the Key Store Contains Keys option is unselected in the Certificate tab) Specify the Key Store password.
• Key store type: (Only available if the Use same key store for private key option is unselected in the Certificate tab) Specify the type of Key Store being used (e.g. JKS, PKCS12, BKS, PEM, UBER)
• Load: Click to populate the aliases with the available certificates/keys if the path, type, and key store password are valid.
• Private key alias: Specify the private key alias.
• Private key password: Specify the private key password.

MQ SSL

...

• Trust all certificates: Enable this option to accept any certificate. This is useful if you want to load pages whose certificates are not "trusted."

• Use default Java cacerts: Enable this option to accept only certificates from the standard list of Java-trusted certificate vendors.

• Use client keystore: Enables you to specify settings for both the server side and client side certificates for SSL through the Client Keystore options.
  
  

Keystores are specified at the test or responder suite level. If this option is selected, the following options are available in the Certificate and Private Key tabs:

• Certificate tab options:
  • Use same key store for private key: Select if the Key Store contains private keys for the certificate.
  • Key store file: Specify the key store file by clicking the Browse button and using the file chooser that opens. If you want the path saved as a relative path (for example, to facilitate project sharing), check the Persist as Relative Path option.
  • Key store password: Specify the Key Store password.
  • Key store type: Specify the type of Key Store being used (e.g. JKS, PKCS12, BKS, PEM, UBER)
  • Load: Click to populate the aliases with the available certificates/keys if the path, type, and key store password are valid.
  • Certificate alias: Specify the certificate alias.
• Private Key tab options:
  • Key store file: (Only available if the Key Store Contains Keys option is unselected in the Certificate tab) Specify the key store file by clicking the Browse button and using the file chooser that opens. If you want the path saved as a relative path (for example, to facilitate project sharing), check the Persist as Relative Path option.
  • Key store password: (Only available if the Key Store Contains Keys option is unselected in the Certificate tab) Specify the Key Store password.
  • Key store type: (Only available if the Use same key store for private key option is unselected in the Certificate tab) Specify the type of Key Store being used (e.g. JKS, PKCS12, BKS, PEM, UBER)
  • Load: Click to populate the aliases with the available certificates/keys if the path, type, and key store password are valid.
  • Private key alias: Specify the private key alias.
  • Private key password: Specify the private key password.

About Kerberos Authentication

Kerberos authentication is known as a trusted third-party authentication mechanism. A client requests access to a service not directly, but from another service: the Key Distribution Center, which manages network-wide authorization. This mechanism facilitates Single Sign-On (SSO) so that a client need only provide authorization credentials once in a given time period (usually 8-10 hours). The authorization is granted in the form of a ticket which can then be cached and reused throughout the granted time period without re-authenticating.

Entities in a Kerberos-protected network, such as clients and servers, are known as principals. The network-space that Kerberos protects is known as a realm. Microsoft's IIS (Internet Information Services) Server provides HTTP-based services with Kerberos through the Negotiation protocol. Other server vendors provide their own implementations of Microsoft's Negotiate protocol.

The ticket that is received upon initial authentication is known as a Ticket Granting Ticket, or TGT. For example, in a Windows environment, the TGT is generated when first logging on to the workstation in the morning. SOAtest and/or Virtualize authorizes itself to use a Kerberos-protected service by retrieving a user's TGT from the system cache.

Anchor
Configuring Kerberos Authentication in SOAtest Configuring Kerberos Authentication in SOAtest

Anchor
Configuring Kerberos Authentication in Virtualize Configuring Kerberos Authentication in Virtualize

Configuring Kerberos Authentication 

1. Configure the following options in the Security preferences panel:

1. • Kerberos realm: Specify the Kerberos realm associated with your network. By convention, this is typically your domain name in all caps (e.g. PARASOFT.COM).

   • KDC server: Specify the hostname of your Key Distribution Center (e.g. kdc.parasoft.com).

   • Check Ticket: Click to execute a simple test to locate a cached Kerberos TGT (Ticket Granting Ticket) to grant access to the service. SOAtest and/or Virtualize will not be able to communicate with the service if it cannot first locate a valid TGT.

2. Select the tool for which you intend to use Kerberos authentication.
3. Select the Transport tab and select Security from the left pane of the Transport tab.

Configure the following options from the security panel of the Transport tab:

1. • Perform Authentication: Select this option to activate authentication.
   • Use Global Preferences: Select this option if you have authentication properties setup in Security Preferences.
   • Type: Select Kerberos to perform Kerberos Authentication.

   • Service Principal: Specify the name of the service/server as defined in the Kerberos database (e.g. HTTP/soatest.parasoft.com).

2. Now when you invoke your tool, the required Negotiate token will automatically be generated and send as an HTTP header.

JCE Prerequisite

Anchor
JCE Prerequisite JCE Prerequisite

In order to perform security operations that use XML Signature Verifier, XML Signer, or XML Encryption tools—or to use Key Stores— you will need to download and install the Unlimited Strength Java Cryptography Extension. You can do this as follows:

...

...