Changes to block bot attacks

[SrBedrock]

Is your feature request related to a problem? Please describe.

Every time I get a bot attack my anti-bot system blocks the bot's entry but FastLogin performs the check anyway

Describe the solution you'd like

I believe that the implementation of these changes would solve my problem:
https://spigotmc.org/threads/formal-petition-to-all-bungeecord-plugin-developers.393041

Describe alternatives you've considered

We have two options:

1. Adding the following code when you trigger an event:

if (event.isCancelled()) {
    return;
}

With this code, you will be cancelling your plugin checks, if an AntiBot plugin has kicked the player. This way, bot-attacks won't crash the server due to your bungeecord plugin.

2. Moving checks to the LoginEvent instead of the PreLoginEvent

Additional context

Log of the Bots that are trying to access my server but blocked by the anti-bot system:

[03:12:41] [FastLogin Pool Thread #1/INFO] [FastLogin]: Handling player hujxy5148
[03:12:41] [Netty Worker IO Thread #27/INFO] [FastLogin]: Incoming login request for Warc0s_Gamer from /138.204.106.71:50637
[03:12:41] [FastLogin Pool Thread #2/INFO] [FastLogin]: Handling player Warc0s_Gamer
[03:12:45] [Netty Worker IO Thread #0/INFO] [FastLogin]: Incoming login request for EiMath from /187.21.192.231:55449
[03:12:45] [FastLogin Pool Thread #0/INFO] [FastLogin]: Handling player EiMath
[03:13:01] [Netty Worker IO Thread #1/INFO] [FastLogin]: Incoming login request for xtron56 from /181.213.58.29:52005
[03:13:01] [FastLogin Pool Thread #3/INFO] [FastLogin]: Handling player xtron56
[03:13:05] [BotSentry Pool Thread #9/INFO]: BotSentry » 669 Bad packets prevented (last second)
[03:13:28] [Netty Worker IO Thread #25/INFO] [FastLogin]: Incoming login request for gnmuv5694 from /213.81.178.185:52231
[03:13:28] [FastLogin Pool Thread #4/INFO] [FastLogin]: Handling player gnmuv5694
[03:13:29] [Netty Worker IO Thread #23/INFO] [FastLogin]: Incoming login request for lufue9246 from /185.220.101.134:20640
[03:13:29] [FastLogin Pool Thread #5/INFO] [FastLogin]: Handling player lufue9246
[03:13:30] [Netty Worker IO Thread #22/INFO] [FastLogin]: Incoming login request for qfvlb2121 from /185.220.101.134:11774
[03:13:30] [FastLogin Pool Thread #3/INFO] [FastLogin]: Handling player qfvlb2121
[03:13:37] [Netty Worker IO Thread #26/INFO] [FastLogin]: Incoming login request for vdnxs8577 from /213.81.178.185:52393
[03:13:37] [FastLogin Pool Thread #4/INFO] [FastLogin]: Handling player vdnxs8577
[03:13:39] [Netty Worker IO Thread #0/INFO] [FastLogin]: Incoming login request for nwwyk3727 from /213.81.178.185:52436
[03:13:39] [FastLogin Pool Thread #5/INFO] [FastLogin]: Handling player nwwyk3727

[games647]

Funny thing. I had this discussion multiple times and people don't seem to understand the origin of this problem.

Adding the following code when you trigger an event:
if (event.isCancelled()) {
return;
}
With this code, you will be cancelling your plugin checks, if an AntiBot plugin has kicked the player. This way, bot-attacks won't crash the server due to your bungeecord plugin.

FastLogin already has this check. See this:

FastLogin/bungee/src/main/java/com/github/games647/fastlogin/bungee/listener/ConnectListener.java

Line 112 in 7192dcd

if (preLoginEvent.isCancelled() || isBedrockPlayer(connection.getUniqueId())) {

Moving checks to the LoginEvent instead of the PreLoginEvent

FastLogin has to do the check on the PreLogin event, because this is where the onlinemode decision is made.

https://github.com/SpigotMC/BungeeCord/blob/830ee8f27d47400d17915bf546fc85540dbe5180/proxy/src/main/java/net/md_5/bungee/connection/InitialHandler.java#L384-409

Source of this issue:

#304, #471, etc.

TL;DR If your anti-bot plugin peforms the check asynchronous, then the event listener of other plugins including FastLogin will fire while the check is performed. Try to think about a parallel program flows. At this time the event isn't cancelled, because the check is still performed (like a HTTP api check). This means the isCancelled check won't work. The result isn't there yet.

Solutions:

Often also suggested in other threads:

1. Make the anti bot plugin event synchronous. This can be a bad practice, because as far as I know this could block the worker thread of Bungee. (needs more investigation)
2. Listen the ConnectionInitEvent of Waterfall if available. It fires even before. However this could not be very feasible depending on your target platform

FastLogin specific

1. FastLogin has a rate limiter in newer versions. It simply counts the number of requests in certain time. You can adjust it in the config.
2. FastLogin offers events. You can cancel them. Then FastLogin will only load the profile from database, but stops after
3. We offered multiple times that we would also use the API of anti bot plugins if available. However two things have to be required for this open source project. The API of the plugin has free and the license should allow the open source usage available. Therefore paid plugins should split the project into API and rest. A contributor of FastLogin should not be required to buy or request access to the plugin. This would slow the process of new contributors. However the plugins I found didn't address this issue. I'm happy if someone suggests one that works.

Side-Note

Please use the search functionality first. The issue came up multiple times and all should be linked together.

[games647]

Sorry if I sounded a bit harsh. I don't know if you have any technical knowledge about this situation. Basically the source is the parallel program flow. FastLogin can't see the result of the AntiBot plugin if the check is still performed.

If you or any other have any questions, feel free to ask. Maybe I could describe it in a non-technical way.

[games647]

Taking the OP of your linked post. There is still no public available API of BotSentry to check for the result. At least not on the project page.

[SrBedrock]

Sorry if I sounded a bit harsh. I don't know if you have any technical knowledge about this situation. Basically the source is the parallel program flow. FastLogin can't see the result of the AntiBot plugin if the check is still performed.

If you or any other have any questions, feel free to ask. Maybe I could describe it in a non-technical way.

Despite not having technical knowledge, I fully understand the reason after your explanation, thanks for your patience.

Taking the OP of your linked post. There is still no public available API of BotSentry to check for the result. At least not on the project page.

I will show him this discussion and maybe it can be solved through the botsentry plugin

[Laurenshup]

Hello,

I am the developer of BotSentry and I have read through this issue.
This issue should be redirected to us rather than @games647.

This is the second time we have noticed problems with FastLogin.
The first time was a problem with FastLogin in Spigot (and forks) systems.
We have fixed that by using the FastLogin API.

This issue will also be fixed by using the FastLogin API for our BungeeCord (and forks) system.

Also, we do have a public API.
You can find it at: https://cyberdevelopment.es/BotSentry/javadocs

More information about the problem or a better solution can be reported at:
BlackDemonZyT/BotSentry#21

[games647]

@Laurenshup Ok sorry I missed it, my fault; I only took peak look and tried to use search. However there are a few things that should be addressed. There seems to be no way to query the result of a currently connecting player (Event or Method like CompletableFuture). Blocking the current thread until the result is there. Or is BlockSentryList for this use case. According to the API it could make an extra request in the background. At least it's unclear. Could you please clarify this. Another idea is to post some example scenario or queries.

This is the second time we have noticed problems with FastLogin.
The first time was a problem with FastLogin in Spigot (and forks) systems.
We have fixed that by using the FastLogin API.

Thank for looking into it and integrating support into your plugin.

[Laurenshup]

@games647 Since we are an AntiBot we have to make sure the server can handle everything. That is also why we are currently having no event related to connecting. If needed, I can try to implement it in any way that is possible.
BotSentryList is fully asynchronously, to make sure BotSentry's threads are not blocked.

If any new feature is needed into the API, I will be happy to add it to the newest version.

As stated before, BotSentry is already integrated with FastLogin in Spigot. I do not see the need of FastLogin also integrating into BotSentry.
BotSentry already cancels the PreLoginEvent with the lowest priority (runs first) in BungeeCord, any other reason why FastLogin would still execute their code?

[games647]

That is also why we are currently having no event related to connecting. If needed, I can try to implement it in any way that is possible.

Because of the event overhead? Then you could create a custom event with a simple java interface listener this way there no really overhead.

BotSentryList is fully asynchronously, to make sure BotSentry's threads are not blocked.

Yes I noticed that, but does it make a new request while you are making a check at the same time? It indicates that you would make another request.

BotSentry already cancels the PreLoginEvent with the lowest priority (runs first) in BungeeCord, any other reason why FastLogin would still execute their code?

Just giving feedback at this point. In case for other plugins.

[Laurenshup]

Yes I noticed that, but does it make a new request while you are making a check at the same time? It indicates that you would make another request.
Yes it does make another request.

[games647]

@Laurenshup This is likely not the best solution or at least your API still has no way for plugins to check the check result during login.

I'm closing it in favor of the mentioned ticket.