not always kicking in on *line either.
We now check for shuns/*lines in user_account_login(), so upon
SASL or NS IDENTIFY etc. This also means that the client could
now be killed in that function, so callers should take extra
care and take that into account. We check for IsDead() in our
calls now (if it's our client anyway).
Hopefully this doesn't break anything.........
I forgot to include message tags earlier, so this is a breaking change:
-int hooktype_local_nickchange(Client *client, char *newnick);
-int hooktype_remote_nickchange(Client *client, char *newnick);
+int hooktype_local_nickchange(Client *client, MessageTag *mtags, char *newnick);
+int hooktype_remote_nickchange(Client *client, MessageTag *mtags, char *newnick);
Be sure to update your hooks!
You can use something like: #if UNREAL_VERSION_TIME>=202115
The new display field is called 'R', use something like:
WHO * %cuhsnfmdaRr
At the moment only "displaying" is available and not "searching"
on reputation. If you need that, you're stuck with the /REPUTATION
command at the moment. Too much hassle to implement that.
About reputation: https://www.unrealircd.org/docs/Reputation_score
the spamfilter. Only after a rehash it showed the me::name as the
setter. From now on we just display -config- in the setter field,
like we do for all the other TKLs as well (ELINE, ban xyz, etc).
if running multiple ircds from the same directory you sometimes get
weird messages otherwise (not that we really support such a thing
but i use it while dev'ing).
Not reported by anyone, but yeah.. who knows there is someone out there
that does this :D.
Also make it work the same like channeldb by spreading the event.
notices to IRCOps and in ircd.log.
See the release notes for more details.
Module coders:
You can use HOOKTYPE_CONNECT_EXTINFO to add your own additional
information as well. See get_connect_extinfo() for inspiration.
Use nvplist_add() or nvplist_add_fmt() to easily add your info
to the list.
Module coders II:
Small note: this moves the sending of the far connect notice
to /under/ HOOKTYPE_REMOTE_CONNECT instead of /above/.
The handshake delay exists so results from DNSBL's can be checked before
the user is fully online. Whenever someone is exempt from DNSBL checking
it serves no purpose, so we mark it that the user has no handshake delay.
This will speed up connecting by up to 2 seconds (by default).
Also updated WebIRC example to suggest this now:
https://www.unrealircd.org/docs/WebIRC_block#UnrealIRCd-side
The exempted ban types are only ones that will affect other connections as well,
such as gline, and/but not policy decissions such as bypassing qlines or maxperip.
Currently the list is: gline, kline, gzline, zline, shun, blacklist,
connect-flood, unknown-data-flood.
Suggested by PeGaSuS and others in https://bugs.unrealircd.org/view.php?id=5806
Previously it rejected ! for all type of *LINES to avoid users
making the mistake of banning nick!user@host in a *LINE.
Note that for non-extended-server-bans the ! is still forbidden.
* 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.
It is highly recommended that services pseudo users all have +o since
there are likely many places where ULines don't bypass a restriction while
opers do. But still, this particular issue has been fixed, it caused
unexplained loss of messages which looked rather mysterious.
Reported by severinmueller in https://bugs.unrealircd.org/view.php?id=5799
The reputation command (IRCOp-only) has been extended to make it
easier to look for potential troublemakers:
* ```REPUTATION Nick``` shows reputation about the nick name
* ```REPUTATION IP``` shows reputation about the IP address
* ```REPUTATION #channel``` lists users in channel with their reputation score
* ```REPUTATION <NN``` lists users with reputation scores below value NN
to the specified number of lines. This defaults to 1000.
This will prevent IRCOps from being flooded off ("Max SendQ exceeded")
if they list all *LINES and there are thousands.
In the newly introduced error message, after too many matches,
we also kindly point out to use filters like '/STATS gline +m *.nl'
by armyn in https://bugs.unrealircd.org/view.php?id=5769.
The default behavior in 5.x is to continue matching:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*; password "iwantmore"; class clients; maxperip 10; }
This so users who provide a password get additional rights,
such as a higher maxperip or a different class, etc.
If the user connects without a password then we simply continue
to the next block and use the general block with only 2 maxperip.
However, some people want to use passwords to keep other users out.
That is entirely understandable as it is an 'allow block' after all.
For example:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*.nl; password "tehdutch"; class clients; maxperip 2; options { reject-on-auth-failure; } }
In this case anyone without the correct password will be rejected access.
if someone searches explicitly on a nick name and that user exists.
This fixes a bug where doing '/who name a' would return only 1 result
if 'name' exists as a nick, even though multiple people with the
same account 'name' are online and visible to the user, as
reported in https://bugs.unrealircd.org/view.php?id=5761 by Koragg.
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.
Bram Matthys