| Commit message (Expand) | Author | Age | Files | Lines |
|---|
| * | - Make default service stamp 0 (zero) again, instead of '*' which was••• introduced by ESVID changes a few days ago. This makes anope happy,
and also means nothing will change in a non-ESVID scenario.
|  Bram Matthys | 2011-12-28 | 1 | -0/+2 |
| * | extban ~a = also allowed for invex | Bram Matthys | 2011-12-25 | 1 | -0/+1 |
| * | - Added extended ban ~a:<account name> which matches users who are logged••• in to services with that account name. This works only on services that
support ESVID. Patch from nenotopia (#3966).
| Bram Matthys | 2011-12-25 | 1 | -0/+24 |
| * | - Fix compilation issue when disabling stacked extbans. https://bugs.gentoo.o... |  Nathan Phillip Brink | 2011-11-09 | 1 | -1/+1 |
| * | - Fixed braindamage in stacked bans. | Bram Matthys | 2010-09-25 | 1 | -5/+7 |
| * | ..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).
| Bram Matthys | 2010-08-14 | 1 | -25/+96 |
| * | - Add an extban of the schema +b ~j:*diff | less@* which _only_ prevents a us... |  binki | 2010-07-22 | 1 | -0/+28 |
| * | - Prevent stacked bans (like +b ~q:~q:~n:~c:#chanel) from crashing unrealircd... | binki | 2010-07-13 | 1 | -2/+8 |
| * | hmmm... dilemma... | Bram Matthys | 2009-11-29 | 1 | -0/+2 |
| * | - Added support for "chained" extbans. Put simply this allows extban combinat...••• 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.
- Misc fix for disabling extban chains, should've done stuff in our autoconf
stuff instead of hacking configure directly :P .
| Bram Matthys | 2009-11-29 | 1 | -1/+113 |
| * | - Made the IRCd calculate the cloaked host only once upon connect, and store ...•••- When checking if a user is banned, we always check the cloakhost too. Previously we could
not do this if the user had a /VHOST (=a minority of the cases, but still...). In short,
this is some extra protection to combat ban evasion.
- Performance of is_banned() *slightly* improved (just 1-2 usec, but 7 usec if no bans).
- [Module coders] For extban routines, we now offer a routine extban_is_banned_helper(buf)
which can be used instead of the ban_realhost/etc static chars stuff, see
extban_modeq_is_banned for a (real-life) example of how this is used.
- [Services coders!] Added PROTOCTL CLK (requires NICKv2) which adds an extra field in the
NICK command (when a user connects) right before the infofield (gecos).
The added field contains the cloaked host, that is: the masked host if +x would have been
set. This field is ALWAYS sent, regardless of whether the user is actually +x or not.
Services can then store this field in memory, to know the host of the user if the user
is set +x (+x-t). This is a (better) alternative to PROTOCTL VHP, with no race conditions,
and avoids some other VHP problems.
VHP will stay supported though... so it's not mandatory to switch over.
| Bram Matthys | 2006-04-16 | 1 | -12/+2 |
| * | - Redid glob matching. Escaping is now ripped out for normal bans (as it shou...••• means no longer weird issues with +b *\* etc not banning nicks with \ in it.
ExtBan ~c/~r get special treatment and will use our match_esc [match with escaping]
routine, that way you can ban channels such as "#f*ck" via "+b ~c:#f\*ck".
Fix triggered by bugreport of vonitsanet (#0002782).
| Bram Matthys | 2006-01-30 | 1 | -2/+3 |
| * | - Couple of source code cleanups (svsnick, a *line msg, kill, and some useles...••• code), suggested by Nazzy and Requi3m.
- Fixed extbans no longer working properly in CVS, fix provided by Nazzy (#0002681).
| Bram Matthys | 2005-11-09 | 1 | -0/+11 |
| * | - Fixed ~c not working properly with * and ?'s in channel names.. Now you jus...••• escape them like in all bans (eg: to ban #* you need to +b ~c:#\*). As an additional
bonus, real wildcards are now accepted and processed (eg: +b ~c:#*sex*, just don't
forget to specify the #). Reported by PhantasyX (#2605).
- Sidenote on above: ~c:*chan* is not supported (use ~c:#*chan* instead) because it would
cause "hidden bans", therefore it now prints a message (which is useful anyway), but
does accept such remote bans. In 3.2.5 or so we could enable support for it, it's
not that important though... ;)
- Added ifdefs for mass closing of file descriptors on start, can now be disabled by
adding -DNOCLOSEFD as a compile option. Useful for valgrind w/--db-attach=yes, mpatrol,
and some other debugging tools (not useful for anyone normally running a server).
- Fixed a read-after-free: sptr->serv->aconf was freed but not NULL'ed in exit_client,
causing close_connection to read from it (when deciding on doing a quick reconnect).
Could have caused a crash, although nobody ever reported one...
- Removed useless strncpyzt with dest==src.
| Bram Matthys | 2005-08-19 | 1 | -2/+27 |
| * | - Added a feature to +b ~c, ~c:[prefix]<#channel>, prefix can be +/%/@/&/~ an...••• check if the user is voiced/halfoped/etc.. Especially useful for +e ~c. Idea from
Bugz (#0002198). Obviously all servers need to be upgraded to make this work.
| Bram Matthys | 2005-02-12 | 1 | -3/+40 |
| * | Added an options member to the ExtbanInfo structure. This currently supports ... | codemastr | 2005-01-23 | 1 | -0/+2 |
| * | Corrected numerous -Wall warnings | codemastr | 2004-11-04 | 1 | -1/+0 |
| * | Rewrote the 005 system to be dynamic and added an API to manipulate it | codemastr | 2004-09-03 | 1 | -1/+10 |
| * | - Fixed ban bug: halfops were also prevented from doing nickchanges if banned...••• +b ~n:*!*@* also made nickchanges impossible for voiced(&halfop'ed) people (so like half
of the purpose of it was defeated @$#&@#). Reported by Rocko.
| Bram Matthys | 2004-07-06 | 1 | -0/+3 |
| * | - Made extbans desynchs a bit more friendly: if a bantype is unknown for the ...••• it will just accept it if it's from a remote server, and also ops/etc will be allowed
to REMOVE any unknown extbans (but not add new unknown ones).
- Added extended ban type ~n (nickchange ban), if a user matches this (s)he can not
change nicks (eg: +b ~n:*!*@*.aol.com) unless (s)he has voice or higher.
This can be useful as an overall measure for some +m chans (+b ~n:!*@*) or against
specific 'good' people that are just nickflooding due to a wrongly configured script.
- Added set::restrict-extendedbans by which you can disallow normal users to use
any extendedbans ("*") or disallow only certain ones (eg: "qc").
- Made the negative TS message a bit more annoying if time is off more than 10 seconds.
| Bram Matthys | 2004-06-12 | 1 | -0/+19 |
| * | Added module support for Windows | codemastr | 2004-05-12 | 1 | -3/+3 |
| * | Various fixes | codemastr | 2004-01-10 | 1 | -1/+1 |
| * | Made extbans use the module objects system | codemastr | 2004-01-09 | 1 | -7/+29 |
| * | Bug fixes and EXTBAN 005 token | codemastr | 2004-01-08 | 1 | -2/+17 |
| * | Made the extban stuff compatible with the module API | codemastr | 2003-12-20 | 1 | -28/+24 |
| * | minor fix | Bram Matthys | 2003-12-19 | 1 | -2/+2 |
| * | - Added "extended bans". An idea from SorceryNet ircd.••• These bans look like ~<type>:<stuff>. Currently the following bans are available:
~q: quiet bans (ex: ~q:*!*@blah.blah.com). People matching these bans can join
but are unable to speak, unless they have +v or higher.
~c: channel bans (ex: ~c:#idiots). People in #idiots are unable to join the channel.
~r: gecos (realname) bans (ex: ~r:*Stupid_bot_script*). If the realname of a user
matches this then (s)he is unable to join.
NOTE: an underscore ('_') matches both a space (' ') and an underscore ('_'),
so this ban would match 'Stupid bot script v1.4'.
These bantypes can also be used in the channel exception list (+e).
+e ~r:*w00t* makes anyone with 'w00t' in their realname able to join,
and +e ~c:#admin makes anyone in #admin able to join, etc..
This system allows modules to add extended bantypes too.
This feature requires some additional testing, also the module interface will
probably be changed in the next few weeks, and perhaps more extended bans will
be added before next release.. we'll see...
| Bram Matthys | 2003-12-19 | 1 | -0/+230 |
Bram Matthys
Nathan Phillip Brink
binki