chunked encoding stuff is copied from the modulemanager and #if'd out.
The non-chunked is not OK yet either, as it must check the Content-Length,
while we currently assume a single packet == the complete request.
These deal with set::anti-flood::everyone::connect-flood and
set::max-unknown-connections-per-ip respectively.
This adds a new hook HOOKTYPE_ACCEPT, that is mostly meant for internal
usage by UnrealIRCd. Most module coders will want to use the existing
hook HOOKTYPE_HANDSHAKE instead.
This also gets of check_banned() which is now spread over the individual
modules (eg: checking banned is done in tkl on HOOKTYPE_ACCEPT and
HOOKTYPE_IP_CHANGE).
So you can just use mask { ip { 127.*; 192.168.*; } } without
having to worry about hostnames like 127.example.net.
(Of course you could also have used CIDR notation)
Another benefit is that, since we are dealing with IP's only,
the matching is faster than going through the more universal
match_user() routine.
clients etc. are expanded in the logging routines.
HOOKTYPE_JSON_EXPAND_CLIENT - for all clients
HOOKTYPE_JSON_EXPAND_CLIENT_USER - for clients that are users
HOOKTYPE_JSON_EXPAND_CLIENT_SERVER - for clients that are servers
HOOKTYPE_JSON_EXPAND_CHANNEL - for channels
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.
This existed in UnrealIRCd 3.2.x but was later removed when
switching to the new operclass system.
Requested by Valware in https://bugs.unrealircd.org/view.php?id=6041
Syntax: SVSO <uid|nick> <oper account> <operclass> <class> <modes> <snomask> <vhost>
All these parameters need to be set, you cannot leave any of them out,
HOWEVER some can be set to "-" to skip setting them, this is true for:
<class>, <modes>, <snomask>, <vhost>
In UnrealIRCd the <operclass> will be prefixed by "services:" if not already
present. It is up to you to include or omit it.
If you want to set any swhoises you need to use the SWHOIS s2s command,
other than that this command basically does everything for you,
in fact it uses the same code as the OPER command does.
Most of the "user is now ircop" code has been moved out of cmd_oper() to
a new function make_oper() that is called by both cmd_oper() and cmd_svso().
This function also changes the hook HOOKTYPE_LOCAL_OPER:
It no longer passes a ConfigItem_oper struct, since we can't do that for
remote opers. Instead it passes oper name and oper class.
The complete definition is now:
int hooktype_local_oper(Client *client, int add, const char *oper_block, const char *operclass);
the rest of the hooks, most of which do not use the past tense.
Only affects HOOKTYPE_USERHOST_CHANGE / HOOKTYPE_REALNAME_CHANGE.
This does, however, make it inconsistent with the userhost_changed()
call, though :D.
It was missing for a lot of extbans (removing too little) and
for ~t it was removing too much (eg quiet bans).
Bug reported and changes suggested by k4be.
Coders:
Setting extban.options to EXTBOPT_CHSVSMODE has no effect anymore,
just didn't want to remove it so modules would still compile.
We now purely match based on .is_banned_events including BANCHK_JOIN.
using mixed UnrealIRCd 5 and UnrealIRCd 6 networks.
This is a slightly complex rewrite of make_mode_str() and do_mode(),
as we nog go from single mode lines to potentially multiple mode lines.
In short: whenever we would be near buffer cut-off point (the famous
512 byte limit) then previously we would prevent the mode, though not
succesfully in all cases where a network consists of mixed 5.x and 6.x.
From this point onward we no longer do that. Instead we convert one
MODE command to two MODE lines if that is needed.
The benefit of this is that we no longer prevent it BEFORE processing
the MODE, which is a flawed method and could be wrong (causing desyncs).
And also, we no longer partially ignore MODE lines from clients when
they would cause the limit to be exceeded, as we replace them with
two MODE lines instead.
These are more changes than I wanted at such a late point but.. they seem
to be necessary to prevent U5-U6 compatibility issues.
to expose to which users and in what detail.
The default configuration is as follows:
set {
whois-details {
basic { everyone full; }
modes { everyone none; self full; oper full; }
realhost { everyone none; self full; oper full; }
registered-nick { everyone full; }
channels { everyone limited; self full; oper full; }
server { everyone full; }
away { everyone full; }
oper { everyone limited; self full; oper full; }
secure { everyone limited; self full; oper full; }
bot { everyone full; }
services { everyone full; }
reputation { everyone none; self none; oper full; }
geo { everyone none; self none; oper full; }
certfp { everyone full; }
shunned { everyone none; self none; oper full; }
account { everyone full; }
swhois { everyone full; }
idle { everyone limited; self full; oper full; }
}
}
Oh, yeah, and for "secure" this also adds displaying of the TLS cipher
in /WHOIS for ircops and self by default. For all others it is limited
to just "is using a Secure Connection".
This also removes the newly added set::geoip::whois-for-anyone since
it is now configured via set::whois-details::geo.
Module coders: HOOKTYPE_WHOIS changed and you may no longer send
directly to the client from this hook. Instead, you should use
add to the NameValuePrioList, usually via the functions
add_nvplist_numeric() and add_nvplist_numeric_fmt().
For inspiration see bot_whois in src/modules/usermodes/bot.c
and reputation_whois in src/modules/reputation.c
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...).
It's usage would be rare, but this is f.e. used from channeldb.
Other uses may be in some 3rd party module.
Example: set_channel_mode(channel, "+k", "key")
* 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.
and used for auditting purposes across servers (assuming the servers
itself can be trusted).
This is done via the 'operlogin' module which is loaded by default.
Obviously for opers of U5 and below this information is not available.
This also changes the HOOKTYPE_LOCAL_OPER hook to include oper block info:
-int hooktype_local_oper(Client *client, int add);
+int hooktype_local_oper(Client *client, int add, ConfigItem_oper *oper_block);
Move checking of +t restrictions to chanmodes/topiclimit.
Move checking for +m restrictions to chanmodes/moderated.
Now the only check remaining in topic is for +b (banned users)
which is fine I think.
We use char *member_modes like we now have at all the other places,
which contains eg "o".
TODO: fix prefix sending rules or remove some if 0'd out code
And not sure if we want to do it entirely this way :D
an extra char **errmsg argument. Upon failure (non zero return value)
this should contain a format string to be sent to the client
(with the return value denoting the number of the numeric).
This gets rid of sendnumeric_legacy() in join.c
It means you can no longer modify eg parv[1] in-place with strtoken and such.
The main reason for this is that as a command handler you have no idea
where the arguments may come from. It could be from a do_cmd() with
read-only storage (eg a string literal) and so on.
It started with an experiment of how far I could get and how annoying the
side-effects would be, but they seem to be quite managable, so I'm
committing this stuff.
Hopefully this catches/solves some stupid bugs somewhere :)
- For HOOKTYPE_LOCAL_JOIN and HOOKTYPE_REMOTE_JOIN: drop parv[] argument
as it was useless anyway, it only contained the channel name in parv[1]
but never the key, sometimes was entirely NULL even.
- For HOOKTYPE_PRE_LOCAL_JOIN instead of char *parv[] we now pass
const char *key. As predicted more than a year ago when fixing
0902ed7a99
Bram Matthys