Message interceptors

When visitors and agents interact with Unblu’s live chat or secure text messaging feature, there is the potential risk of data leakage: one of the participants shares information that your organization considers too sensitive to transmit in a text conversation.

For example, your organization may have a policy that credit card numbers may only be transmitted in conversations with authenticated visitors. If an unauthenticated visitor asks a question about their credit card from your public website, you want to prevent them from transmitting their credit card number.

To prevent data leakage, Unblu lets you use message interceptors to vet messages before they’re made visible to the other participants in a conversation. For simple pattern matching tasks, you can use Unblu’s internal message interceptors. If you need to carry out more complex vetting procedures, you can integrate external message interceptors.

How message interceptors work

The diagram below shows how the interception process for messages works:

Figure 1. Message interception process

When someone sends a new message to a conversation, Unblu retrieves all the message interceptors configured for the conversation. Which interceptors that encompasses depends on the conversation template used to create the conversation as well as the conversation’s language and state; see below for further information.
The message is sent to all the message interceptors Unblu collected to be evaluated. The interceptors evaluate the message in parallel.
If an interceptor rejects the message, Unblu rejects the message. The effect this has depends on the severity of the interceptor that rejected the message; see below for more information on rejeection severity levels.

Creating and managing message interceptors

The Unblu web API has a number of endpoints to query, create, and manage message interceptors. The web API reference describes how the endpoints work.

You can also create message interceptors in the Account Configuration interface. For more information, refer to the relevant section or the Account Interface guide.

The sections below provide additional information that’s useful when creating and managing message interceptors.

Regular expressions in internal message interceptors

All internal message interceptors use regular expressions to evaluate the messages passed to them.

If the interceptor’s point of interception is before the message is persisted, the syntax of the regular expression must match that of JavaScript.
If the interceptor’s point of interception is after the message is persisted, use the regular expression syntax described in the documentation of the Java Pattern class.

There may be some differences in the syntax, so if you change an internal message interceptor’s point of interception, you should verify that your regular expression still blocks all the messages you want blocked.

IMPORTANT: Changes to internal message interceptors are only applied to conversations that start after you save the change.

Rejection severity levels

The rejection severity determines which participants can see the text of the rejected message. The table below shows what different participants see for rejected messages with different rejection severity levels.

Table 1. Text visibility for different participant types depending on the rejection severity level
	Rejection severity level
	High	Medium	Low
Context person	Hidden	Hidden	Hidden
Assigned agent	Hidden	Visible, no text	Visible with text
Secondary visitor	Hidden	Hidden	Hidden
Secondary agent	Hidden	Visible, no text	Visible with text
Ghost participant	Visible with text	Visible with text	Visible with text

The rejection severity also affects how rejected messages appear in conversation logs.

If the person generating the logs was the sender of the rejected message, the original text is displayed, prefixed with the value of com.unblu.conversation.export.labelMessageRejectedPrefix.
If the person generating the logs wasn’t the sender of the rejected message, the original text is only displayed if the person has permission to view messages with the rejection severity of the message. If the text is displayed, it’s prefixed with the value of com.unblu.conversation.export.labelMessageRejectedPrefix. If the person doesn’t have permission to see the original text, only the prefix is displayed.

Configuring message interceptors

Once you’ve created a message interceptor, you must configure the Unblu Collaboration Server to use it the way you want.

Using message interceptors in conversations

To use a message interceptor in a conversation, you must add it to the conversation template that the conversation is created from.

You can add individual message interceptors in the configuration property com.unblu.conversation.message_interceptor.messageInterceptorIds.
If you want to use all your message interceptors in a conversation template, set the configuration property com.unblu.conversation.message_interceptor.enableAllMessageInterceptors to true instead. This overrides the list of individual message interceptors.

Message interceptor timeout behavior

You can configure how the Collaboration Server should behave if it doesn’t receive a response from a message interceptor.

The configuration property com.unblu.conversation.message_interceptor.maxInterceptionTime defines the time each message interceptor has to evaluate a message and send the result to the Collaboration Server.
com.unblu.conversation.message_interceptor.timeoutSeverity lets you define the default rejection severity for messages that the Collaboration Server doesn’t receive an evaluation result for. You can override the value in each message interceptor’s own settings.

Disabling message interceptors

If a message interceptor is causing issues, you can disable it in the Account Configuration interface:

Click the message interceptor in the message interceptor overview.
Click the Enabled switch to disable the interceptor.
Click Save to save your changes.

Manually disabled message interceptors aren’t included in the message interception process for new conversations. How disabling an interceptor affects ongoing conversations depends on the point of interception:

Disabling a message interceptor that intercepts messages after persisting doesn’t affect ongoing conversations.
Disabling a message interceptor that intercepts messages before persisting only affects ongoing conversations if the participants refresh their browser tab.

Message interceptors that were disabled automatically because their endpoints aren’t reachable are included in the message interception process. They generate an error that eventually leads to Unblu rejecting all messages.