LuckPerms

LuckPerms

41.4k Downloads

Suggestion: Replacing LoginEvent with PostLoginEvent

BestMark opened this issue · 18 comments

commented

Hello,

Could you rewrite LuckPermsBungee using PostLoginEvent instead of LoginEvent? I have BungeeCord with anti-bot protection (captcha).
When someone launches an attack on my server, a lot of bots join it at one moment, and LuckPerms does not allow other players to log in to the server.
I understand that there may be incompatibility with some plugins because of this. But how else can you deal with a bot attack? Pay the one who attacks?

commented

If your anti-bot plugin cancels the connection at a low priority on the LoginEvent, LP will not attempt to handle the connection.

It's not possible for LP to use the PostLoginEvent because it is not async.

commented

It is not LPs job to look for other plugins that cancel a connection.
Your anti-bot should cancel the connection before LP handles it, as luck said, which is done by having a higher priority set.
From what I understand can (and should) such plugins cancel connections on the PreLoginEvent which (obviously) happens before the LoginEvent.
Again: Not LPs job here. Tell the dev of the other plugin to increase the priority, or to switch to the PreLoginEvent if possible.

commented

I do not use any plugins, captcha is built into the BungeeCord. It is impossible to do strong anti-bot protection using PreLoginEvent.

commented

Captcha is entered after entering the server, not before

commented

Plugins expect permissions data to be loaded by the time the player is entering the server - it's too late to only be loading it then, and besides, it's not an async event so cannot be done then anyway.

The LoginEvent is absolutely the correct event for LuckPerms to be listening to.

It is impossible to do strong anti-bot protection using PreLoginEvent

I disagree - there's plenty of information available during the PreLoginEvent to decide whether a connection should be allowed.

And if you want to wait until after authentication with Mojang, just listen to the LoginEvent, but do any cancellation before LP handles the event at LOW priority (i.e. listen on LOWEST).

commented

@lucko It is impossible to call PreLoginEvent after passing the captcha, because the player enters the captcha when he is already on the server. Again, this is the only way to protect yourself from smart bots. It is too late to call this event at that moment.
image

commented

Get a better anti-bot then
A Anti-bot plugin should deny the login before it even happens. The system you have right now doesn't, as it requires the player/bot to be actually on the server, which is already too late.
Again: This has nothing to do with LP, as LP does its job as expected and it is that anti-bot plugin being bad.

commented

It is impossible to block bots on PreLoginEvent.
All Russian servers use captcha to protect server from bots. There is no other way to block them.
For example, https://github.com/Leymooo/BungeeCord
You can block them at the connection setup, but this option is only suitable for dumb bots.
If you are an administrator of a server with 20 players online, you don't need to be afraid of bot attacks, but in my case, when there are more than 1500 players (online-mode=false) playing on my server, I need good protection.
image

commented

Do me a favour and stop claiming stuff that isn't true.
I in fact know a dev of a anti-bot plugin which can block bots on Pre-Login.
Your claim about this being "impossible" is as wrong as the Pin-system you use, as this doesn't block bots at all from joining. The damage is already done when they joined as plugins like Essentials will create files for the user on first join.

There aren't any "smart" bots. Only Bots, which - again - can be blocked using a suffisticated anti-bot plugin (or system for that matter).
Your claim that this is impossible to do on PreLogin is wrong. Luck already mentioned that the PreLogin has enough information to have a proper way to find and block bots before they join your server.
You ask Luck to change LP in a way to be worse in how to handle permissions for users.

But we should really stop this now as I can see that you really can't be bothered to look any further than what you yourself believe.

Btw. Sorry Luck for the spam here.

commented

The captcha is built into BungeeCord, it does not require a backend (ex. Spigot) server.
Where did you find the Essentials for BungeeCord? о_О

commented

Most servers use a captcha (see for yourself: http://monitoringminecraft.ru/), so I think it's important to redo your plugin to make it compatible with this.

commented

The only information that is available in PreLoginEvent is client version, username, hostname, ip address and maybe some other handshake data that i can't remember now but that doesn't matter. How you are supposed to know from this very limited and easily spoofable information is this a bot connection or not? We are not talking about simple rate limiters that are easily bypassed by cheap proxies, right? There's no damage from just logging in to special captcha server that is running inside bungee itself that is specifically designed to be able withstand more than 10000 simultaneous connections
Either you guys never experienced really serious bot attack, you know, when there's thousands IPs from different countries, bots uses random usernames that looks like real and can automatically register on the server, or you really don't understand what you say.

commented

It isn't.
It's not LPs job to listen for other plugins. The plugin you use does need to change its Listener Priority to fix this.
And the player stull joins, no matter what as they need a way to get the map displayed, as you've shown before. This won't work for the player without joining to the server first, which at the end will cause issues.

And I in fact never experienced this, as I use one of the best Anti-Bot systems out there: Mojangs Auth-System,
From what I can tell are you running a cracked (offline) Network, which comes with problems like the one you have.

You're the only one complaining about this issue which needs to be fixed on the side of that captcha plugin and not LP.

AGAIN: LuckPerms is not responsible for listening to other plugins or to switch to a different, much worse, system for handling player data.
It is open source after all, so you can fork it and make the changes you want. Luck gave his statement and won't change this just for a single case, that isn't even LPs fault.

I'm now done here, as this clearly is not something that should be discussed any further.

commented

It is not single case, all servers use captcha, see for yourself: http://monitoringminecraft.ru/

commented

AGAIN: It is not plugin for Bungee.

commented

Alright I see what you mean about the captcha.

Unfortunately this breaks the design of BungeeCord somewhat - my suggestion would be that your fork of BungeeCord should hold off from calling the LoginEvent until after the captcha has been completed, and then call the event for normal BungeeCord plugins afterwards.

I don't think this is really something LuckPerms (or plugins similar to LuckPerms) should be expected to work around.

commented

Also keep in mind that moving the data load to the PostLoginEvent would not only lag servers it would also break plugins that expect permissions to be loaded during the LoginEvent. The only somewhat reasonable way to handle things would be by not storing new player data until for example the PostLoginEvent. Though I doubt the effort would be worth the niche use, especially considering security vulnerabilities like the one you describe are easily fixed by using the Mojang authentification servers, which in turn is easily achieved by turning on a single setting.

commented

Could you say what else should I change in LuckPermsBungee if I want to replace the LoginEvent with PostLoginAsync?