Make Players:BanAsync() callable from plugin

Feature Requests Engine Features
,
1

As a Roblox developer, it is currently too hard to create plugins that ban players. The API Players:BanAsync() is only callable from the server and will throw error if called from Edit context (see this for example)

I even tested to do some jujitsu to call the API from an Plugin but under Server context (instead of Edit) in Roblox Studio, but then I was met with the following instead:

BanAsync will succeed on production game servers. Skipping request in test environment…

Why this would be nice:

We usually build plugins to manage different aspects of the games we build, one of those plugins I am working on is to clean up cheaters by:

  1. Removing them from all leaderboards in the game
  2. Banning them (and this is where I hit the roadblock)

Potential workarounds:

  1. Call the Ban OpenCloud API, but that feels unnecessarily complex when there is a Luau API already.
  2. Build some kind of in-game admin panel that developers can access in production - guess this can be done but does not follow how we usually do it, also can choke the different quotas and limits if we start to build bulk operation tooling.
5 Likes
2

Call the Ban OpenCloud API, but that feels unnecessarily complex when there is a Luau API already.

This workaround did not work for two reasons:

  1. HttpService:GetSecret() fails to find the Local Secret when running in edit mode.
  2. The user-restrictions OpenCloud Endpoint is not available from a Roblox game without going through a proxy.
3

really would like support for Players:BanAsync() from plugins.

Have my own plugin and would make moderation way easier as I list all my macros in my plugin.

4

Hell no this will be abused

2 Likes
5

Obviously you can’t just grant all plugins permission to use the ban api.

Right now you get noticed beforehand if a plugin tries to access anything http related.

Some sort of similar system could be implemented for accessing the ban api, I’m sure there is loads of ways of doing this.

6

this is a good idea!
making moderation plugins that you can use to manage your game while in studio would be nice.

a example i would probably think of for this is for admin panels
it wouldnt exactly be ideal to put it ingame for a global event.
it would be more trouble to put it on a web page.
so where can you put it?
in your studio.

7

i mean roblox can make a confirmation window when a plugin tries to ban

8

A confirmation window seems unnecessary - you can delete the datastore from a plugin which is a way more destructive action without anything. It is up to the plugin developer to handle that I would say.

9

Why? Plugins can access the datastore without any special permissions, and deleting the datastore is way harder to recover from than a bunch of incorrect bans.

10

I can see bad actors abusing this. Back when ModuleScripts could be private and require()ed in game, people would create their own ban list there, banning people they didn’t like from games using their tech…

I just feel like this is going to be the same story all over- Plugins maker banning people they dont like from games using their plugins

A confirmation as @justadude180812 said MUST be required as to avoid any abuses. The Ban API is subject to Roblox’s Community Guidelines, so plugins having free reign on bans could easily get creators banned

11

You can still easily build a plugin today that bans someone you dislike without the developer using the plugin understanding why (e.g. inject a server script somewhere deep in the workspace / ServerScriptService hierarchy) - restricting the API will not do any big difference here.

12

Sure you can do that and your plugin will get flagged and disliked, nobody will be using it.

I’m just approaching this feature with safety in mind.. how would a confirmation even hurt this? It’s extra safety at no additional cost (except maybe one click?)

13

Sure you can do that and your plugin will get flagged and disliked, nobody will be using it.

This applies when you use BanAsync too I would assume.

A confirmation would basically ruin my use case since I would use it to batch ban people.

14

And since the api natively support batches (through the userIds parameter), the confirmation could be a single prompt like “The plugin XXXX is trying to ban these people” then there’s the list avatar? | userId | name | reason (similar to the prompt asking you to grant asset permissions before publishing) with “Confirm” and “Cancel” at the bottom