View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003193 | unreal | ircd | public | 2007-01-06 06:13 | 2010-08-14 20:42 |
| Reporter | Shining Phoenix | Assigned To | aquanight | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i386 | OS | Linux | OS Version | 2.6.10-1.771_FC2 |
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.2.9-RC1 | ||||
| Summary | 0003193: Enable some combinations of extbans | ||||
| Description | Extbans ~c and ~r are different ways of specifying users, ~n and ~q are different things to do to users. Some new combos could be: ~nc - Users in matching channel can('t) nickchange ~nr - Users with matching realname can('t) nickchange ~qc - Users in matching channel can('t) speak ~qr - Users with matching realname can('t) speak And if the new simple ewxtban I suggested was added: ~jc - Users in matching channel can('t) join ~jr - Users with matching realname can('t) join Nice, accurate little extbans. I think anyone who uses ~c and ~r extbans may use these as well :) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
That'd be nice |
|
|
this seems way over the top. imo write a module for it, i wouldnt stick it in the core |
|
|
Yeah, but we know how 3rd party modules cause problems =P I guess I could request a module for this /me wanders off to the forums |
|
|
I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like: +b ~n:~c:#blah - anyone in #blah can't /nick +b ~q:~r:*lamer* - anyone with "lamer" in realname can't speak Note you wouldn't be able to do this the other way around: for example, ~c:~q:#blah wouldn't work. This could conceivably be done to any extban that would otherwise just take a normal n!u@h mask. Of course you could then do wierd but useless combinations like ~q:~n:~q:~n:~q:~q:~n:~n:~c:#blah(*) ... but not for me to tell people not to uselessly waste banspace if they really want to do that for some reason. Bricker: As it is now, you can't write a module for it - extbans are only allowed one character (another reason why "chaining" as stated above would work better), and you can't "override" extbans like you do commands. Also it wouldn't allow extending this to other extbans, like RegExcept, etc. And if you look at the extban.c code for ~q/~n - it's a change of exactly 1 function call for each of the two (from extban_is_banned_helper to just is_banned) so it's not a stupidly complicated change or anything. ( (*) == Useless because ~q:blah == match (blah) only during msg check, and ~n:blah == match (blah) only during nick change, so ~q:~n:blah == match (match (blah) only during nick change) only during msg check == can never match. ) [edit: I should also point out that a chained ban would likely also not work with extban that doesn't ban on the join/nick/msg basis (eg: syzop's textban module). Also I suppose it would be necessary for ~q/~n's "format convparam to forward to the sub-extban's convparam] |
|
|
*Ignore this suggested syntax, look at the next one* Hmm, I have an idea. What if a user could only set one mode at a time when using an extban? So, when the first parameter after the mode has a ~ in front: /mode #channel {+|-}<mode> ~<extbans> {extbanparam} {extbanparam} ... {n!u@h} And when the first parameter after the mode does not have a ~ in front, it is handled normally. That way, you could combine any number of extbans together, e.g. /mode #channel +b ~jr stupid_bot_script *!*@*.aol.com |
|
|
The problem with that, is all the extban params need to be in 1 ban param. Spaces separate params, so it would not work. |
|
|
Umm, read over my suggestion more closely. When someone sets an extban using this system, they can only set one ban mode at a time. Then, since there are no other mode parameters to confuse things, the extban parameters can be seperated by spaces. |
|
|
No. - It would most certainly break clients. Much more than extbans do already. - It's extra work for the mode parser when simpler solutions are available. |
|
|
*I keep coming up with new ideas, look further down* Hmm. mode # +b/e/I ~type1:param1:param2:~type2:param3:param4 So, "after the second colon, before the next :~" would be the definition of param2 in that, then having : within an extban param(e.g. IPv6), and having ~ in an extban param(e.g. ~#chan2) wouldn't be a problem. I'm fairly sure no extban parameter would have ~: in it. |
|
|
a) ~T or ~r could contain _any_ characters b) I back aquanight on this one. |
|
|
a) chaining ~n and ~q to the extbans sounds interesting. b) adding multiple parameters is a bit much, and likely impossible. |
|
|
Tabrisnet said: a) ~T or ~r could contain _any_ characters Hmm. 1. Don't allow a combo of T and/or r and/or c and/or f 2. Make sure their troublesome parameter is specified last. Then, the banned text would be "all the stuff after the colon after the ~T:", the banned realname would be "all the stuff after the ~r:", the banned channel would be "all the stuff after the ~c:", and the forwarded channel would be "all the stuff after the ~f:". ...that just disallowed nearly every combo there is... Or, only allow combos between any number of action extbans, and just one usermatching extban. e.g. ~nq:n!u@h ~jr:realname ~qc:@#lamers ~nqfC:#losers:202.156.345.765/32 <--usermatching param is all after last colon *More detail below* |
|
|
The rule has always been 1 mode has no more than 1 parameter. Only +f and +j break this rule, but they need to. +b does not need to because it's a list mode. People can take the time to do +bbbbbbbbbbbbeIeIo blah.... Also, ~c bans *CAN* start with a tilde. You can use a PREFIX= prefix to match users in the channel with that status or higher. ~r can start with tildes. ~T can start with tildes. If you start saying X ban type has to be last (and you can't core-side enforce that for ~T, it's module-provided, so now you have to somehow let the module say "has to be last"), you completely defeat the purpose of the whole thing. This is exactly why it should stay one extban per +b, no more. Plus now you have to parse something around something other than a space seperator. Basic IRC already takes care of parameters as it is, no need for +b to do extra logic. (Checking for ~, some letter, and : is easy enough, but having to strtok() loop over a :-seperated list is pushing it.) And what is the benefit of it anyway? You don't get any more or less banspace with it (banspace is limited by # of bans and by raw length), and it's simpler to do +bbbb ban1 ban2 ban3 ban4 (and some clients have a command to do it for you, and some might even break it up into multiple /modes if you go over 12 bans). Extended bans confuse clients enough since they know only of normal bans. Please let's *NOT* confuse them anymore with multiple parameter stuff. One mode, one parameter. It's worked so far, why break it? It's feasible to chain ~q: and ~n: (and ~j:) onto the other extbans. It's just taking the fact that they already do half the work of normal ban parsing (normal n!u@h), and changing *one* function call (and add forwarding logic in convparam) is enough to have the other half. It isn't feasible to go wild with it and start chaining X00 bans onto the one entry. [edit: Ick, looks like I was wrong: is_banned is what actually checks the entire banlist (not just one ban). But we could extract the check of the individual ban inside the loop into a function and then just use that.] |
|
|
Hmm. Make ban syntax(I know this is a clumsy way to show it): mode #chan {+|-}<b|e> {~<{action}{masktype}|{other}:>}<mask> All extbans would be either action, masktype or other. Put all extbans in modules perhaps? Where action currently is = j|n|q|jn|nq|jq Masktype currently is = C|E|r|c Other currently is = T {optional} <required> option1|option2 |
|
|
jesus H christ! FIX IT ALREADY! ;P |
|
|
aquanight said: I'd think it's a bit simpler to just do "chained" extbans. Basically as it is now, ~n and ~q just take a n!u@h mask, but we could just pass the mask right back to the ban parser, thus allowing something like: +b ~n:~c:#blah - anyone in #blah can't /nick I say: Would +b ~n:~c:~#blah work? |
|
|
This conversation is getting weird. I agree with aquanight. The ~q:~c:#Chan chaining stuff is the way to go. Also: A ~j: would be very nice. As it is, a normal ban is ~j & ~q |
|
|
Err, a normal ban is ~q, ~j and % or higher required to nickchange >.> Well, if you're sure about the chaining, ok. A lot of ~: to type =( |
|
|
*bump* Chained extbans would be a good feature, e.g. +b ~n:~c:~#lame_guys_channel Modules that provide extra extbans would need to be fixed afterwards to take advantage of this feature...especially m_hostforward (extban ~f). Disallowing colons in channel names, which I believe is going to be done in future, will make chained extbans more doable. |
|
|
aquanight wanted to do this but, basically I said waaaaah waittt ;P But I'd be fine if you (aquanight) would again look into it... with a few remarks: * Things should stay very fast, ban checking is one of the most important CPU eating tasks in the IRCd (top 5). * The code shouldn't be cluttered too much, aka "try to keep the code nice" * There should be a config option to disable this feature (for speed/personal preferences/etc) * Should only allow one combination like ~q:~c:#chan and not like ~q:~c:~c and such ;p * You're right, be careful with allowing which extbans to be extended, sometimes ~ may be used in the extban itself already, so that means it could not be extended or else you get confusion. I guess extbans should somehow set a flag (on init/load/whatever, in the extbanadd thing) whether they'd allow them to be extended or not. ~q and ~n look a good place to start. So like point 1 (speed), if you'd split things to 'check whole banlist' and 'check individual ban' functions, be sure to tag the 2nd as inline, and.. also use the n!u@h buffers (std, ip, cloak, etc) in that function and don't go rebuild them for every ban... you get the idea. well, you probably get a good idea how to do things then, have fun ;P ***** Then on ~j.. that deserves a separate report, with some good explanation over there why it would be useful. |
|
|
~j at http://bugs.unrealircd.org/view.php?id=3192 |
|
|
Going with the chained extban deal. To sum up what's basically going to happen: - Any extban (like, say, ~q) that normally uses (as either all or part of their parameter) a nick!user@host mask, can instead choose to allow sticking an extban in its place. So eg for ~q:nick!user@host, you could then do ~q:~c:#stfu. - It will be up to each extban to decide if it wishes to allow stacking extbans or not. The current extban_is_banned_helper() function that allows extbans to easily do n!u@h matching will remain as it is (= no extban stacking) for compatibility. - An extban that wishes to allow stacking will call a function like ban_check_mask, which will do n!u@h, or extban, as appropriate. Such extbans also need to arrange for convparam forwarding. - Since extbans are in control of whether or not extbans stack, they are given responsibility for dealing with any stacking limits they might want to impose, or to, say, collapse wasteful things like ~q:~q:~q:~q:~q:blah, to ~q:blah. - I'm still considering whether to control this behavior with a ./Config option or unrealircd.conf option, or indeed if such an option is really needed at all. I can understand the whole "personal preferences" deal though, and I'm leaning toward ./Config option since that way will ensure modules have to respect it (as if they don't, they won't compile when support for it is switched off :P ). |
|
|
Added to devel (3.3*) CVS, .2397 I'll do a slightly better write-up or something when I have time. Put simply, though, existing modules don't have to change unless they want to deal with chained extbans, but core extbans now support chaining. For compatibility, an Config option disables this support, and makes extbans work pretty much exactly as it did before. (So basically, modules can still support this and be ok in 3.2 because of the #define.) - Added support for "chained" extbans. Put simply this allows extban combinations such as ~q:~c:#test to only silence users on #test, for example. This feature is enabled by default, but can be disabled during ./Config -advanced. Module support for this feature must note the following: - For is_ok function, the extban can either assign extban_is_ok_nuh_extban, which will deal checking a chained extban (including checking for restricted extbans), or it can call that function from its own is_ok routine. For the latter case, remember to pass only the mask part of your ban format (ie, don't just pass para as otherwise it'll just call your is_ok again). - For conv_param function, the extban can either assign extban_conv_param_nuh_or_extban, which will automatically call conv_param for a chained extban, or pretty up a n!u@h mask. - For is_banned, the extban should call ban_check_mask with the mask part of the parameter. This will automatically call is_banned for a stacked extban, or match against a n!u@h. n!u@h is checked against the current user (ie, with the info in the globals ban_ip, etc), so things can get weird if you call this outside a normal ban check. Modules must keep in mind that chained extban support is not available (and neither are the three functions above) if DISABLE_STACKED_EXTBANS is #defined (this is controled by Config). Modules will not compile/load if they try to use them anyway. This change should not break extban modules, and should need some more extensive testing. |
|
|
The problem with combining extbans is that if you can combine some but not others, then you have to remember which can and can't be combined, which makes it more complex. If any extbans could be combined in one ban, then this topic gets simpler. If there was one magic character that could seperate the parameters of each extension, then you could do +b ~thing1:~thing2:param1<magic character>param2 An analogy for this is that the magic character in mode lines is a space, ie /mode #channel mode1mode2 thing1 thing2 The sticking point here is that I couldn't think of a suitable magic character for seperating the parameters of a chained ban. Today I think I figured it out. <magic character> is a semicolon As far as I know, semicolons are never in the host part of nick!ident@host, nicknames, CIDR bans or server names. So all that's left to worry about are channel names and real names. If semicolons are disallowed in channel names and real names, then semicolon won't be used within the matching bit of any extban (except T, I'll get to that later), so it can be used as the magic character. To diallow semicolons in real names, I suggest that ; gets changed to T, so that if a person has ;-; in their real name it changes to T.T, hence retaining its original meaning. Chaning textban ~T with other extbans is doomed to fail, so it simply shouldn't be allowed. So yeah, people would need to remember that T doesn't chain, but that's easier to remember than "c, C and r (and s if unreal has it) don't chain with each other". |
|
|
Added in CVS mass-commit .863: - This is actually an update of earlier code from CVS, but now it works ok: - Added support for "stacked" extbans. Put simply this allows extban combinations such as ~q:~c:#test to only silence users on #test, for example. This feature is enabled by default, but can be disabled during ./Config -advanced. This feature was suggested by Shining Phoenix (0003193), was then coded by aquanight for U3.3, and later on backported and partially redone by Syzop. Module coders: In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban: Since stacked extbans only makes sense where the 1st one is an action extended ban like ~q/~n/~j, most modules won't have to be changed, as their extban never gets extended (just like ~c:~q: makes no sense). However, you may still want to indicate in some cases that the extban your module introduces also shouldn't be used as 2nd extban. For example with a textban extban ~T it makes no sense to have ~n:~T. The module can indicate this by setting EXTBOPT_NOSTACKCHILD in the ExtbanInfo struct used by ExtbanAdd(). For completeness I note that action modifier extbans are indicated by EXTBOPT_ACTMODIFIER. However, note that we currently assume all such extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things will go wrong with regards to stack-counting. Module coders should also note that stacked extbans are not available if DISABLE_STACKED_EXTBANS is defined. - Added extended ban ~R:<nick>, which only matches if <nick> is a registered user (has identified to services). This is really only useful in ban exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he has identified to NickServ. This is often safer than using +e n!u@h. - Added Extended Invex. This is very much like extended bans, in fact it supports some of the same flags. Syntax: +I ~character:mask Currently supported are: ~c (channel), ~r (realname) and ~R (registered). This can be useful when setting a channel invite only (+i) and then setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while still being able to ban users. Because action modifiers (~q/~n/~j) make no sense here, extended invex stacking (+I ~a:~b:c) makes no sense either, and is not supported. Suggested by DanPMK (0002817), parts based on patch from ohnobinki. Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by ExtbanAdd() to indicate that your extban may also be used in +I. - Invex (+I) now always checks cloaked hosts as well. Just like with bans, it checks them also when the user is not currently cloaked (eg: did -x, or is currently using some VHOST). - Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-01-06 06:13 | Shining Phoenix | New Issue | |
| 2007-01-06 11:54 | Stealth | Note Added: 0013008 | |
| 2007-01-06 21:28 | Bricker | Note Added: 0013020 | |
| 2007-01-07 00:55 | Shining Phoenix | Note Added: 0013022 | |
| 2007-01-08 13:42 | aquanight | Note Added: 0013032 | |
| 2007-01-08 13:45 | aquanight | Note Edited: 0013032 | |
| 2007-01-21 22:58 | Shining Phoenix | Note Added: 0013077 | |
| 2007-01-22 13:47 | Stealth | Note Added: 0013091 | |
| 2007-01-23 02:42 | Shining Phoenix | Note Added: 0013092 | |
| 2007-01-23 09:37 | aquanight | Note Added: 0013097 | |
| 2007-01-23 21:08 | Shining Phoenix | Note Added: 0013098 | |
| 2007-01-23 21:11 | tabrisnet | Note Added: 0013099 | |
| 2007-01-23 21:12 | tabrisnet | Note Added: 0013100 | |
| 2007-01-23 21:17 | Shining Phoenix | Note Added: 0013101 | |
| 2007-01-23 21:19 | Shining Phoenix | Note Edited: 0013077 | |
| 2007-01-23 21:34 | Shining Phoenix | Note Edited: 0013101 | |
| 2007-01-23 21:46 | Shining Phoenix | Note Edited: 0013101 | |
| 2007-01-23 21:48 | Shining Phoenix | Note Edited: 0013101 | |
| 2007-01-23 22:02 | aquanight | Note Added: 0013102 | |
| 2007-01-23 22:10 | aquanight | Note Edited: 0013102 | |
| 2007-01-23 23:12 | Shining Phoenix | Note Added: 0013103 | |
| 2007-01-23 23:17 | Shining Phoenix | Note Edited: 0013103 | |
| 2007-01-27 17:04 | Bricker | Note Added: 0013127 | |
| 2007-01-28 01:35 | Shining Phoenix | Note Edited: 0013103 | |
| 2007-01-29 23:13 | Shining Phoenix | Note Edited: 0013098 | |
| 2007-01-29 23:14 | Shining Phoenix | Note Edited: 0013101 | |
| 2007-01-29 23:19 | Shining Phoenix | Note Edited: 0013103 | |
| 2007-01-31 03:23 | Shining Phoenix | Note Added: 0013156 | |
| 2007-01-31 03:24 | Shining Phoenix | Note Edited: 0013156 | |
| 2007-02-01 18:12 | JasonTik | Note Added: 0013157 | |
| 2007-02-01 18:13 | JasonTik | Note Edited: 0013157 | |
| 2007-02-01 20:34 | Shining Phoenix | Note Added: 0013158 | |
| 2007-04-18 05:54 |
|
Relationship added | child of 0003284 |
| 2007-04-18 06:07 |
|
Status | new => acknowledged |
| 2007-05-07 20:28 | Shining Phoenix | Note Edited: 0013103 | |
| 2007-05-07 20:33 | Shining Phoenix | Note Added: 0014028 | |
| 2007-05-08 04:24 | syzop | Note Added: 0014045 | |
| 2007-05-10 21:54 | Shining Phoenix | Note Added: 0014083 | |
| 2007-05-12 10:05 | aquanight | Note Added: 0014096 | |
| 2007-05-12 10:05 | aquanight | Assigned To | => aquanight |
| 2007-05-12 10:05 | aquanight | Severity | minor => feature |
| 2007-05-12 10:05 | aquanight | Status | acknowledged => assigned |
| 2007-05-13 17:19 | aquanight | Note Added: 0014121 | |
| 2007-05-13 17:19 | aquanight | Status | assigned => resolved |
| 2007-05-13 17:19 | aquanight | Resolution | open => fixed |
| 2007-05-13 17:19 | aquanight | Fixed in Version | => 3.3-alpha0 |
| 2008-09-03 04:21 | Shining Phoenix | Status | resolved => feedback |
| 2008-09-03 04:21 | Shining Phoenix | Resolution | fixed => reopened |
| 2008-09-03 04:21 | Shining Phoenix | Note Added: 0015399 | |
| 2010-07-14 21:16 | syzop | Relationship added | related to 0003928 |
| 2010-08-14 20:41 | syzop | QA | => Not touched yet by developer |
| 2010-08-14 20:41 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2010-08-14 20:41 | syzop | Note Added: 0016271 | |
| 2010-08-14 20:41 | syzop | Status | feedback => resolved |
| 2010-08-14 20:41 | syzop | Fixed in Version | 3.3-alpha0 => 3.2.9-RC1 |
| 2010-08-14 20:41 | syzop | Resolution | reopened => fixed |
