Clients with buggy supports block

[PPK]

-- 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]

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  ;D

[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 ? ;D

[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 ? ;D

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  ;D

[ATAG]

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

How can i disable it? 

[ATAG]

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

[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 :

[PPK]

It is funny but dc++ devs again shown that they are bunch of idiots. Not only that they are not able to correctly code things as it is documented by them, but they are not able to fix bugs they created... https://answers.launchpad.net/dcplusplus/+question/179023  ;D