(Advanced) Set Unicode allowlist
This action sets the Unicode codepoint allowlist that restricts names or messages.
It takes two parameters:
- Codepoint list name.
This is one of "client names", "channel names", "received by client", "received by server".
See below for more details. - The allowlist. The format is covered under Unicode notes.
If the format is blank, all code points are allowed, although the Unicode must still be valid and normalized.
There is a default Unicode allowlist for client and channel names.
Client names
This restriction is applied to client name sets and changes; including client names modified by the Server during the request.
This restriction is applied in all name set request handling modes, just like the other name limitations, like not allowing a blank name or reused name.
The new client name allowlist is not applied retroactively, so if client names that were already set fail the new allowlist, they will keep their names.
If the client requests a name that the server denies, it will get an automatic deny response with a deny reason:
name not valid (char U+XXXX 'X' rejected)
For example, in an allowlist set to letters only, a client name "Bob1" will be rejected with the deny reason:
name not valid (char U+0031 '1' rejected)
No error will be generated on the server side if an unmodified client name is rejected.
However, you can get the details of a name failure by checking a name manually, using the Convert string to UTF-8 and check against Unicode allowlist expression, and passing "client names" as an allowlist.
When name set handling is set to "wait for Fusion" mode, a client can request a name that would fail the allowlist, and it can be modified to one that matches (using the On interactive condition > Change name (for on name set/change request) action).
Channel names
This is applied to channels being created by channel joins, or being created by the server explicitly.
The restriction is also applied to channel names the Server modifies during a channel join request.
This restriction is applied in all channel join request handling modes, just like the other name limitations, like not allowing a blank name or reused name.
The new channel name allowlist is not applied retroactively, so if channels are already created with names that fail the new allowlist, they will stay open with all the already-joined clients remaining on the channels, although new clients cannot join the channel.
If the client requests a channel name that the server denies, it will get an automatic deny response with a deny reason:
name not valid (char U+XXXX 'X' rejected)
For example, in an allowlist set to letters only, a channel name "Bob1" will be rejected with the deny reason
name not valid (char U+0031 '1' rejected)
No error will be generated on the server side if a unmodified channel name is rejected.
However, you can manually check a name, using the Convert string to UTF-8 and check against Unicode allowlist expression, and passing "channel names" as an allowlist.
When channel join handling is set to "wait for Fusion" mode, a client can request to join a channel with a name that would fail the allowlist, and the name can be modified to one that matches (using the On interactive condition > Change channel name (for channel join request) action).
If a modified channel name fails the allowlist, you will get a server error similar to:
Cannot change joining channel name: Code point at index 6 does not match allowed list. Code point U+0031, decimal 49; valid = yes, Unicode category = Nd.
For a breakdown on what parts of the error message means, see the Convert string to UTF-8 and check against Unicode allowlist expression.
Received by client
This is applied to all text messages, sent or blasted, to a client, whether it is from another client or by the server itself, direct or via a channel.
This restriction is applied in all channel/server/peer message request handling modes.
If a message fails the allowlist, it will be dropped with an server-side error message.
For example, if the "received by client" allowlist is letters and symbols only, and the message is "First ~15 chars aren't a whole lot":
Dropped channel text message "First ~15 chars…" from client Alice (ID 0) -> channel Bob (ID 1), invalid char U+0031 '1' rejected.
Dropped peer text message "First ~15 chars…" from client Alice (ID 0) -> client Bob (ID 1), invalid char U+0031 '1' rejected.
The first 15 characters (more accurately, first 15 UTF-8 code units) of the text message will be output, not the entirety, so that error messages are not huge.
Received by server
This is applied to all text messages, sent or blasted, to the server directly.
This restriction is applied only when server messages will be listened to by Fusion events.
If a message fails the allowlist, it will be dropped, with an server-side error message, and the client will be marked as untrustworthy and disconnected.
The client is marked as untrustworthy as they are attempting to communicate with the server in a disallowed method. Clients that aren't trusted are disconnected instantly, with any pending received/sent messages discarded.
For example, the error if the "received by server" allowlist is letters and symbols only, and the message is "First ~15 chars aren't a whole lot":
Dropped server text message "First ~15 chars…" from client Alice (ID 0), invalid char U+0031 '1' rejected. Client is no longer trusted.
The first 15 characters (more accurately, first 15 UTF-8 code units) of the text message will be output, not the entirety, so that error messages are not huge.