Based on previous reports and patches from k4be in
https://github.com/unrealircd/unrealircd/pull/129
Looks much cleaner now.
This also filters out the edge case where user_account_login()
could have been called when a user transitioned from "not logged in"
to "unconfirmed account". It did not cause any issues AFAICT but
it is not really expected either.
that only set +r on people. To my knowledge, practically no services are
out there anymore that do not use proper SVIDs (and that can link with
UnrealIRCd 5).
services account.
This adds set::authentication-prompt::unconfirmed-message with
a default of:
unconfirmed-message "You are trying to use an unconfirmed services account.";
unconfirmed-message "This services account can only be used after it has been activated/confirmed.";
See https://www.unrealircd.org/docs/Set_block#set::authentication-prompt
Note that this is only shown for services which allow SASL from
unconfirmed services account in the first place, like atheme.
Anope does not allow it, which is something that could very well
be considered 'correct' as well. In that case you would simply
get the "Authentication failed" message instead
(set::authentication-prompt::fail-message).
I would like a bit more room for this in the future,
but until then we will keep sending UIDs of length 9 in
server to server traffic, so no change at all.
https://bugs.unrealircd.org/view.php?id=5925
This does two things in cmd_uid() now:
* It checks if parameter 6 in UID is a valid UID, using valid_uid()
* It checks if the first 3 characters of the UID match the SID
Modules can still opt-in via mreq.remote_write=1 to allow it for
certain moddata.
For example, k4be may want to do this for his geoip-base module which
allows a single server to set moddata "geoip" for all connecting clients,
including remote clients.
If you are a moddata provider then you can enable it like this:
ModDataInfo mreq;
[..]
#if UNREAL_VERSION_TIME >= 202125
mreq.remote_write = 1;
#endif
[..]
See discussion on https://github.com/unrealircd/unrealircd/pull/142
This also allows known-users to execute slightly more commands per second.
For people who want their trusted users/bots to allow even more commands
per second (eg 20cmds/sec) we now have a nice FAQ item that uses this:
https://www.unrealircd.org/docs/FAQ#high-command-rate
* New block [set::server-linking](https://www.unrealircd.org/docs/Set_block#set::server-linking)
* For link blocks with autoconnect we now default to the strategy
'sequential', meaning we will try the 1st link block first,
then the 2nd, then the 3rd, then the 1st again, etc.
* We now have different and lower timeouts for the connect and
the handshake. So we give up a bit more early on servers that
are currently down or extremely lagged.
set {
server-linking {
autoconnect-strategy parallel;
connect-timeout 10s;
handshake-timeout 20s;
}
}
Right now the only autoconnect-strategy is 'parallel', which is simply
the existing behavior since 4.x. A future commit will add other
strategies and may or may not change the default as well.
The bit that is working already is that you can now specify different
timeouts for the connect()/TLS_connect() call and for the rest of
the handshake (when the "SERVER" message is seen), this so the connect
timeout can be relatively short.
All this will be documented later in the wiki and release notes.
They were already ignored in MODE by remote UnrealIRCd servers,
but this makes it so local modes (+Z and +d at the moment)
are not sent across the wire.
This also changes the channel_modes() function to have an additional
'hide_local_modes' argument. Set this to 1 if you are building a
buffer that will be sent to remote servers, otherwise use 0,
which is far more common.
Also, this will skip saving of local channel modes to channeldb
since all of these are temporary, or at the moment anyway.
Thanks to alice for reporting this bug and providing a good test
case to help fix this issue and the previous ones.
~a:0: match all unauthenticated users
~a:*: match all authenticated users
~a:SomeUser: match only SomeUser, also allow wildcards here, even
though that is usually a very bad idea :D
- If you have only negating entries, like '!abc' and '!def', then
we assume an implicit * rule first, since that is clearly what
the user wants.
- If you have a mix, like '*.com', '!irc1*', '!irc2*', then the
implicit * is dropped and we assume you only want to match *.com,
with the exception of irc1*.com and irc2*.com.
- If you only have normal entries without ! then things are
as they always are.
This patch also makes the behavior for unreal_mask_match() and
unreal_mask_match_string() the same.
If you had a spamfilter on type 'c' but not on 'p' then it would not
trigger. Reported by armyn in https://bugs.unrealircd.org/view.php?id=5913
This probably went unnoticed because most people add spamfilters
on 'pc' (or even 'pcnN').
Reported by Ariadne Conill in https://bugs.unrealircd.org/view.php?id=5906
This patch applies cleanly against 5.2.0-rc1 and 5.0.9.x.
Needs more testing, though, as fiddling with SQUIT code and the
various directions and far/near server distinctions can be tricky.
Bram Matthys