For example: +e ~flood:*:~account:TrustedBot
Suggested by PeGaSuS in https://bugs.unrealircd.org/view.php?id=6204
Will refine the checking and perhaps sorting of floodtype(s) later...
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.
These were already not counted for set::anti-flood::xx::nick-flood
and it makes sense.
Benefit of this is that limits for floodtype 'n' can be set tighter,
as now it is really only about manual (voluntarily) nick changes.
for this amount of seconds (default: 75) when a server splits.
This helps in case a server dies and the clients reconnect to the
other servers, causing a join-flood to be triggered needlessly.
Of course, OTOH disabling a flood protection temporarily is not
ideal, but after seeing it being triggered too often and requiring
manual intervention in many +f/+F channels, this is the best option
I think, if we want +f/+F to work as painless as possible.
If you have a large network (eg: >5 servers) with equal user
spreading then you could disable this by setting it to 0, since then
1 server dieing may not have enough impact on +f join floods
for this to be needed.
TODO: Documentation and release notes
Actually it accepts the following variations for this query:
MODE #test f
MODE #test +f
MODE #test F
MODE #test +F
As long as it is like that (with no parameter) we will show details.
Details are shown for all of the four possible combinations of having
or not having +f and +F.
For example "+F normal" and "+f [1k,20t]:10" result in this output:
Channel '#test' uses flood profile 'normal', without action(s) 'k' as they are overridden by +f.
Effective flood setting via +F: '[7c#C15,30j#R10,40m#M10,10n#N15]:15'
Plus flood setting via +f: '[1k,20t]:10'
-
List of available flood profiles for +F:
none: []:0
very-relaxed: [7c#C15,60j#R10,10k#K15,90m#M10,10n#N15]:15
relaxed: [7c#C15,45j#R10,10k#K15,60m#M10,10n#N15]:15
normal: [7c#C15,30j#R10,10k#K15,40m#M10,10n#N15]:15
strict: [7c#C15,15j#R10,10k#K15,40m#M10,10n#N15]:15
very-strict: [7c#C15,10j#R10,10k#K15,30m#M10,10n#N15]:15
See also https://www.unrealircd.org/docs/Channel_anti-flood_settings
When a channel CTCP flood happens and there is an +f with the 'c' floodtype,
we set channel mode +C by default. Alternative action possiblities
were +m and +M. I don't think anyone really used those alt actions for CTCP
because makes little sense to set the channel +m/+M on a CTCP flood when
there is +C which has far less impact.
More important, the fact that +m/+M could be set both upon CTCP flood
and upon message flood, this 'dual timer' thing, makes it rather
complex when we now have both +f and +F, so easiest solution is just
to scratch this possibility :)
if the join flood is caused by >75% of "unknown-users". This
to see if that will take care of the flood without harming
the "known-users" group. And naturally, do something similar
for message floods and nick floods.
If the flood persists, because they are caused by known-users,
then the +i/+m/etc actions are still taken.
This is work in progress, and some things are set to useful-
for-testing values, such as an unsettime of 1 minute.
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.
thus the 'unset time' would be stripped.
This was because the timedban module was seen as 'unavailable' when
checking the +f syntax so early in the booting process.
We now assume timedban is available during config testing, if it later
turns out it is not available the 'unset time' is still stripped
when setting the mode on JOIN.
Reported by ctcp.
Reported by Jaka in https://bugs.unrealircd.org/view.php?id=6077 and
Valware and buayadarat in https://bugs.unrealircd.org/view.php?id=6078
This commit also makes the halfop rules for +h/-h match the ones in U5:
Previously in 6.0.0 - 6.0.2 it was:
* halfops can set +h on others
* halfops cannot set -h on others
* halfops can set -h on themselves
Now in 6.0.3+ it matches 5.x behavior again:
* halfops cannot set -h or +h on others
* halfops can set -h on themselves
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.
* 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.
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.
This also changes the remove_user_from_channel() function to have an
extra parameter to hide it from logs. This is used for KICK (already
logged) and QUIT (which would be stupid to generate 10 part log lines for).
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
Bram Matthys