the particular extended ban module if you don't want it.
For example, if you include the default modules.default.conf and, say,
you don't want ~quiet extbans then you add this in your unrealircd.conf:
blacklist-module "extbans/quiet";
instead of arbitrary 256 and such. Also makes it so other people
reading this code will understand better that MAXBANLEN is the
real limit here and not 256 (which is never reached because
the cut off already happens at 200).
allow bans of NICKLEN+USERLEN+HOSTLEN+3. Previously NICKLEN was
ommitted for some reason, which also explains why this ban-
simplification-routine exists in the first place. I think we can
make it use this full n!u@h space. Especially since we already allow
this for bans like ~quiet (the full n!u@h) and other extbans can be
quite long as well, it no longer makes sense to limit it here.
Small detail: in extban_conv_param_nuh() we used +32 which i think
is from the times when we had to deal with prefixes like ~quiet,
which is no longer the case, this routine is only about the final
suffix after the last : in a ban.
This was documented as optional in include/modules.h but on
https://www.unrealircd.org/docs/Dev:Extended_Bans_API it
was always mentioned as required.
In practice, I know of no module that does not have this,
in UnrealIRCd or third party (doing zero filtering is
quite a bad idea).
Anyway, long story short: this also means we can remove some
(flawed) logic in src/api-extban.c in case conv_param was
NULL, which raised a compiler warning:
api-extban.c: In function ‘extban_conv_param_nuh_or_extban’:
cc1: error: function may return address of local variable [-Werror=return-local-addr]
api-extban.c:382:14: note: declared here
382 | char tmpbuf[USERLEN + NICKLEN + HOSTLEN + 32];
| ^~~~~~
leading to duplicates. The effect was that in the 005 EXTBAN= string some
letters showed up twice like EXTBAN=~,aacfjmnpqrrtCCGGOSST.
Reported by jesse in https://bugs.unrealircd.org/view.php?id=6199
Reported by armyn in https://bugs.unrealircd.org/view.php?id=6147
This also adds a new function convert_regular_ban() which is now
used by both clean_ban_mask() and extban_conv_param_nuh().
The extban module API is used behind the scenes. To the server admin
the functionality appears in a more natural way:
account { <list>; };
country { <list>; };
realname { <list>; };
certfp { <list>; };
In the same way, they appear as exclude-xxx options too:
exclude-account { <list>; };
exclude-country { <list>; };
exclude-realname { <list>; };
exclude-certfp { <list>; };
Modules can add additional fields (3rd party modules too!).
Module coders:
See src/modules/extbans/realname.c for a simple example. In short:
1) You need to register your extban in both MOD_TEST and MOD_INIT
2) Other than that, the existing rules for extended server bans apply:
a) Your req.is_banned_events needs to include BANCHK_TKL
b) Your req.options needs to include EXTBOPT_TKL
Be advised that for modules that are called in extended server bans
the client may be missing several fields, for example client->user could
be NULL, so be careful with accessing everything in your module.
Just like already done for Usermode_Table[] and Channelmode_Table[].
This also adds support for ->unloading=1 and re-use etc etc,
something that seemed to be missing before (but also wasn't
an issue apparently...).
* Now ban_check_types (previously checktype):
this is one or more of BANCHK_* OR'd together, eg BANCHK_JOIN, BANCHK_MSG..
* Now ban_type (previously what2):
this is the type of the ban, eg EXBTYPE_BAN, EXBTYPE_EXCEPT, etc.
* Now is_ok_check (previously is_ok_checktype)
this is one of EXBCHK_* for is_ok, eg EXBCHK_PARAM to check parameter.
already were in extban_conv_param_nuh_or_extban().
The recursion check was already there, but not the "rule 2 violation"
if ((extban->options & EXTBOPT_ACTMODIFIER) || (extban->options & EXTBOPT_NOSTACKCHILD))
This also backs out the temporary fix 5df1b1b889.
which BANCHK_* events you want to listen, eg BANCHK_JOIN, BANCHK_MSG.
You can use BANCHK_ALL to watch on all events.
Only BANCHK_TKL is not included there and needs an explicit
BANCHK_ALL|BANCHK_TKL.
The caller will now take care of BANCHK_* filtering so we won't
waste any CPU on calling an is_banned() function that isn't
interested at all in the event that we have.
Also, no longer require an extban->is_banned function, since some
extbans don't use it. This too saves useless calls.
Currently only supported option is:
BCTX_CONV_OPTION_WRITE_LETTER_BANS: always write letter bans
This removes the NULL pointer magic that i was not happy about.
server to server traffic to be letter extbans.
Yeah this is a tad ugly, but the alternative was worse, see
header of the file for the full story.
Module is loaded by default (obviously).
Still to do: only do this for non-U6 servers (add some PROTOCTL)
And probably alter clean_ban_mask because I don't like the
magic on NULL client at the moment.
configuration file via set::named-extended-bans <yes|no>; and now
defaults to yes.
Still to do:
* explicitly set names instead of using stupid module names
* update test suite to check for these new names (other git tree)
* backwards compatible sending to U5 and lower using ugly shit
The .conv_param() now receives the ban minus the ~own-extban.
And it should also return the part minus the ~own-extban.
Changes to findmod_by_bantype():
1) Takes a string now, rather than a single char value,
so it is ready for named extbans.
2) Second parameter added so you can easily jump to the remainder.
Eg:
extban = findmod_by_bantype(b->banstr, &nextbanstr);
[..check if extban is non-NULL and then..]
b->banstr = nextbanstr;
When extban->is_ok() is called the banstr now no longer points
to "~x:something" but to "something".
Just like we did for extban->is_banned().
Again, need this for later too...
than scattered checks - which are sometimes different - everywhere in
the source code.
Also extban handler "is_ok" was being called with EXBTYPE_EXCEPT
rather than EXBTYPE_INVEX for +I. (Not reported by anyone)
This so I - and others - don't constantly have to wonder whether the client
is called sptr, cptr or acptr in a simple routine.
Insane --> 212 files changed, 6814 insertions(+), 6945 deletions(-)
Couldn't just mass-replace of course since there are places where there
are multiple clients involved. So had to check each function.
Also renamed some 'acptr' to 'target' and such.
I will write a page with new style rules later.. but in short if there is
only 1 client involved it will now be called 'client'.
This so we have a few simple concepts:
Client: this can be a user, server, or something unknown yet
Then the type of clients:
User: this is a user, someone with a nick name.
Server: this is a server
Etc.
aChannel to Channel, and some more. Third party module coders will
love this. But.. it makes things more logical and the doxygen output
will look more clean and logical as well.
(More changes will follow)
Bram Matthys