WEB-MON Plug-in - Technical Reference

Introduction

Geneos WEB-MON Plug-In checks a WEB Server's ability to supply pages/files by requesting a series of pre-set pages/files on a regular basis.

Page/file availability, response time, data size and any HTTP headers are displayed and rules can be set to alert when a page/file becomes unavailable or when the response times are unacceptable.

This is particularly useful when WEB Servers are managed by an Application Service Provider (ASP) or Internet Service Provider (ISP), where this could be the only facility to ensure the quality of the service.

All HTTP Web Server types are supported. Where servers publish their type, this information is displayed for reference.

Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored.

Note: The cURL library used by WEB-MON plug-in cannot utilise JavaScript. Refer to ITRS Synthetic Monitoring User Guide for more information.

Scenarios and Stages

The configuration of the WEB-MON plug-in is broken down into a number of scenarios. Each scenario allows a series of stages (web pages or files) to be requested in sequence, in the same way that a user would do. Scenarios themselves are run in parallel.

Stages have a set of success criteria associated with them, such as a response code or time to complete. If the criteria are not met then the stage and the overall scenario will fail.

If the website is simple then a number of scenarios may exist, each of which may be composed of a single stage. These could then check that a number of key pages are available.

If the website is more complex then more stages may be needed in the scenarios. An example scenario might be to log in with a username and password, and then request a page that is unavailable without a login. Another scenario may be to deliberately enter an incorrect username and password, and verify that the request for the protected page fails.

The Examples section of this document describes possible uses in more detail.

Views

The WEB-MON plugin produces one view which can be displayed in Summary or Summary and Details mode.

WEB-MON plugin in Summary mode:

webmon2

WEB-MON plugin in Summary and Details mode:

webmon3

The samplingStatus will show OK if the sampling takes longer than the initial sample period to complete a scenario, or FAILED if the setup is incorrect.

Headline Legend

The headlines are shown above the main table and provide an overview of the state of the server.

Name	Description
serverName	The name of the server, as specified in the setup. This is what is sent as the Host header in the request.
ipAddress	The IP address that has been resolved from the server name or proxy name.
serverURL	If present, the ipAddress, serverType and serverState fields are populated as a result of making a request for this URL (relative to serverName). Otherwise, the mentioned fields are populated as a result of making a request for "/" (which is typically the default server webpage).
portNumber	The port being used. This will typically be 80.
serverType	If the server publishes a type (Server header) then this will be displayed here. If a proxy server has responded with an error then this will be the proxy server type.
serverState	This will be one of: UP - The server is responding to requests UNAVAILABLE - The server name cannot be resolved or the web server is not running. TIMEDOUT - The server is running, but has taken too long to reply. UNKNOWN - Another type of error has occurred. If a proxy server is used this will show the state of the proxy server, not the destination server.
scenariosFailed	A count of the number of scenarios that have failed.
scenariosInError	A count of the number of scenarios that have errors.
scenariosTimedOut	A count of the number of scenarios that have taken too long to run.
protocol	Whether http or https is being used.
proxy	Server name and port of proxy server being used, if any.

The ipAddress, serverType and serverState columns are populated as a result of making a request for the default server webpage (/).

Table Legend

The columns in the table are broken up into two parts:

The first set of columns show status information about the stages and scenarios;

The second set of columns show more details about the requests and responses. For scenarios, the second set of columns will show the details of the last stage to run. For successful scenarios, this will be the last stage. For unsuccessful scenarios this will be the stage that failed.

Name	Description
name	Scenario Name or Scenario Name # Stage No. # Stage Name
status	For scenarios, the status can be: OK - Every stage of the scenario ran successfully. TIMEDOUT - The scenario took too long to run. ERROR (stage name) - An error occurred on the specified stage during retrieval. FAILED (stage name) - The page for the specified stage did not meet the relevant success criteria. This includes the page taking too long to retrieve. IDLE - Nothing is happening. Probably because no stages have been configured. For stages, the status can be: OK - The page was downloaded correctly and met all the criteria DOWNLOADING - The page is currently being downloaded. TIMEDOUT - The stage took too long to run. ERROR - There was a problem getting a response from the server. FAILED - The success criteria have not been met. CANCELLED - The scenario cancelled this request. This could happen if the scenario took too long to run. SKIPPED - A previous stage in this scenario did not complete successfully, so this stage was not run.
detail	If the status is not OK then this column provides more information about what went wrong.
duration	For stages this will be the time taken to resolve the hostname, make the request and get the page back. For scenarios this will be the time taken to run each stage, check the success criteria, and set up the next stage. The time will therefore sometimes be fractionally greater than the sum of the stage times.

Name	Description
url	The URL of the request
responseCode	The HTTP response code. This will be, for example, 200 for OK or 404 for Not Found. The full set of possible response codes can be found in RFC2616 References .
responseText	A textual description of the response code, as sent by the server.
downloaded	The number of bytes downloaded as the body of the page. If a Transfer-Encoding is used by the server then this will not necessarily be the same as the length of the content.
(additional headers)	Additional response headers may be configured, and these will be shown as extra columns in the view.

Plug-In Configuration

Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored.

Scenarios are configured with a number of stages in each. Stages can have additional data sent as part of the request, such as query variables and headers. They also specify a set of success criteria that, if breached, will cause a FAILED state to occur. In addition to the configurable success criteria, if the server sends a Content-Length header and the amount of data downloaded does not match this then the stage will fail.

It is possible to configure connection details at the scenario or stage level in addition to the top level. This allows connections to other servers if, for example, authentication is required from a central location. It also allows monitoring of multiple domains that are served from the same physical web server, or checking both secure and non secure versions of a site.

Although setting different connection details would also allow multiple physical servers to be monitored from the same WEB-MON instance, this is not recommended, and the headline variables will only show the status of the main server being monitored.

The configuration parameters are listed below:

host

The full name of the server to monitor.

This should be entered as it is entered in a web browser, and might not be the same as the physical hostname of the server if virtual hosting is being used. For example, a server serv1 might be hosting www.example.com and www.example.net. The host should be set to www.example.com or www.example.net rather than serv1.

Mandatory: Yes

port

The port of the server to monitor.

Mandatory: No

Default: 80 (http) or 443 (https)

serverURL

If specified, the ipAddress, serverType and serverState headline fields are populated as a result of making a request for this URL (relative to host). Otherwise, the mentioned fields are populated as a result of making a request for "/" (which is typically the default server webpage).

For example: if host is set to www.example.com and serverUrl is set to sample1, the request would be made for www.example.com/sample1. If this field is not set, request would be sent for for www.example.com instead.

Mandatory: No

Default: 80 (http) or 443 (https)

protocol

Whether to use http (unencrypted) or https (SSL encrypted). When using SSL connections, the server certificate can also be verified.

Mandatory: No

Default: http

protocol > https > certificate

Certificate to use for the SSL authentication.

Setting	Description
Verify	Whether to check the server certificate.
Client Certificate	Certificate that will be sent to a web server that requires SSL client authentication. Must be in PEM format. Required for client authentication.
Client Key	Private key corresponding to the client certificate. Must be in PEM format. Required for client authentication.
Client Key Passphrase	Passphrase used to encrypt the private key. Needs to be specified only if private key is passphrase-protected.

Note: In Windows, WEB-MON makes use of OS-specific certificate stores for identifying certificates to use during SSL authentication. As such, the required certificates must be installed in the appropriate certificate stores. Certificate and certificate-related settings are ignored.

Mandatory: No

Default: No

protocol > https > certificate > verify

What to check within the certificate.

Setting	Description
None	Will succeed as long as any certificate is present.
Against authority	Checks the certificate to ensure it has been signed by a Certificate Authority (CA) that is trusted, but doesn't check that the hostname matches.
Against authority and hostname	Checks that the certificate has been signed by a trusted CA and that the hostname matches

When checking the certificate against a Certificate Authority then a CA Bundle in PEM format must be used. This file specifies the CAs that are to be trusted. If the operating system has not come with a CA or it is out of date then a CA Bundle should be specified.

This can either be constructed (if, for example, you wish to add your own trusted authorities when self-signing) or downloaded. If you wish to generate your own then please search online for 'Creating a PEM CA bundle'. If you just wish to download an existing one then you can do so from the cURL page describing how to extract CA certificates from Mozilla: http://curl.haxx.se/docs/caextract.html

Mandatory: No

Default: none

proxy

Settings for making connections via proxy servers.

Note: If a proxy is specified at the top level then this changes the behaviour of some headline variables.

Name	Description
serverName	Unchanged
serverURL	Unchanged
ipAddress	This will be the IP address of the proxy.
portNumber	Unchanged
serverType	In the event that the proxy server responds with an error then this will be the proxy server type, otherwise it will be unchanged.
serverState	The state of the proxy server. The state of the destination server is invisible to the netprobe. If the destination server is unavailable the proxy will likely respond with an http error code, however this could equally have come from the destination server. There is no way to tell. The server type should give a clue as to whether the request reached the destination or got no further than the proxy.
scenariosFailed	Unchanged.
scenariosInError	Unchanged.
scenariosTimedOut	Unchanged.
protocol	Unchanged.
proxy	Configured proxy connection settings.

Mandatory: No

Default: none

proxy > none

Explicitly disable proxy.

proxy > proxyServer > host

Hostname of proxy server.

Mandatory: Yes

proxy > proxyServer > port

Port number of proxy server.

Mandatory: Yes

proxy > proxyServer > type

The type of proxy to use. Six types are currently supported.

HTTP	Http 1.1.
HTTP 1.0	Http 1.0.
SOCKS 4	Socks 4.
SOCKS 4A	Socks 4a.
SOCKS 5	Socks 5 but resolve the hostname locally.
SOCKS 5 Hostname	Socks 5 and let the proxy resolve the hostname.

Mandatory: Yes

proxy > proxyServer > authentication

Authentication settings for proxy.

Mandatory: No

Default: None

proxy > proxyServer > authentication > password

Allows username/password combinations to be sent to proxy servers.

proxy > proxyServer > authentication > password > loginCredentials

Contains details of the username and optional password. The password may be encoded in the setup file so that it is not easily visible if required. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See Authenticating with Kerberos for more details.

proxy > proxyServer > authentication > password > method

Allows various HTTP authentication methods to be selected. These are all enabled by default but only one method should be selected by the user. Disabling other methods may speed up the request and prevent usage of incorrect methods (depending on which methods are employed) so disabling other methods is highly recommended.

For example, if the user wants to use NTLM authentication, and the host is known to have both NTLM and Kerberos (GSS-Negotiate) authentication, it is highly recommended to enable NTLM authentication, and disable both Basic and Kerberos authentication.

Kerberos authentication requires additional configuration prior to use. See Authenticating with Kerberos for more details.

Mandatory: No

Default: All methods are enabled

authentication

Allows authentication information to be sent along with requests using various methods. When usernames and passwords are entered into webpage forms then query vars should be used instead. See the Checking Secured Pages example for more details.

Mandatory: No

authentication > httpAuthentication

Allows HTTP level authentication to be set

authentication > httpAuthentication > password

Allows username/password combinations to be sent to servers. When using a web browser, this authentication method is typically seen by a pop-up dialog box.

authentication > httpAuthentication > password > loginCredentials

Contains details of the username and optional password. To set an encrypted password, click on the "Set Password" button, then enter and confirm the password to be used. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See Authenticating with Kerberos for more details.

authentication > httpAuthentication > password > method

Kerberos authentication requires additional configuration prior to use. See Authenticating with Kerberos for more details.

Mandatory: No

Default: All methods are enabled

display

Contains a number of settings to control how the information is displayed.

display > displayMode

The display mode will be one of:

Setting	Description
SUMMARY	Just display the Scenarios
SUMMARY+DETAILS	Display the Scenarios, and also display each of the Stages under each Scenario.

Mandatory: No

Default: SUMMARY

display > displayURL

You can display URLs in one of the following ways:

Setting	Example Result
PATH	/path/to/file.html
PATH+QUERY	/path/to/file.html?name=value&name=value
FULL	http://www.example.com/path/to/file.html
FULL+QUERY	http://www.example.com/path/to/file.html?name=value&name=value

You may not wish the query part of the URL to be shown in the view if it contains sensitive information, however if you use the 'encoded' query variables option then it will be shown as name=[encoded] so that it is not visible in Geneos. Even with all these measures in place, this will not prevent the information showing up in any server logs.

Mandatory: No

Default: PATH

display > displayHeaders

If you wish to see additional HTTP headers then they can be specified here. Each one will appear as a new column in the view. This is particularly useful if your web application writes out custom headers.

A full list of standard headers can be found in RFC2616 References. Examples of potentially useful headers are: Content-Length, Last-Modified, X-Powered-By.

Mandatory: No

Default: No additional headers

maxInitialSample

When each sample starts it will check the status of the downloads every 0.1 seconds for an initial period. If it hasn't finished after that time then it will leave the downloads in the background and relinquish control to other samplers. It will then check the status again while other samplers aren't sampling, until all the scenarios are complete. The minimum time between these additional checks is 1 second.

                    Mandatory: No
                  
                    Units: Seconds
                  
                    Default: 5

maxServerDuration

This setting allows the maximum amount of time to wait for the main server status - the settings which allow the headline variables to be populated.

                    Mandatory: No
                  
                    Units: Seconds
                  
                    Default: 60

scenarios

Contains the list of scenarios. If no scenarios are configured then only the default server webpage (/), or the serverUrl(if provided), will be monitored and the results shown in the headline variables.

scenarios > scenario

A scenario is a named object that consists of a number of requests to the same web server (scenarios > scenario > stages). Cookies are maintained within a scenario but not between scenarios.

scenarios > scenario > name

Specifies the name of a scenario. Each scenario should have a unique name within this sampler. The scenario mode will be displayed as the row name in the dataview, and will also form the first part of the row names when SUMMARY+DETAILS is selected as the display > displayMode.

scenarios > scenario > connection

This allows the connection details to be overridden. See the following sections for more details:

host
port
protocol
authentication
proxy

scenarios > scenario > successCriteria

Allows success criteria to be specified for the whole scenario. Each stage also has its own, more extensive, success criteria.

scenarios > scenario > successCriteria > maxDuration

This specifies the maximum amount of time the scenario is allowed to run for. If this time is exceeded then the scenario will be marked as TIMEDOUT, the current stage will be CANCELLED and any remaining stages will be SKIPPED.

                      Mandatory: No
                    
                      Units: Seconds
                    
                      Default: 60

scenarios > scenario > stages

Contains the list of stages. A stage is a single request to a web server. Requests in a scenario are made in the order they are declared in the setup.

scenarios > scenario > stages > stage

A stage is a named step inside a scenario. A stage is a single request to a web server.

scenarios > scenario > stages > stage name

Specifies the name of the stage. This should be unique within the scenario. It will be seen in the scenario line if this particular stage fails. It will also form the second part of the row names when SUMMARY+DETAILS is selected as the display > displayMode.

scenarios > scenario > stages > stage > connection

This allows the connection details to be overridden. See the following sections for more details:

host
port
protocol
authentication
proxy

scenarios > scenario > stages > stage > url

Specifies the URL (relative to the server root) of the page to request. Example:

/path/to/file.html

It is possible to specify the query string as part of the URL, but it must be properly encoded. This may be used in addition or as an alternative to the queryVars table. The queryVars table is preferred as any name/value pairs in this table will be encoded by the plugin, and hiding of sensitive information is also supported. Example:

/path/to/file.html?name=value&name=value

Mandatory: Yes

scenarios > scenario > stages > stage > requestData

This configuration allows the request to be altered

scenarios > scenario > stages > stage > requestData > method

Sets the request method to GET or POST.

GET is the normal option for standard page requests, and POST is the normal option when submitting information to forms, particularly if a lot of data is to be sent, or if sensitive information needs to be transferred so that it won't show up in server logs and proxies as part of the request URL.

Although it is possible that either method can be used in either case, sometimes when forms are involved the server will insist on one method or another so it is worth checking the page source to see which is used. See the Checking Secured Pages example for more details.

Mandatory: No

Default: GET

scenarios > scenario > stages > stage > requestData > method > get > queryVars

The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them.

It is also possible to perform Geneos-level encoding of the values for when sensitive information such as passwords is used. This information will not show up in the setup file, and if the PATH+QUERY or FULL+QUERY displayURL option is selected then this data will show up as [encoded] in the dataview. For example:

/login.php?username=myname&password=[encoded]

Mandatory: No

Default: No additional variables

scenarios > scenario > stages > stage > requestData > method > post > body > queryVars

The query variables to be sent as the body of the POST request. Each name value pair is url encoded and then passed to the server with the Content-Type: x-www-form-urlencoded unless overridden in the requestHeaders configuration.

For example:

Geneos: Netprobe
Gateway: Webmon

would be encoded as:

geneos=netprobe&gateway=webmon

Mandatory: No

Default: Empty Post Request

scenarios > scenario > stages > stage > requestData > method > post > body > rawData

The body of the post request to be sent to the server, as a string. This allows Webmon to post any type of string data to the server, for example SOAP requests.

Note: You should also add the Content-Type to the requestHeaders configuration to indicate to the server the mime-type of the raw data that Webmon will send. For example a SOAP request would have a Content-Type of application/soap+xml. If this header is not specified the type will default to x-www-form-urlencoded.

Mandatory: No

Default: Empty Post Request

scenarios > scenario > stages > stage > requestData > queryVars

Deprecated: use queryVars under the GET or POST elements

The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them.

/login.php?username=myname&password=[encoded]

Mandatory: No

Default: No additional variables

scenarios > scenario > stages > stage > requestData > requestHeaders

The request headers allow additional headers to be sent to the server as part of the request. An example of use might be to change the User-Agent header for applications that serve different pages depending on the web browser being used.

A full list of standard headers can be found in RFC2616 [1].

An example of use may be seen in the Changing Request Headers example.

Mandatory: No

Default: No additional headers

scenarios > scenario > stages > stage > successCriteria

This configuration section allows the response to be checked against a set of criteria. This will determine whether the scenario and stage show as OK or FAILED in the dataview.

scenarios > scenario > stages > stage > successCriteria > responseCodes

The response codes specify the acceptable responses given by the server. These are all three digit codes. The first digit specifies the type of response, and the other two digits provide more detail. 4xx codes are problems with the request, such as specifying a URL for a file that doesn't exist. 5xx codes are server errors, when a problem occurred trying to fulfil the request.

A full list of the response codes and their meanings can be found in RFC2616 References.

Mandatory: No

Default: All codes in the 100 to 399 range

scenarios > scenario > stages > stage > successCriteria > maxDuration

This specifies the maximum amount of time the stage is allowed to run for. If this time is exceeded then the stage will be TIMEDOUT and any remaining stages in the scenario will be SKIPPED. The scenario will then show FAILED.

                      Mandatory: No
                    
                      Units: Seconds
                    
                      Default: Unlimited

scenarios > scenario > stages > stage > successCriteria > response

Can check the response from the server for various different conditions

scenarios > scenario > stages > stage > successCriteria > response > expression

The expression defines, using Boolean and/or/not logic, which of the conditions need to be met in order for the server response to be valid. For example, you may define a page content condition called 'failed' which matches against the text 'login failed please try again' and then the expression would be:

not "failed"

Right clicking on the expression editor will bring up a menu that gives access to the available operators, and also provides some common templates for expressions that may be used.

scenarios > scenario > stages > stage > successCriteria > response > conditions

Allows the various different conditions to be specified. These can then be used in the expression above to define the criteria under which the response matches.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent

The page content checks look at the actual page - the text that would be seen in a browser's 'Show Page Content' or 'View Page Source' options.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string

Checks the page content against an exact piece of text.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string > text

The actual text to match against

Mandatory: Yes

scenarios > scenario > stages > stage successCriteria > response > conditions > condition > type > pageContent > match > string > caseSensitive

Whether to perform a case sensitive comparison. Case sensitive comparisons will be slightly quicker, so if the case of the text you are looking for is not going to change then this is the best option.

Mandatory: No

Default: true

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex

Checks the page content against a regular expression.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > regex

The perl-compatible regular expression to use. Example:

a.\*b

Mandatory: Yes

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > flags

This a set of zero or more regex flags which can affect how the regex is applied to the contents of the web page. For example if 'i' is specified then the web page contents is considered in a case-insensitive manner when the regex is being applied to it.

Any of the following flags may be specified:

Setting	Description
i	Case insensitive
s	A dot should match all characters when applying the regex. This is required if the expression will span several rows since a dot will not match newline characters by default.

Mandatory: No

Default: All flags are false

scenarios > scenario > stages > stage > dataTransfer

If a page downloads correctly and passes all the success criteria then the content may be exported for other samplers to read, such as EXTRACTOR. The purpose of the web-mon plugin itself is to allow the server/app to be checked to ensure that it is returning pages. In contrast, the data transfer may be used, for example, to display the page content in a separate dataview so that the figures displayed can be monitored by Geneos.

The name selected does not have to match anything else in the web-mon plugin, however:

The name must match the name used in the sampler reading the data.
It must be unique on any particular Netprobe - if multiple instances of the same web-mon sampler are used on the same Netprobe (through use of different Managed Entities or Types) then variables must be used to make it unique.

If web-mon is only present to provide other samplers with information and you do not wish to see the status of the pages being retrieved, then once it has been set up you can prevent it being shown by setting the 'Publish' option to false in the Visibility tab of the Sampler configuration section.

Mandatory: No

Default: The page content is not exported.

Additional Configuration Information

This section provides additional configuration information needed to use certain features of this plug-in.

Authenticating with Kerberos

Before setting the plug-in to use Kerberos authentication to connect to a web server, the client machine must first acquire a Kerberos ticket-granting ticket from that web server. The following guidelines describe how to acquire the ticket on a Linux client machine with support for Kerberos. The plug-in currently supports Kerberos authentication on this platform only.

Verify that the Kerberos realm of the web server is defined in the Kerberos configuration of the client. The configuration file is in /etc/krb5.conf. Below is an example of the realms section of the configuration file:

...
 [realms]
   EXAMPLE.COM = {
    kdc = kerberos.example.com:88
    admin_server = kerberos.example.com:749
    default_domain = example.com
 }
...

Check that the realm of the web server is defined with the corresponding names of the kdc, admin server and default domain.

Generate the Kerberos ticket-granting ticket for an authorized user and store it in the default location. This can be done by running kinit <user@realm> on the command line. Enter the password when prompted.

# kinit User@EXAMPLE.COM

Run klist on the command line to view the generated ticket. Verify that ticket is stored in the default location, i.e. /tmp/krb5cc_0.

# klist

The ticket has a finite lifetime and the client machine will need to regenerate it once it expires. The lifetime of a ticket is controlled by the Kerberos Key Distribution Center (KDC) of the web server, which issues the tickets. The default expiration is typically set to 8 or 10 hours, but can be configured to a longer duration in the KDC. Ticket renewal polices can also be set between the web server and client. Consult your web server administrator on how to configure Kerberos the ticket lifetime and renewal.

Examples

This section provides more detailed examples possible uses of this plug-in.

Simple Server Status Monitoring

If the requirement is just to check that a particular server is up, then no scenarios need to be configured. The plug-in will make requests for the default server page ( / ), or the serverUrl (if provided), and use this to decide on the server status.

Checking Simple Pages

If there are pages that need to be available on the server, these may be configured as single stage scenarios. One scenario would be written for each page, as the requests do not have to happen in any particular order. The plug-in would try and access all these pages simultaneously to minimise the time taken to perform a sample. Since each scenario only has one stage, the display should probably be set to SUMMARY.

Checking Secured Pages

If a login is required to view pages, scenarios may be configured with the login page as the first stage, and the page to check as the second stage. Query variables can then be used to pass the username and password to the login page.

To find out the query variables that need to be used, it is necessary to look at the source of the login page. This would look something like this:

...
<form action="/site/login.php">
...
<input type="text" name="username">
...
<input type="password" name="passwd">
...
</form>
...

In this case, the URL should be set to /site/login.php, and the query variables needed are username and passwd.

Depending on how the login was written, it may require other name/value pairs to be set. It may require hidden variables, like this:

<input type="hidden" name="action" value="login">

or the submit button, like this:

<input type="submit" name="submit" value="Log Me In">

It is also worth checking the request method, which will also be part of the form definition:

<form action="/site/login.php" method="POST">

The method (either GET or POST) can be set as part of the request data for the stage.

Checking Security of Pages

It is also possible to ensure that it is not possible to access pages that have been secured behind a login. In this case, a single stage is needed that accesses the secured page. The acceptable responseCode should then be set to 403 (Forbidden). The scenario will then be successful if it is not possible to view the page.

Another similar test would be to visit the login page first, but deliberately enter in an invalid username/password.

Changing Request Headers

It is possible to change the headers that get sent as part of the request. One possible use would be to change the User-Agent if the same URL is used to serve pages for different browsers, or for a browser and a PDA.

In this case scenarios could be set up with a User-Agent requestHeader of:

Mozilla/4.0 (compatible; MSIE 6.0; Win32)

and another with

Nokia6630/1.0 (2.39.129) Series60/2.6 Profile/MIDP-2.0 Configuration/CLDC-1.1

That would allow the responses to be compared for Internet Explorer 6 and a Nokia 6630 mobile phone. User-Agent strings for common browsers and wireless devices can be found on the Internet.

References

RFC2616 - Hypertext Transfer Protocol - HTTP/1.1

RFCs are "Request For Comments" documents and each system used on the Internet has one that describes exactly how to use it. The documents are all numbered and are hosted many places on the Internet. RFC2616 can be found by performing a search for "RFC2616" in any search engine.

Known Issues

IPv6 with NTLM

In a few cases timeout issues have been seen when using NTLM authentication with some types of IPv6 environments.

If you experience any issues then please contact ITRS support so that we can gather more information to diagnose the root cause.

Kerberos Authentication

Kerberos authentication by GSS-Negotiate has been added to the authentication method options. This option is currently supported in Linux only. To use this method, the plug-in requires that the client machine generate the Kerberos ticket-granting ticket from the corresponding web server and store it using the default file setting. The plug-in does not generate the ticket on its own and only looks for it in the default location when performing the authentication. The ticket must also be renewed outside of the plug-in when it expires.