Chat filter
From EsWiki
ElectroServer provides flexible support for flooding and language filters. Filters are used to help automatically restrict abuse in your applications. The language filters can be used to whitelist or blacklist word usage. The flooding filters can be used to restrict the rapid firing of messages or too many duplicate messages.
This tutorial explains how to take advantage of the default filters.
Contents |
Default Filters
DefaultExclusiveFilter
When ES4 is installed, the default language filter is DefaultExclusiveFilter, which can be used to prevent chat from using words in the fullWordList and also does a root word check against the words in the rootList. A root word check strips the chat message of all non-alphabetic characters (including blanks) and capitalizations, then checks for each word from the rootList appearing anywhere in the string. Root word checks are much slower than the normal filtering, so the number of words in rootList needs to be kept short.
For most purposes, DefaultExclusiveFilter is exactly what you want: a black list filter. You can add more words using the web admin (see below). To enable this filter in a chat room, you will have to set the room to use it when the room is created (see below).
DefaultInclusiveFilter
The other language filter already available with ES4 is the DefaultInclusiveFilter which is a white list filter. When this is used, chat messages that contain any words not on the word list for the filter will fail. This requires a very long word list, which would need to be entered either via the web admin or by an SQL script. Because a white word list needs to be extensive, filtering will be slower. Many applications for children opt for using canned chat instead, where users choose from a fixed set of chat messages instead of typing in their own chat.
DefaultFloodingFilter
Another problem that often occurs in chat rooms is flooding: a user will send far too many messages in a short period of time, annoying everybody else in the room. ES4's DefaultFloodingFilter checks for both too many duplicate messages and also too many messages in a short time (possibly not duplicates). To enable this filter in a chat room, you will have to set the room to use it when the room is created (see below).
Web admin
To make changes to the ES4's filters, use the web admin's Filters tab. Here you can add words to fullWordList and rootList or remove them, and modify the settings of the flooding filters. You can create new filters and word lists as well, but for this tutorial we will assume you just use the default filters. See Word lists for more information on customizing fullWordList and rootList.
Also on the web admin you can change what the default language filter is, and what action should be taken if a chat message fails the filter. See Filters for more information on the options.
Client created rooms
When a client sends a CreateRoomRequest, if that room should use the default language filter, simply add this line to the request before it is sent:
crr.setIsUsingLanguageFilter(true);
Similarly, if the room should use the default flooding filter, add this line:
crr.setIsUsingFloodingFilter(true);
If you are using the default filters as set in the web admin, you don't need to specify the name of the filters to be used, which is good because if a typo is made in the name of the filter, the room will use no filter at all.
Plugin created rooms
Rooms are also created by plugins. In this case, before the RoomConfiguration is used, if the default language filter is needed add this line:
roomConfig.setUsingLanguageFilter(true);
Similarly, if the room should use the default flooding filter:
roomConfig.setUsingFloodingFilter(true);
For game plugins that use Game Manager, this will be done in the GMSInitializer class.
Room Plugins and userSendPublicMessage
The problem with setting the chat filtering in CreateRoomRequest from the client is that if a user hacks the client the room can be created without chat filtering at all. If a chat room requires a room plugin of some kind, then this security hole can be fixed easily by having the plugin implement RoomUserEvents (or extend BasePlugin) and then override the userSendPublicMessage method. If this is done, then the client doesn't need to specify that filtering is needed in the room. For example:
@Override
public ChainAction userSendPublicMessage(UserPublicMessageContext message) {
String chatLine = message.getMessage();
LanguageFilterResponse lfr = getApi().applyLanguageFilterToString("DefaultExclusiveFilter",
chatLine);
if (lfr.isStringValid()) {
return ChainAction.OkAndContinue;
} else {
return ChainAction.Fail;
}
}
Note that this does not apply flooding filters. If there is a concern about hackers and flooding filters, then the best solution is to make all chat rooms GameManager games, which has the advantage of allowing clients to use a QuickJoinGameRequest to create or join a chat room as well as CreateGameRequest for starting a new chat room. Much simpler on the client than specifying everything about the room, hacking is prevented, and it's easy to add any needed plugins at the same time, such as a chat logger.
PluginRequest filtering
Plugins will sometimes need to filter other strings, such as when a user is allowed to specify the text to appear on the GUI for all users in the room. In this case, have the client send a PluginRequest with the text to be used, then the plugin can use getApi().applyLanguageFilterToString to filter it, as shown above. If the text is approved, the plugin can broadcast the change or set the RoomVariable or whatever else is needed.
This technique can also be used by a server level plugin to handle private messages if these need to be filtered. Instead of clients sending a PrivateMessageRequest and listening for a PrivateMessageEvent, the client would send a PluginRequest to the server level plugin, and it would filter the message and send a plugin message to the other user.
