Skip to content

User moderation (kicking and banning)

SmartFoxServer 3 offers a number of tools to manage your chat and game Rooms so that higher privilege clients can deal with pesky users. If you're not familiar with how privileges are assigned in SFS3, please take a look at this document first.

There are three different approaches to moderating Users and Rooms, depending on your application and use case:

  • Directly from the AdminTool: provides a global view of the server and all connected Users. From there you can select the Zone Monitor to explore each Zone and Room or the Banned Users modules to manage global banishments.

  • Server side API: can be invoked by Zone and Room Extension. Here you can integrate banning and kicking in your custom logic and create new behaviors for the specific use case.

  • Client side API: integrate user moderation directly in your client side application for Users with higher privileges.

Room level banning

New in SmartFoxServer 3 is the ability to temporarily ban a User from the current Room. When a User is banned from a specific Room it will not be able to join back until the banishment expires. This doesn't preclude from joining other Rooms, if available.

Room level banning is intended for short periods of time (typically in the range of several minutes or hours).

To do so you will need special permissions, such as being the:

  • Room's owner
  • Zone moderator (mod)
  • Zone administrator (admin)
  • Server administrator

Let's take a look at the BanUsersFromRoomRequest from the C# client API:

// Select users to ban from the current Room
var theRoom = sfs.LastJoinedRoom;

var kermit = theRoom.GetUserByName("Kermit");
var gonzo = theRoom.GetUserByName("Gonzo");
var banList = new List<User> {kermit, gonzo};

// Send request
var req = new BanUsersFromRoomRequest(banList, theRoom, "Sayonara", 30, TimeUnit.MINUTES);
sfs.send(req);

Here we select the Users we intend to ban from the current Room and proceed with sending the BanUsersFromRoom request to the server. Provided we have the right permissions, the target Users will receive the message as SFSEvent.MODERATOR_MESSAGE event, then they will be kicked out of the Room and won't be able to join back for the specified amount of time (30 mins in this case).

There's also an UnbanUsersFromRoom request in case we want to lift the ban earlier.

NOTE:

Room level banning is short-lived and non-persistent, meaning that you can only remove Users for a short period of time (minutes or hours) and restarting the server will reset the state of the banishments.

Zone level kicking / banning

While the previous method works for single Rooms, you can also kick or ban a User from a Zone (i.e. the entire application). This is a more effective system that prevents pesky Users from joining back in the application itself.

Differences between kicking and banning:

  • kicking: disconnects the User, optionally sending a message to provide a reason/warning to the offending party
  • banning: works like kicking plus it prevents the User from logging back in the Zone for an amount of time

Also Zone level bans are persistent, so the ban states are preserved across server restarts.

Let's take a look at a ban request from client side:

// Select user to ban from the Zone
var theRoom = sfs.LastJoinedRoom;   
var kermit = theRoom.GetUserByName("Kermit");

// Send request
int delaySecs = 5;
int durationHrs = 48;

var req = new BanUserRequest(kermit.Id, "Sayonara!", BanMode.BY_NAME, delaySecs, durationHrs);
sfs.send(req);

When banning a User we provide the target's id, a warning message, a BanMode, a delay value (seconds) for kicking the User, and a duration of the ban in hours.

BanMode has two options:

  • BY_NAME: (recommended) bans the User by name, which is a unique identifier in the Zone
  • BY_ADDRESS: bans the User by its IP address. This is less effective since clients can change IP on subsequent connections. This modality can still be useful if you often see bad behaviors behind a specific address.

The reason why we recommend the BY_NAME option is that most games/applications require a credential check upon logging in the Zone and as such it's easy to keep bad Users away via banishment.

NOTE:

With this modality User bans can be set for very long stretches of time, if necessary.

Fighting sock puppets and spammers

A common issue with bad actors is that banning won't prevent them from trying to create multiple other accounts to access the server anyway and continue with their spamming, harassing etc.

This is not something SmartFoxServer can tackle out of the box as it depends on many factors such as the nature of the game, the modality in which players sign up and interact together, etc.

Fighting multiple sign-ups (automated or not) can require multiple approaches:

  • Validate user emails: not just for correctness but also for reliability. There are countless throwaway email services that can be used for creating spam accounts. Disallowing temp emails is not an easy task but there are services that can provide updated black lists or directly validate email addresses via a remote API.

  • Human verification: we recommend always integrating some kind of captcha or human verification system in your sign-up phase to keep away bots and automated scripts. The ideal systems should have the user interact with the page, such as dragging images around to compose a specific picture, or choosing among a group of items the one that doesn't belong etc. Well known solutions are:

    • Cloudflare Turnstile
    • Google reCaptcha
    • hCaptcha
    • FunCaptcha

  • Ban ip addresses: if there's a consistent pattern of bad behavior coming from specific IP addresses, you can take the more radical step of denying them any form of access. SmartFoxServer 3 provides a black list of IP addresses that can be populated as you discover who these bad actors are. Take a look at this document for more details.

Further readings: