View Issue Details

IDProjectCategoryView StatusLast Update
0003928unrealircdpublic2010-08-14 20:40
ReportersyzopAssigned Tosyzop 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version 
Target VersionFixed in Version3.2.9-RC1 
Summary0003928: Fix chained/stacked bans
DescriptionJust a TODO item to remember me fixing chained/stacked bans.
It should not be in 3.2.9 release in it's current state.
TagsNo tags attached.
3rd party modules

Relationships

related to 0003193 resolvedaquanight Enable some combinations of extbans 
has duplicate 0003192 resolvedohnobinki Add a new simple extban 
has duplicate 0003505 closed Seven possible new ban functions and corresponding extbans 
related to 0002817 resolvedsyzop Request: Extended Invex 
child of 0003776 resolvedsyzop Unreal3.2.9 TODO 

Activities

syzop

2010-08-14 20:40

administrator   ~0016270

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).

Issue History

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