search

jonesdevelopment / sonar

Sonar is a lightweight, effective and easy-to-use anti-bot plugin for Velocity, BungeeCord, and Bukkit.
https://docs.jonesdev.xyz
GNU General Public License v3.0
126 stars 10 forks source link

Feature Request: Is it possible to not kick players? #262

Closed Test-Account666 closed 6 months ago

Test-Account666 commented 6 months ago

Hey!

I'd love to know, if it is possible to not kick a player after successful checks.

Also, your Discord URL doesn't seem to work anymore

jonesdevelopment commented 6 months ago

I'd love to know, if it is possible to not kick a player after successful checks.

Sadly, this is not possible with Sonar. This exact issue is also present in other anti-bot plugins. You can read more about it on the Discord.

Also, your Discord URL doesn't seem to work anymore

Huh? I didn't know, thanks for mentioning it. (Edit: Resolved. It was a cloudflare issue. You can join through https://jonesdev.xyz/discord)

jonesdevelopment commented 6 months ago

I will close this issue as resolved. If you need more information about this, please join the Discord server.

Link to the community post regarding this: https://discord.com/channels/923308209769426994/1177305423930462248

AndrobaL commented 5 months ago

I'd love to know, if it is possible to not kick a player after successful checks.

Sadly, this is not possible with Sonar. This exact issue is also present in other anti-bot plugins. You can read more about it on the Discord.

Also, your Discord URL doesn't seem to work anymore

Huh? I didn't know, thanks for mentioning it. (Edit: Resolved. It was a cloudflare issue. You can join through https://jonesdev.xyz/discord)

Hello can you explain why its not possible ?

FallenCrystal commented 5 months ago

Hello can you explain why its not possible ?

AndrobaL commented 5 months ago

I see, but instead of kicking the player, can't we just emulate the player's connection as if sonar hadn't been there? Once verification has been completed, the plugin uses the UserVerifySuccessEvent to connect the player as by default

jonesdevelopment commented 5 months ago

I see, but instead of kicking the player, can't we just emulate the player's connection as if sonar hadn't been there? Once verification has been completed, the plugin uses the UserVerifySuccessEvent to connect the player as by default

I really don't want to dig up this again. If you want to read more about this (with some more technical explanation), please join the Discord server and take a look at this thread.

TL;DR Sonar injects into the pipeline, removes the servers pipeline and does some shenanigans. Sonar is explicitly made to not let the server know that the player has connected. Any other workaround will

  1. break compatibility with literally any plugin trying to do something with packets or the login process,
  2. make the server vulnerable to security issues, especially if it's a premium server.

Conclusion: It's not worth it. I wouldn't even implement an ugly hack/workaround even if I was paid thousands for it. It just breaks too much and takes too much time to implement.

andreasdc commented 5 months ago

I see, but instead of kicking the player, can't we just emulate the player's connection as if sonar hadn't been there? Once verification has been completed, the plugin uses the UserVerifySuccessEvent to connect the player as by default

I really don't want to dig up this again. If you want to read more about this (with some more technical explanation), please join the Discord server and take a look at this thread.

TL;DR Sonar injects into the pipeline, removes the servers pipeline and does some shenanigans. Sonar is explicitly made to not let the server know that the player has connected. Any other workaround will

  1. break compatibility with literally any plugin trying to do something with packets or the login process,
  2. make the server vulnerable to security issues, especially if it's a premium server.

Conclusion: It's not worth it. I wouldn't even implement an ugly hack/workaround even if I was paid thousands for it. It just breaks too much and takes too much time to implement.

Hater hater, it's worth it with good approach and you won't lose anything, but you wil gain much love from Sonar's users.

jonesdevelopment commented 5 months ago

Hater hater, it's worth it with good approach and you won't lose anything, but you wil gain much love from Sonar's users.

If there was a good approach I would've implemented this a long time ago. There just isn't.

andreasdc commented 5 months ago

Hater hater, it's worth it with good approach and you won't lose anything, but you wil gain much love from Sonar's users.

If there was a good approach I would've implemented this a long time ago. There just isn't.

Even on PostLoginEvent can't be possible? They added default server to connect there last time in BungeeCord. If there's UserVerifySuccessEvent maybe we can use it too.

FallenCrystal commented 5 months ago

Even on PostLoginEvent can't be possible? They added default server to connect there last time in BungeeCord. If there's UserVerifySuccessEvent maybe we can use it too.

This event is proxy telling the plugins what server proxy is trying to transfer the player to. It's not about Sonar. I recommend that you first understand the structure of these proxies and how Sonar works. Then consider whether or not to post the comment.

And here's what you need to know. Fallback is not a backend server. It is not bound to any port. It just hijack the connection before the server processes it.

This is not an issue with a call event. And I kind of want to lock (conversation) for this issue. This comment already explains it.

andreasdc commented 5 months ago

Everything can be done, we talk about the biggest and the most wanted feature. I have similar approach already done, I just suggest what can be added.

FallenCrystal commented 5 months ago

Everything can be done, we talk about the biggest and the most wanted feature. I have similar approach already done, I just suggest what can be added.

??? I don't think it's clear to you that the issue at the moment isn't what servers connecting to.

Edit: All current antibots that use virtual servers to check players and support this feature (e.x. BotFilter) will break compatibility to some extent. (Or sacrifice something else. e.x. authenticate ahead of time regardless of possible rate limits.) Don't want to spend a lot of experience implementing this shaky feature. The best solution is to use the latest stable releases of the Minecraft client. And enable the transfer feature in Sonar.

I'm going to give up on continuing to follow this issue. All the information on why it's not worth implementing is already here. It makes no sense to continue answering.

andreasdc commented 5 months ago

Everything can be done, we talk about the biggest and the most wanted feature. I have similar approach already done, I just suggest what can be added.

??? I don't think it's clear to you that the issue at the moment isn't what server Sonar is connecting to. It's that the proxy doesn't actually know with this player. (If the player needs to verify.)

You could just say 'Don't want to spend a lot of experience implementing this shaky feature.'. This is possible to implement, if not today maybe someday you will add it, I keep my fingers crossed for the project anyway and I think it would be nice feature, allowing to easily verify every player.

Test-Account666 commented 5 months ago

Everything can be done, we talk about the biggest and the most wanted feature. I have similar approach already done, I just suggest what can be added.

??? I don't think it's clear to you that the issue at the moment isn't what server Sonar is connecting to. It's that the proxy doesn't actually know with this player. (If the player needs to verify.)

You could just say 'Don't want to spend a lot of experience implementing this shaky feature.'. This is possible to implement, if not today maybe someday you will add it, I keep my fingers crossed for the project anyway and I think it would be nice feature, allowing to easily verify every player.

He never implied it is not possible.

He DID say though that it requires a lot of effort.

The proxy never processed the player correctly.

And you cannot simply tell the client to authenticate again, so re-processing is not possible

andreasdc commented 5 months ago

Everything can be done, we talk about the biggest and the most wanted feature. I have similar approach already done, I just suggest what can be added.

??? I don't think it's clear to you that the issue at the moment isn't what server Sonar is connecting to. It's that the proxy doesn't actually know with this player. (If the player needs to verify.)

You could just say 'Don't want to spend a lot of experience implementing this shaky feature.'. This is possible to implement, if not today maybe someday you will add it, I keep my fingers crossed for the project anyway and I think it would be nice feature, allowing to easily verify every player.

He never implied it is not possible.

He DID say though that it requires a lot of effort.

The proxy never processed the player correctly.

And you cannot simply tell the client to authenticate again, so re-processing is not possible

Yes, then you do it after the verification.

Test-Account666 commented 5 months ago

Everything can be done, we talk about the biggest and the most wanted feature. I have similar approach already done, I just suggest what can be added.

??? I don't think it's clear to you that the issue at the moment isn't what server Sonar is connecting to. It's that the proxy doesn't actually know with this player. (If the player needs to verify.)

You could just say 'Don't want to spend a lot of experience implementing this shaky feature.'. This is possible to implement, if not today maybe someday you will add it, I keep my fingers crossed for the project anyway and I think it would be nice feature, allowing to easily verify every player.

He never implied it is not possible. He DID say though that it requires a lot of effort. The proxy never processed the player correctly. And you cannot simply tell the client to authenticate again, so re-processing is not possible

Yes, then you do it after the verification.

No. It is impossible to tell the client to re-authenticate.

It is the same reason why BungeeCord requires all Subservers to set online-mode to false.

Jones could do some dirty tricks to tell the Proxy (Oh look, a player just came out of nowhere!), but as he already said, it takes a lot of effort and he is NOT willing to do so

andreasdc commented 5 months ago

Everything can be done, we talk about the biggest and the most wanted feature. I have similar approach already done, I just suggest what can be added.

??? I don't think it's clear to you that the issue at the moment isn't what server Sonar is connecting to. It's that the proxy doesn't actually know with this player. (If the player needs to verify.)

You could just say 'Don't want to spend a lot of experience implementing this shaky feature.'. This is possible to implement, if not today maybe someday you will add it, I keep my fingers crossed for the project anyway and I think it would be nice feature, allowing to easily verify every player.

He never implied it is not possible. He DID say though that it requires a lot of effort. The proxy never processed the player correctly. And you cannot simply tell the client to authenticate again, so re-processing is not possible

Yes, then you do it after the verification.

No. It is impossible to tell the client to re-authenticate.

It is the same reason why BungeeCord requires all Subservers to set online-mode to false.

Jones could do some dirty tricks to tell the Proxy (Oh look, a player just came out of nowhere!), but as he already said, it takes a lot of effort and he is NOT willing to do so

Yes, that's the reason you do it after the authentication. I know right now it's not a good time to implement it, but as I say maybe someday and it is a great feature.

Test-Account666 commented 5 months ago

Yes, that's the reason you do it after the authentication. I know right now it's not a good time to implement it, but as I say maybe someday and it is a great feature.

That would basically completely ruin the entire point of this plugin.

It is to save the proxy and installed plugins from processing bots.

Otherwise, the effectiveness would go to basically 0

andreasdc commented 5 months ago

Yes, that's the reason you do it after the authentication. I know right now it's not a good time to implement it, but as I say maybe someday and it is a great feature.

That would completely ruin the entire point of this plugin.

It is to save the proxy and installed plugins from processing bots.

Otherwise, the effectiveness would go to basically 0

Then you disable it during the attack.

jonesdevelopment commented 5 months ago

Then you disable it during the attack.

The world isn't as simple as "make it configurable". I am not wasting hundreds of hours for a "solution" that isn't a solution in any way, shape or form.

Yes, I said it's possible, but that does not mean it's easy, nor does it mean that I'm going to waste my time on it. You cannot ignore the downsides by simply saying "yo so let's disable it when things get tricky". It's like fixing a performance issue in a computer program by stopping the program whenever the CPU usage goes up: It doesn't solve the issue.

jonesdevelopment commented 5 months ago

In the future, please refer to https://github.com/jonesdevelopment/sonar/issues/262#issuecomment-2100216673, https://github.com/jonesdevelopment/sonar/issues/262#issuecomment-2098524716, https://github.com/jonesdevelopment/sonar/issues/262#issuecomment-2098331162, and https://discord.com/channels/923308209769426994/1177305423930462248.

I would really like to find an end to this issue. If you need anything, please contact me through Discord.