mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Good point. So it looks like this would break all existing scripts that use these features. I am going to avoid making any changes for now since there does not seem to be a viable solution. The best solution, that would avoid breaking clients/scripts, would be for UnrealIRCd to ensure that the ban/etc. lists are case-insensitive.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
If you are needing a way to identify conventional bans, versus bans prefixed with flags, I would check if the first character of the banmask matches none of: A-Z a-z ][}{\|^`_- ?* 0-9 and possibly: . : /

In theory, ban flag prefixes are not going to use any of the following: Qualified nickname characters nor Wildcard characters. Possibly wouldn't use qualified DNS characters '.' and ':' (though '~' is found in ident). Probably wouldn't use '/'.

Charybdis uses '$', and UnrealIRCd uses '~' for its flag prefixes. Let's just start by assuming these are the only possibilities for abnormal ban address masks that might require special handling or case sensitivity.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
The issue is that I would need to split the extended ban address into the case-sensitive and case-insensitive parts in order to compare them separately. For example, on UnrealIRCd, these would be identical:

~r:abc!def@ghi.org
~r:abc!DEF@ghi.org

case-sensitive comparison: ~r and ~r
case-insensitive comparison: abc!def@ghi.org and abc!DEF@ghi.org

And these would be different:

~r:abc!def@geh.org
~R:abc!def@geh.org

case-sensitive comparison: ~r and ~R
case-insensitive comparison: abc!def@ghi.org and abc!def@ghi.org

So I would need to parse the extended ban prefixes all the way to the data parts in both addresses, so I can compare the prefixes case-sensitively and the data parts case-insensitively.

In order to do that, I would need to know:

1) The exact method that the ircd itself uses to parse the prefixes, to make sure I do it the same way.

2) That all ircds use the same method. If they do not, it will fail on different ircd implementations.

This is why I wanted to avoid the above by not performing tracking. But that would break features/scripts that have worked for 15+ years.

I have already implemented a routine that extracts:

EXTBAN=$,ajrxz (on irc.freenode.net)
EXTBAN=~,SOcaRrnqj (on irc.unrealircd.org)

And uses the specified prefix. It then stores and scans everything after , and determines if extban types are case-sensitive or not. If case-sensitive, a banmatch routine parses the ban addresses to be compared, checking for a prefix (required), a ~ negation (optional), an extban type character (optional), and a : colon (optional), repeatedly (to handle stacked types) until no more prefixes are available. It then assumes whatever is left is the data part. It then compares the extban section case-sensitively and the data part case-insensitively. However, there is no way to know if this will work across ircd implementations.

I am also going to add a $ibl() .extban and .extdata property that return the split information. That might help debug the routine to see if it is working correctly with different extbans.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Okay, it looks like the parsing method needs to be more sophisticated than the one I described above.

If the extbans are stacked, they can contain multiple extban characters and data, all of which need to be parsed and split separately and compared case-sensitive/case-insensitive per extban:data combination.

-> irc2.unrealircd.org MODE #thisisatest +b ~q:~xyz!abc@lmn.org~c:#pumpkin~T:censor:*badword*
<- :nick!user@host MODE #thisisatest +b ~q:~xyz!abc@lmn.org~c:#pumpkin~T:censor:*badword*

Notice that the ~ prefix can also be used in data, so it is not as simple as spltting the line into parts based on the prefix character. We will need to go character by character, validating each character, and its formatting, against the EXTBAN list, and splitting them into multiple extban:extdata parts.

Really, the only way to be sure we are doing this correctly is to look at the ircd source code. The odds are that UnrealIRCd and Freenode will do this differently, which means that an IRC client cannot parse this information without using a different method for each ircd.

I am going to leave this issue for now, since I cannot see a practical solution.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Khaled
I am going to leave this issue for now, since I cannot see a practical solution.

That does sound like the best option. What a mess..


Saturn, QuakeNet staff
Page 2 of 2 1 2

Link Copied to Clipboard