WebSocket Monitoring

How to Create Devices and Targets

• • Creating a Device
  • Adding Several Targets within a Single Device

WebSocket is a communication protocol that works over TCP and is designed to exchange messages between a browser and a web server in real time. The browser (client) and server use a protocol similar to HTTP to establish a WebSocket connection.

For more information about the WebSocket protocol and WebSocket-based application monitoring, please visit the Dotcom-Monitor blog.

A WebSocket device created in the Dotcom-Monitor platform checks a single WebSocket URL for availability, performance, proper content, and errors. The monitoring device can also be configured to validate security certificates and response content.

Configuring a Request

URL

To open a WebSocket connection, you are required to enter the WebSocket URL of the endpoint or IP address of the WebSocket URL you wish to check (the ws:// and encrypted wss:// protocols are supported). For example, wss://echo.websocket.org/

To turn on a more visually-friendly input mode, click the Detailed switch on the top of the section.

You can convert the URL to a dynamic value or context parameter here. For example, you can dynamically change the target URL while monitoring.

Send Data

Once the connection has been opened, Dotcom-Monitor listens to the events in the socket. If you need to transfer data to the target endpoint, in the Send Data field, specify a message in a string or binary format. Dotcom-Monitor will send the message to the target endpoint using the WebSocket protocol and wait for the response.

Dotcom-Monitor supports Razor expressions in the WebSocket messages. To send a string that contains a Razor expression, enter it in the Send Data field and use the Prepare Script to set the message type to Razor expression. Otherwise, the message will be parsed and sent as text. Use the following snippet in the Prepare Script field to notify the system that it must parse the message with the Razor engine:

ProcessPostDataByRazor(currentTask);

In addition to the Razor engine, Dotcom-Monitor enables dynamically changing request body data by using data masks. To learn how to use the Razor syntax and data masks in sent data, and configure dynamically changing payload, see How to Dynamically Change Payload in HTTP Request.

Response Validation (Content Validation)

To validate a message string received from the WebSocket, you can assert keywords in the call execution scenario. The system will wait for the response from the target endpoint and check the received message for the presence of the specified keyword in the string until the monitoring task completion timeout is reached. If the keyword was not detected in the responses from the socket, an error will be generated.

In the Keyword fields, you can specify one word or phrase that you wish to search for in the response message. Use the plain text to specify a keyword:

Prepare Script and Post Script

The fields can contain C# code, which can be used for specific requests and URL data or for validating or publishing custom headers. Please see the Using Prepare Script and Post Script article or contact technical support for more details on usage.

The dynamic scenario of the WebSocket call execution can be specified in the Prepare Script field. The dynamic scenario can include a number of operations with binary or string data.

Binary formatted operations (msg as Base64 encoded):

• ValidateBinary(string msg) – checks if a WebSocket response is equal to specified binary data.
• ValidateBinaryContains(string msg) – checks if a WebSocket response contains specified binary data.
• SendBinary(string msg) – sends a binary message to a WebSocket.

Text formatted operations:

• SendText(string msg) – sends a text string to a WebSocket.
• ValidateText(string msg) – checks if a response from a WebSocket is equal to a specified string.
• ValidateTextContains(string msg) – checks if a WebSocket response contains a specified string.

Delay:

• Delay(string duration) – sets a delay between websocket messages in seconds in the following format: XXs. The system will wait for the specified time before executing the next operation in the script. Note that too long delays can lead to the script termination due to the task completion timeout.

In cases where any assertion was specified in the Prepare Script field, the system will wait for the specified assertion in the response and proceed with the script execution once the validation is successful. If a message with the specified assertion is not received, and the task completion timeout is reached, we will generate the validation error.

Dotcom-Monitor allows you to include as many operations as necessary in the Prepare script. However, if the task completion timeout is reached, the script execution will be terminated. The task completion time is counted from the start of the script execution.

currentTask.SendText("This is a test");
currentTask.ValidateText("This is a test");

SSL/Certificate Check

Secure Socket Layer SSL Certificate Monitoring is a standard aspect of web monitoring.

The following options are available:

• Authority: verifies whether a certificate chain contains a root certificate that is trusted, or not trusted.
• Common Name (CN): validates that an address you navigate to matches the address certificate the address was signed to.
• Date: verifies the certificate expiration date.
• Revocation: validates that the certificate’s chain of trust doesn’t contain a revoked certificate.
• Usage: verifies a certificate chain for the improper use of an intermediate certificate.
• Expiration Reminder in Days: a reminder that notifies (as an error) about certificate expiration.
• Client Certificate: client certificate name.

Time Validation Threshold (in seconds)

Enter the number of seconds the task should wait for a response before ending the task and returning an error. The maximum timeout is 60 seconds. If this is left blank the default timeout of 60 seconds will be applied. The task completion time is counted from the start of the script execution.

Authorization

The HTTP authentication protocol is used to allow users to access content on some websites.

The following authentication schemes are available:

• Basic Authentication: This method encodes the username and password in base64 and sends them in the request header. It’s simple but not secure unless used with HTTPS.
• Digest Authentication: This scheme hashes credentials using a nonce (a random value) before sending them over the network, providing better security than Basic Authentication by preventing replay attacks.
• NTLM Authentication: A challenge-response mechanism developed by Microsoft, NTLM is used for securing credentials in Windows environments. It provides strong security by using multiple hashing and challenge-response protocols.

Once provided, login credentials will be passed along with the request header to the web server.

• Username: contains a username for HTTP/S  authentication.
• User Password: contains a password for HTTP/S authentication.

Do not confuse HTTP authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.

Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.

Headers

The option enables adding any additional custom headers if it is necessary.

• Header Name: specify the name of the parameter as it will appear in the request.
• Value: enter the value associated with the name of the parameter.

DNS Options

The DNS Options feature allows users to choose how domain name server (DNS) requests are conducted during a monitoring task.

To specify the mode of resolving hostnames, in the DNS Resolve Mode section, select one of the available modes. For more details on the feature configuration, see DNS Mode Options.

The Custom DNS Hosts section allows to set up the mapping of IP addresses to hostnames. IPv6 and IPv4 DNS resolution is supported.

To specify the mapping, enter the IP address and the hostname in the corresponding fields.

See also: DNS Mode Options.