Clients with buggy supports block

[PPK]

Code:

-- Block of clients with buggy supports
-- Created for fun and to force client creators to fix bug caused by bad quack coding.

function SupportsArrival(curUser, sData)
    if string.sub(sData, string.len(sData)-1, string.len(sData)-1) == " " then
        Core.SendToUser(curUser, "<"..Core.GetHubSecAlias().."> Your client is buggy and sent bad $Supports command.")
        Core.SendToUser(curUser, "<"..Core.GetHubSecAlias().."> Please report that bug to your client creator and wait for fixed version.")
        Core.SendToUser(curUser, "<"..Core.GetHubSecAlias().."> If you don't want to wait or your client creator is not able to fix that bug then please change client.")
Core.Disconnect(curUser)
    end
end

[bastya_elvtars]

Yes, but not in a hardcoded way. Or at least not for the first time.

[CrazyGuy]

May i suggest a Core.Kick instead of a Core.Disconnect to avoid hammering ? 

[bastya_elvtars]

May i suggest a Core.Kick instead of a Core.Disconnect to avoid hammering ? 

I object; hammering will lead to autoban anyway. And kicking would disappoint the user too much IMHO.

[CrazyGuy]

I object; hammering will lead to autoban anyway. And kicking would disappoint the user too much IMHO.

i don't really see why kicking would disappoint more than an autoban for hammering

[TwîsTèd-dèvîl]

If kicking doesnt that mean user has to be in hub ... therefore defeting the object

[ruler]

i voted 'yes' but thats because i'd like to see the back of all dodgy clients 

[TTB]

Voted: Only as option with default enabled.

I don't know which clients has buggy supports. The hub-runner should manage it if needed, imo.

[Thor]

The only one client which sends corrupted $Supports string is rmDC.

[PPK]

No, it is not only one client But yes this script block rmDC++ too

[PPK]

36.8% for yes, 36.8% for option with enabled, 26.3% for option with disabled.

Who really test that script ? Why nobody complains that this script blocking DC++ and most of DC++ modifications ? Who really want to block them ?

[Mutor]

Well the poll itself has little to do with your script.
Asking if users want bad supports blocked does not
infer you want them to test your script.

I'm not sure why blocking this is even a question.
Do you allow bad client tags? Do you allow invalid MyINFO?
Did you put either of those to a vote? Not AFAIK, but
you do have an option to allow clients without tags.
So in keeping with tradition, provide it as an option.

[PPK]

Tag is optional because it is not part of protocol, it is ugly description hack by quack.

This block is question, because that bug is in most actually used clients

[CrazyGuy]

36.8% for yes, 36.8% for option with enabled, 26.3% for option with disabled.

Who really test that script ? Why nobody complains that this script blocking DC++ and most of DC++ modifications ? Who really want to block them ?

I haven't tested that script, but I can see pretty clearly what it does 
As Mutor said, the question asked in the poll is taken as stand-alone.

I would encourage such a block as default if it wasn't that it would mean so many current clients will not be allowed in because of it 
Therefor I'm sticking with my vote of making it optional

[PPK]

Voting locked, will be implemented in next PtokaX version as option with default enabled 

[CrazyGuy]

good 

[ATAG]

Voting locked, will be implemented in next PtokaX version as option with default enabled 

How can i disable it? 

[Mutor]

There will be an option for you to toggle once it's implemented.

First the horse, then the cart.   

[ATAG]

Then what is "Bad $Supports from <unknown> (xxx.xxx.xxx.xxx) - user closed." in the log?

[Mutor]

Just what it seems. AFAIK, there is no option to enable/disable yet.
Correct me if I'm wrong. I can take it. 

[PPK]

Then what is "Bad $Supports from <unknown> (xxx.xxx.xxx.xxx) - user closed." in the log?

That is rmDC++, client sending more buggy supports that this block will disallow