---
title: Adding WebSocket handshake rules
description: Add a WebSocket handshake rule, which lets you define the domains that can open a cross-origin WebSocket to the application or resource.
component: pingaccess
version: 9.0
page_id: pingaccess:pingaccess_user_interface_reference_guide:pa_adding_websocket_handshake_rules
canonical_url: https://docs.pingidentity.com/pingaccess/9.0/pingaccess_user_interface_reference_guide/pa_adding_websocket_handshake_rules.html
revdate: February 13, 2023
section_ids:
  about-this-task: About this task
  steps: Steps
  choose-from: Choose from:
---

# Adding WebSocket handshake rules

Add a WebSocket handshake rule, which lets you define the domains that can open a cross-origin WebSocket to the application or resource.

## About this task

You can also define allowed WebSocket subprotocols and extensions, providing more fine-grained control over how the application behaves.

## Steps

1. Click **Access**, then go to **Rules > Rules**.

2. Click **[icon: plus, set=fa]Add Rule**.

3. In the **Name** field, enter a unique name up to 64 characters long.

   Special characters and spaces are allowed.

4. From the **Type** list, select **WebSocket Handshake**.

5. In the **Allowed Origins**, enter one or more origins.

   If no origins are defined, all cross-origin WebSocket requests are denied.

   |   |                                                                                                                       |
   | - | --------------------------------------------------------------------------------------------------------------------- |
   |   | Avoid using a value of `*` in this field. While this is a valid configuration, it is considered an insecure practice. |

6. Modify the list of **Allowed Subprotocols**.

   Subprotocols are defined in the `Sec-WebSocket-Protocol` handshake header. The default value of `*` allows all subprotocols.

7. Modify the list of **Allowed Extensions**.

   WebSocket extensions are defined in the `Sec-WebSocket-Extensions` handshake header. The default value of `*` allows all extensions.

8. To configure rejection handling, click **Show Advanced Settings**, then select a rejection handling method.

   ### Choose from:

   * If you select **Default**, use the **Rejection Handler** list to select an existing [rejection handler](pa_rejection_handlers.html) that defines whether to display an error template or redirect to a URL.

   * If you select **Basic**, you can customize an error message to display as part of the default error page rendered in the end user's browser if rule evaluation fails. This page is among the templates you can modify with your own branding or other information. If you select **Basic**, provide the following:

     1. In the **Error Response Code** field, enter the HTTP status response code to send if rule evaluation fails.

        The default is `403`.

     2. In the **Error Response Status Message** field, enter the HTTP status response message to send if rule evaluation fails.

        The default is `Forbidden`.

     3. In the **Error Response Template File** field, enter the HTML template page for customizing the error message that displays if rule evaluation fails. This template file is located in the `<PA_HOME>/conf/template/` directory.

     4. From the **Error Response Content Type** list, select the type of content for the error response.

        This lets the client properly display the response.

9. Click **Save**.