Reported by Adanaran in https://bugs.unrealircd.org/view.php?id=5698
Although voiced users normally bypass bans, it is not really logical
for them to bypass filtering of banned words, since that is normally
a policy decission by channel management. So +v will not bypass it.
1) The problem is that this is enforced at the ban layer API. The extban
routines, textban in this case, are not called when the user is voiced,
because voiced users bypass bans. If we would change that in the ban API
then voiced users can also no longer talk through (=bypass) regular +b or
other extended +b such as ~a (account) etc.
2) I figured we would then make +T not use the ban API but the
can_send_to_channel hook instead. However, then you have to do manual
looping through bans and such, it's rather ugly from a coding point of view,
and you risk "missing" things like ~T stacked with ~t.
3) Then I went back to look if the ban API could be changed by having the
textban module set a flag and then the ban api would call that specific
module still for voiced users. While starting on that, unfortunately things
(variables, arguments) cascaded quickly into having to change all kinds of
underlying functions that would break the module API.
4) I then went back to option 2 and implemented it, trying to deal
with all its caveats.
reported by Koragg in https://bugs.unrealircd.org/view.php?id=5757.
This changes the following in the code of who_global():
1) We initialize all the 'marked' users to zero at the beginning,
and remove the previously unmarking in the bottom loop that
shouldn't have anything to do with it. Now there's "no way"
to screw up initialization of marked users.
2) Check for marked users in the bottom loop.
3) Thanks to #1 and #2 we can now easily add simple logic like
not skipping when client==acptr.
4) Similarly, we can remove checks for +i/-i in who_common_channel(),
and as a bonus we will list common channel results altogether
in the WHO result, rather than first +i on common and then at the
very end the remaining -i (which may also be in common channels).
All in all, the code is now more like how I would write it, rather
than the original. It's now harder to screw things up if you change
some visibility or searching logic here or there.
numbers only. This makes things more logical for end-users.
This fixes https://bugs.unrealircd.org/view.php?id=5746,
bug reported by KindOne.
The same issue was also fixed by previous commit, but still:
it is better to limit things to a narrower range, this so you
don't get different behavior depending on the CPU a server uses.
This adds support for latvian-utf8, estonian-utf8 and lithuanian-utf8
in set::allowed-nickchars. Patch from moseslecce.
Co-authored-by: David Lecce <3292014+davidlecce@users.noreply.github.com>
set::history::channel::playback-on-join::lines and
set::history::channel::playback-on-join::time were ignored,
the limit in the +H channel mode was used instead.
Reported by k4be in https://bugs.unrealircd.org/view.php?id=5707
depending on the module load order. Reported by k4be.
Changes:
* Websocket hooks:
* Input should be run first
* Output should be run last
* Labeled-response also had various hook priorities wrong
* Pre command should be run near-first
* Post command should be run near-last
* Close connection (does the flush) should be run near-last
* Packet should be run near-last
set {
anti-flood {
target-flood {
channel-privmsg 45:5;
channel-notice 15:5;
channel-tagmsg 15:5;
private-privmsg 30:5;
private-notice 10:5;
private-tagmsg 10:5;
};
};
};
Max 45 messages in 5 seconds means max 540 messages per minute,
with a peak of (surprise) 45 messages per 5 seconds...
That should be sufficient for every legit channel, right?
How can you chat if you get more than 9msgs/sec for 5 seconds straight?
Maybe I am even too liberal with these limits?
NOTICE and TAGMSG get lower limits because they are far less used
and have other concerns (eg: ringing a bell for NOTICE).
The default limits may be changed in later versions of UnrealIRCd
based on feedback and more insight in (big) channel rates.
Also, remove unnecessary comment about calling lr_post_command() with
the last two arguments being NULL. We don't use these two variables
inside lr_post_command() after this change anyway.
Then the oper may decide if the original entry should indeed be
removed and re-added, or if (s)he should not touch it. These are
usually done by mistake anyway.
Updating existing entries by end-users was never intended and did
not work properly anyway (see bug comments). Issue reported by
Le_Coyote and armyn in https://bugs.unrealircd.org/view.php?id=5603
This had to do with the queued packet (in the labeled-response module)
not being sent because the client was freed before the
post packet hook was called.
any parameter channel mode module loaded after channeldb.
Reported by GaMbiTo, with help from PeGaSuS, Gottem and k4be
in https://bugs.unrealircd.org/view.php?id=5669
It is not safe to call channel mode parameter functions when
unloading modules. Makes sense I think.
We now no longer write the db on rehash, which is something i
didn't like anyway (wasted CPU cycles). The problem was that
one could not just scratch the write db call, as otherwise if
someone rehashes every minute would cause the db never to
be saved. This is because on each rehash the event to write
the db gets rescheduled to +5 minutes in the future.
We now work around that in the same way as connthrottle does.
Obviously it would be better to make the event system itself
deal with this, but that is (way) too much for now.
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.
Bram Matthys