This is a mandatory module to load, and included in modules.default.conf.
This also meant that the crule_test() etc efunctions are available
before running config test routines, so we now have a flag for
early efuncs. I guess we could consider doing that for all efuncs
though, so not sure if this flag is really needed.
that was added late in 6.1.1 development to fix a crash with removing
websocket listeners. Now replaced with a generic HOOKTYPE_CONFIG_LISTENER
that is not only called for removed listeners, but for all listeners.
a function called start_dns_and_ident_lookup(). This can then
be easily called from other places as well, like the code k4be
did in src/modules/websocket.c to handle proxies.
Side-effect is that ident lookups would now be done, if we are
configured to do so, for forwarded webirc stuff (not that I
think many people use that feature at the moment...).
(or changing the port number). Reported by Nini.
Rather complex case: when the listen block is removed, obviously
the config hooks are not called for the (now non-existing) listen
block, and thus the websocket->request_handler and such are not
set to the new address of the websocket handler.
We now use a slightly silly workaround / new hook to fix this
corner case. Ideally there would be an extra layer in-between
like a handler lookup by name, or something like that.
(Or make the websocket module PERM but we don't want that!)
This so you can use throttling exceptions (eg in ELINE) on hostnames.
That is, the above is during normal circumstances. Similar to previous
commit we will turn this feature of during high connection rates.
That is a TODO item.
This adds user_can_see_member_fast() which is used in at least 3 places
now, more places may follow later. It has extra paramters for membership
and membership modes that is very likely already looked up by the caller
(or if not, it is worth doing so by the caller).
This is work in progress so if everything crashes or people mysteriously
seem not present in channels (or the other way around) i would not be
surprised :D.
When sending to channel members this will cache full IRC protocol
lines, including message tags and \r\n, for similar clients.
This avoid the need for many mtags_to_string() calls and also
entire parts of sendbuf_to_one() can be skipped as well.
The "Similar clients" cache entries are defined as clients that:
1) Are of the same type: normal local client, ircop local client
or remote client.
2) Have the same CAPs set, that is: we only look at CAPs that actually
have anything to do with message tags ('clicaps_affecting_mtag')
3) Optionally there can be an explicit line_opts. It is not used yet
but could be used when there are different type of lines sent
depending on other criteria, such as chanop status or something
else that doesn't fit in #1 and #2.
can be used from +f/+F as an action. You need to specify for which
flood type your mode is, eg `cmode.flood_type_action = 'j';` for joinflood.
Currently a mode can only choose one flood type action due to +f/+F
timer fights that could otherwise occur, but that shouldn't be too
much of an issue since we can live with that in core as well.
This will communicate the original issuer of a command.
For example an "SAMODE #test +s" results in a SAMODE coming from
:maintest.test.net MODE ....etc....
And with this feature, we will communicate the IRCOp who did it:
@unrealircd.org/issued-by=OPER:Syzop..etc....
This tag is only sent to servers and to IRCOps, not to ordinary users.
The plan is to support the following variants:
Services: unrealircd.org/issued-by=SERVICES:NickServ@services.test.net
IRCOp: unrealircd.org/issued-by=OPER:Syzop@maintest.test.net:Operblock_name
JSON-RPC: unrealircd.org/issued-by=RPC:adminpanel@irc1.test.net:Adminpanel_Actual_User
This first commit only adds SERVICES and OPER in the handlers of the
SVSNICK and SAMODE commands. The JSON-RPC variant and all of the other
commands have not been done yet.
This is checked for both local and remote services linking in.
Naturally, the list can be expanded to include more services that
really need ulines { }, and not statistical services or some other
purpose non-unrealircd servers, which is the reason why cannot
blindly assume all non-unrealircd servers require ulines.
This should hopefully help users a lot with "mysterious" issues
with services that we see too often in the support channel.
Suggested in https://bugs.unrealircd.org/view.php?id=5742
Note that this does require services to communicate their software
version via EAUTH. Anope does this for years already, but atheme only
does so since 10 days ago (git only, presumably not released yet)
after Valware filed a PR.
This ensures that strings are of maximum 510 characters in length
and do not contain \n or \r.
Solves a lot of theoretical problems in many modules that .add
things or do other non-list/non-get actions.
This behavior can be turned off per-method (per handler) by setting
handler->flags = RPC_HANDLER_FLAGS_UNFILTERED;
This is currently not done in any of the modules.
since these are rather noisy and generally not very interesting to log.
Of course, DO log them if they are like add/delete/etc.
The way this works is a new property in the RPCHandler, eg:
memset(&r, 0, sizeof(r));
r.method = "server.list";
+ r.loglevel = ULOG_DEBUG;
r.call = rpc_server_list;
if (!RPCHandlerAdd(modinfo->handle, &r))
All of the .list and .get (and things like .module_list) now use
the debug facility, which is not logged by default.
You can still log ALL the JSON-RPC calls if you wish, for example
to a separate file, through something like:
log {
source { rpc; }
destination {
file "rpc.log" { maxsize 100M; }
}
}
* If the remote server (and all servers in-between) support RRPC
then forward the RPC request as RRPC and let remote handle the
response. The response will be the verbose rehash response.
* If not supported, then simply return boolean true as a response,
and use oldskool :source_server REHASH dest_server over the wire
sent over the IRC network. This makes it possible to fetch information
from remote servers that is not known locally, and also it makes it
possible to do more things, or do it easier.
This does require the remote servers to enable RPC as well, though,
eg: include "rpc.modules.default.conf";
(They don't need any listener or rpc-user blocks)
Code-wise it looks nice, like from rpc_server_module_list it is a simple:
/* Forward to remote */
rpc_send_request_to_remote(client, targetserver, request);
This is work in progress. In particular, there is no handling yet of
timeouts (eg if the request to the remote server, or the response
from it takes ages). Nor does it handle the case where the server
quits half-way through the request/response... that is: it does free
the request and such, but does not notify the RPC client about it.
That will need to be added, of course, likely soon.
Over the IRC network this uses the new RRPC command:
:<server> RRPC <REQ|RES> <source> <destination> <requestid> [S|C|F] :<request data>
A request looks like this (assuming it is short):
:001 RRPC REQ 001ABCDEF 002 abc SF :..this is the json request...
And then the response (assuming it is long) is like:
:001 RRPC REQ 001ABCDEF 002 abc S :..this is the json response...
:001 RRPC REQ 001ABCDEF 002 abc C :..more...
:001 RRPC REQ 001ABCDEF 002 abc C :..more...
:001 RRPC REQ 001ABCDEF 002 abc F :..and that was it.
There is currently no request/response limit, it is limited by memory.
Right now the only call using this is server.module_list when called
with a param of "server":"some.remote.server"
RPC clients with the RPC user and such.
Most of this work is for server.rehash which causes the request to
be saved, then a rehash begins, and a few seconds later (or whenever)
the entire rehash log and success/failure is indicated in the
JSON-RPC response.
TODO: all documentation for this
Eg if there are 10.000 users online and you do user.list.
The old websocket framing assumed no response was >64Kb.
This also creates a new function websocket_create_packet_ex()
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];
| ^~~~~~
from the *LINE (or other ban type).
Eg /GLINE %*@192.168.* 0 :Please authenticate using SASL
would now, if the user has authprompt enabled and the connection times
out, exit the client after ~30 secs with "Please authenticate using SASL",
instead of "Registration timeout" (pre 6.0.5-rc2) or
the generic "Account required to login" (6.0.5-rc2).
This to help clients and users who do not type or display anything.
This is an enhancement to https://bugs.unrealircd.org/view.php?id=6202
This also fixes a bug in 6.0.5-rc2 where "Registration timeout" was
always showing up as "Account required to connect", even if there
was no softban or authprompt intervention at all.
This makes websocket_common unload last (and near-last: rpc & websocket)
and makes us call Mod_Init for these three modules first.
This way, the period where the websocket handler is unavailable is kept
to a minimum.
This also renames the ModuleSetOptions option MOD_OPT_UNLOAD_PRIORITY
to MOD_OPT_PRIORITY since it dynamically changes the module priority
in the list. For 6.x compatibility, MOD_OPT_UNLOAD_PRIORITY can still
be used.
This is an easier way to call the next command override handler from command
override functions. It passes the standard parameters so you don't have to
worry about which parameters a CMD_OVERRIDE_FUNC() contains.
This so it is easier to change command parameters in future UnrealIRCd versions,
should it be needed, then it may be possible without any source code changes
on the module developer side.
- CallCommandOverride(ovr, client, recv_mtags, parc, parv);
+ CALL_NEXT_COMMAND_OVERRIDE();
and as it should be IMO. Both for invites by channel ops and for OperOverride.
This also fixes a bug where an IRCOp with OperOverride could not bypass +l
and other restrictions. Only +b and +i could be bypassed.
Module coders: HOOKTYPE_OPER_INVITE_BAN is now gone and HOOKTYPE_INVITE_BYPASS
is now new. The HOOKTYPE_INVITE_BYPASS is called when the user is joining
a channel to which they were invited to. If you return HOOK_DENY there then
the join is still blocked, otherwise it is allowed.
Using this hook would be sortof unusual since usually you would want users
to be able to bypass restrictions when they were invited by another user
or when they invited themselves using OperOverride.
The only example where we use it in UnrealIRCd is for +O channels so an
IRCOp cannot use OperOverride to join +O channels when they would otherwise
not be allowed to do so. Actually even that is a corner case that you could
debate about, but.. whatever.
This also moves some of the adding code (sending notice, broadcasting to
other servers, etc) to a function tkl_added().
We should probably do the same for deletion and not use the tkllayer
anymore for that?
Currently available:
* server_ban.list
* server_ban.get with params: name="*@1.2.3.4", type="kline"
This also adds server_ban_parse_mask() which is now used by both GLINE/etc
and the RPC API to parse the same way and convey the same error messages.
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
Bram Matthys