Poll
Question:
Add that block to PtokaX ?
Option 1: YES!
votes: 8
Option 2: Only as option with default enabled.
votes: 11
Option 3: Only as option with default disabled.
votes: 7
Option 4: NO. We must live with that bug.
votes: 0
-- 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
Yes, but not in a hardcoded way. Or at least not for the first time. :P
May i suggest a Core.Kick instead of a Core.Disconnect to avoid hammering ? ::)
Quote from: CrazyGuy on 16 December, 2007, 13:48:55
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.
Quote from: bastya_elvtars on 16 December, 2007, 14:01:34
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
If kicking doesnt that mean user has to be in hub ... therefore defeting the object
i voted 'yes' but thats because i'd like to see the back of all dodgy clients ;D
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.
The only one client which sends corrupted $Supports string is rmDC.
No, it is not only one client :P But yes this script block rmDC++ too 8)
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
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 ::)
Quote from: PPK on 05 January, 2008, 22:59:00
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 :P
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
Voting locked, will be implemented in next PtokaX version as option with default enabled 8)
good ;D
Quote from: PPK on 04 July, 2008, 16:06:51
Voting locked, will be implemented in next PtokaX version as option with default enabled 8)
How can i disable it? :o
Then what is "Bad $Supports from <unknown> (xxx.xxx.xxx.xxx) - user closed." in the log?
Quote from: ATAG on 13 October, 2008, 01:09:16
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 ::)
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 (http://neisep.com/dc/index.php?title=$Supports), but they are not able to fix bugs they created... https://answers.launchpad.net/dcplusplus/+question/179023 ;D