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();
Also rename them to describe better what they do.
ConfigFile:
cf_filename -> filename
cf_next -> next
cf_entries -> items
ConfigEntry:
ce_fileptr -> file
ce_varlinenum -> line_number
ce_fileposstart -> file_position_start
ce_fileposend -> file_position_end
ce_sectlinenum -> section_linenumber
ce_varname -> name
ce_vardata -> value
ce_cond -> conditional_config
ce_entries -> items
ce_next -> next
ce_prevlevel -> parent
Also add doxygen docs for both structs.
* There are two security groups by default: known-users and unknown-users.
See https://www.unrealircd.org/docs/Security-group_block
* New extended ban ~G:securitygroupname, with the typical usage being
MODE #chan +b ~G:unknown-users, which will ban all users from the
channel that are not identified to services and have a reputation
score below 25.
This is the work from May 3rd.. need to commit it so i can merge the
flood protection that is related to this...
The final implementation will still need tweaking before pushed.
[skip ci]
no connect-delay restriction. Also remove the 'disable' option since
it is unneeded. You now simply use:
set {
restrict-commands {
somecommand {
}
}
}
...and the command is disabled.
And you add exempt-identified or exempt-reputation-score if needed.
See https://www.unrealircd.org/docs/Set_block#set%3A%3Arestrict-commands
Note that this also changes some command blocking logic, so I hope
I made no mistake there... only testing will tell.
Add new config option "exempt-webirc yes;" in set::restrict-commands::<commandname> in order to give exceptions in all WEBIRC user. This closes one of the 3 suggestions in https://bugs.unrealircd.org/view.php?id=5506
CAN_SEND_TO_USER rather than HOOKTYPE_PRE_USERMSG (which is now removed).
As for the numeric change: this makes it much easier for client devs.
You rarely need to differentiate in the client code between the various
causes. One only cares about detecting that the message was not sent and
that the user needs to be informed.
This replaces various NOTICEs, ERR_NOCTCP, ERR_NONONREG etc. with just the
new numeric 531, which is taken from InspIRCd. The syntax is:
:server 531 yourname targetname :reason for the block
This makes it similar to numeric 404 (ERR_CANNOTSENDTOCHAN) that is used to
indicate that a channel message was blocked.
For module devs, the new hook CAN_SEND_TO_USER prototype is:
int hooktype_can_send_to_user(Client *client, Client *target, char **text, char **errmsg, int notice);
You can replace the text via this, by setting *text in your function.
You can block the message, by returning HOOK_DENY. If doing so, then
you must also set *errmsg to an appropriate value.
Do not send any error message to the user! UnrealIRCd will take care of
sending the error message for you, if you set *errmsg.
Only if you need something special you could violate this rule, but
preferably not!
As you can see, CAN_SEND_TO_USER works just like CAN_SEND_TO_CHANNEL.
1) HOOKTYPE_CAN_SEND is now called HOOKTYPE_CAN_SEND_TO_CHANNEL
The arguments and return values are unchanged
2) similarly can_send() is now called can_send_to_channel()
3) If you want to block or alter a message you must now
use HOOKTYPE_CAN_SEND_TO_CHANNEL and return HOOK_DENY from
there with an appropriate *errmsg filled (see nocolor and
many other modules for an example)
4) You CANNOT use HOOKTYPE_PRE_USERMSG anymore to block a message.
I actually wanted to rip this hooktype out entirely, but
delayjoin needs it. HOOKTYPE_PRE_USERMSG is only useful for
notification that a message is going to be sent BEFORE it is
actually sent (which is exactly what delayjoin needs, so it
can send a JOIN if the user is currently invisible).
5) This is all to make things more clean:
* HOOKTYPE_PRE_USERMSG is only for delayjoin
* HOOKTYPE_CAN_SEND_TO_CHANNEL is used for exactly what the
name implies. You can also change the message text there,
such as for +G, +S, etc.
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'.
code changes in UnrealIRCd itself:
1) Clients are no longer freed directly by exit_client. Most fields
are freed, but 'sptr' itself is not, so you can use IsDead() on it.
2) exit_client now returns void rather than int
3) ALL command functions return void rather than int.
Of course this also affects do_cmd, command overrides, etc.
This is a direct consequence of the removal of 'cptr' earlier, as that
was used to signal certain things that are now no longer possible
(and it raises the question if things were always correctly signaled
in the first place, so may fix some bugs).
It also makes the code more resillient against cases where you forgot
to check if the client was freed. Still, you are encouraged to do an
IsDead(sptr) if you are calling functions that may kill clients,
such as command functions or things that may use spamfilter.
More changes will follow, such as the removal of FLUSH_BUFFER.
'sptr' is sufficient and in most cases the only one you should care about.
Should you need it, you can access sptr->direction in cases where you
need the old information (usually only for some sendto_* functions
and some protoctl checks), so 'cptr' was redundant too.
[!] This change likely introduces some bugs. This was many hours of work.
I only cut some corners in 4 functions, which will be fixed at a later
stage..... yes, more major changes to come.
On the plus side, I likely fixed some bugs in the process. Situations
where cptr vs sptr usage was incorrect. Eg using cptr->name (near server)
when sptr->name should be used (the actual source server), etc....
MOD_UNLOAD. And MOD_HEADER(xyz) is now MOD_HEADER even without ()
since this isn't a function, really.
To make things understandable I added the following to the
developer section of the release notes:
* The module header is now as follows:
ModuleHeader MOD_HEADER
= {
"nameofmodule",
"5.0",
"Some description",
"Name of Author",
"unrealircd-5",
};
There's a new author field, the version must start with a digit,
and also the name of the module must match the loadmodule name.
So for example third/funmod must also be named third/funmod.
* The MOD_TEST, MOD_INIT, MOD_LOAD and MOD_UNLOAD functions no longer
take a name argument. So: MOD_INIT(mymod) is now MOD_INIT()
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.
including things like CallCmdoverride() to CallCommandOverride().
Type changes like aTKline -> TKL and many more (in particular
aSomething to Something etc. such as aWatch to Watch) but these are
less used by 3rd party module coders.
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)
and remove old dependency field (never used, was always NULL,
broken since 3.2.x)
I'll add some constraints later on things like names and versions.
IOTW: more changes to follow, don't mass update your own mods yet.
so you can use set::restrict-commands without having to loadmodule.
Restrict the LIST and INVITE commands in the example.conf, which is
often a good idea. Finally, document the configuration/usage at:
https://www.unrealircd.org/docs/Set_block#set::restrict-commands
Bram Matthys