View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003928||unreal||ircd||public||2010-07-14 17:32||2010-08-14 20:40|
|Target Version||Fixed in Version||3.2.9-RC1|
|Summary||0003928: Fix chained/stacked bans|
|Description||Just a TODO item to remember me fixing chained/stacked bans.|
It should not be in 3.2.9 release in it's current state.
|Tags||No tags attached.|
|3rd party modules|
|related to||0003193||resolved||aquanight||Enable some combinations of extbans|
|has duplicate||0003192||resolved||ohnobinki||Add a new simple extban|
|has duplicate||0003505||closed||Seven possible new ban functions and corresponding extbans|
|related to||0002817||resolved||syzop||Request: Extended Invex|
|child of||0003776||resolved||syzop||Unreal3.2.9 TODO|
Fixed 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.
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).
|2010-07-14 17:32||syzop||New Issue|
|2010-07-14 17:32||syzop||Status||new => assigned|
|2010-07-14 17:32||syzop||Assigned To||=> syzop|
|2010-07-14 17:32||syzop||QA||=> Not touched yet by developer|
|2010-07-14 17:32||syzop||U4: Need for upstream patch||=> No need for upstream InspIRCd patch|
|2010-07-14 17:32||syzop||U4: Upstream notification of bug||=> Not decided|
|2010-07-14 17:32||syzop||U4: Contributor working on this||=> None|
|2010-07-14 17:32||syzop||Relationship added||child of 0003776|
|2010-07-14 21:16||syzop||Relationship added||related to 0003193|
|2010-07-14 21:17||syzop||Relationship added||has duplicate 0003192|
|2010-07-14 21:18||syzop||Relationship added||has duplicate 0003505|
|2010-08-03 14:01||ohnobinki||Relationship added||related to 0002817|
|2010-08-14 20:40||syzop||Note Added: 0016270|
|2010-08-14 20:40||syzop||Status||assigned => resolved|
|2010-08-14 20:40||syzop||Fixed in Version||=> 3.2.9-RC1|
|2010-08-14 20:40||syzop||Resolution||open => fixed|