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 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| 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. 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 |
|---|---|---|---|
| 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 |
