Filters
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. See also Chat filter
Contents |
Language Filter
ElectroServer supports multiple named language filters and word lists. Language filters and word lists are created and managed in the web-based administrator. A default language filter exists with default actions to take when filtering is applied.
Any language filter can be applied to the following:
- Usernames, during the login process
- Zone and room names, during room creation
- Public messaging, when a message is sent to a room
- Private messaging, when a private message is sent to one or more users
A language filter is identified by its name and can be configured in the following ways:
- Language filter name
- Word list – A list of words to use as either a white list or black list. Words in this list must appear exactly as they are in the list for an action to be taken.
- Root word list – A list of words to use as a white list or black list. Words in this list can appear anywhere for an action to be taken. For instance, the “f-word" contains four characters that should never appear naturally anywhere.
- Language filter type
- Exclusive – If this type is chosen, then the word lists are used as black lists. That means that if a match is detected between what is being filtered and one of the words, then an action is taken.
- Inclusive – If this type is chosen, then the word lists are used as white lists. That means that if a word is found in the filtered string that is not in these lists, then an action is taken.
- Strip HTML – If this is enabled, then HTML is first stripped from the string to be filtered.
- Strip Punctuation – If this is enabled, then punctuation is first stripped from the string to be filtered.
Filter Match During Public Message
The following actions are defined by default in the web-based administrator. These only apply to public message filter matches and can be overridden during the room creation process.
- Deliver on failure – If set to yes, then a message that fails the language filter check is still delivered. If set to no, and a failure is detected, the message is suppressed.
- Failures before kick – This is the number of language filter matches that can occur before the user is kicked. When a user is kicked, he is just removed from the room but not the server.
- Kicks before ban – This is the number of times the user can be kicked before he is disconnected from the server and banned from returning.
- Ban duration – This is the amount of time (in seconds) the user is banned.
- Resets after kick – If this is set to yes, then every time the user is kicked, it resets the process as if the user has never been kicked.
Filter Match During Login
If the filter finds a match during login, then the user receives a login response informing them that their login attempt was unsuccessful and told that their user name failed the language filter check.
Filter Match During Room Creation
If the filter finds a match during the creation of a room, then the room fails to create. The user is informed that the language filter identified text that is not allowed.
Filter Match During Private Message
If the filter finds a match during the sending of a private message, then the user is informed of the language filter match. If the Deliver on failure option is set to true, then the filtered message is delivered anyway. If set to false, any message that is caught by the language filter is suppressed.
Flooding Filter
Often times users of a chat will cause disruption by using profanity or by sending a high density of messages to the room to hijack the chat window. Through the use of language filters (described in the Language Filters section above) and flooding filters, common abuse behaviors can be suppressed and handled.
ElectroServer allows the creation of custom named flooding filters through the web-based administrator. When creating a flooding filter, certain parameters can be created to detect flooding. The flooding filter of choice is applied to a room during the room creation process. The action to take (such as kicking the user) is also established upon room creation.
Filter Parameters
- Filter name
- The unique name referenced when applying a filter to a room.
- Maximum duplicate messages
- The maximum number of allowed identical messages sent consecutively to the server.
- Sliding window duration
- The amount of time (in milliseconds) used when considering if a group of messages is flooding. This is used in conjunction with the parameter for maximum messages in a window.
- Maximum messages in a window
- The number of messages allowed during the given interval. This is best explained by example. Consider that the sliding window duration is set to 1000ms and maximum messages in a window is set to five. If a user ever sends five messages or more within a 1000ms duration, then it will be considered flooding.
Assigning a Flooding Filter to a Room
When creating a room via web-based administrator or from a client, a flooding filter can be optionally selected. If a flooding filter will be used, then the following parameters must be specified:
- Flooding filter name (string) – A unique name that identifies a previously created flooding filter.
- Deliver on failure (boolean) – If true and a failure (flood) is detected, the message is delivered. If false, and a failure is detected, the message is suppressed.
- Failures before kick (integer) – The total number of failures allowed by a user before that user is kicked.
- Kicks before ban (integer) – The total number of times to kick a user before that user is banned.
- Ban duration (integer) – The amount of time in seconds to ban the user. If set to -1, then the user is banned until a server reboot.
- Reset after kick (boolean) – If set to true, then the user’s offenses are erased and reset after kicked, so the user would never get banned automatically. If set to false then number of times the user has been kicked is stored may eventually lead to a ban (depending on the ban settings).
