This so multiple parallel requests can be handled properly.
JSON-RPC over websockets is unchanged, as every JSON-RPC
requests goes into its own websocket frame there (easy).
This will communicate the original issuer of a command.
For example an "SAMODE #test +s" results in a SAMODE coming from
:maintest.test.net MODE ....etc....
And with this feature, we will communicate the IRCOp who did it:
@unrealircd.org/issued-by=OPER:Syzop..etc....
This tag is only sent to servers and to IRCOps, not to ordinary users.
The plan is to support the following variants:
Services: unrealircd.org/issued-by=SERVICES:NickServ@services.test.net
IRCOp: unrealircd.org/issued-by=OPER:Syzop@maintest.test.net:Operblock_name
JSON-RPC: unrealircd.org/issued-by=RPC:adminpanel@irc1.test.net:Adminpanel_Actual_User
This first commit only adds SERVICES and OPER in the handlers of the
SVSNICK and SAMODE commands. The JSON-RPC variant and all of the other
commands have not been done yet.
instead of the server executing the MODE. Eg unrealircd.org/userhost
was set. This occured because the client = &me; was done after
the message tag preparation, now moved up so it's done before.
See release notes:
+* The RPC modules are enabled by default now. This so remote RPC works
+ from other IRC servers for calls like `modules.list`. The default
+ configuration does not enable the webserver nor does it cause
+ listening on any socket for RPC, for that you need to follow the
+ [JSON-RPC](https://www.unrealircd.org/docs/JSON-RPC) instructions.
[skip ci]
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
This is an integer which decides the amount of details in the response object.
See https://www.unrealircd.org/docs/JSON-RPC:User#Structure_of_a_client_object
Especially for user.list it can be a good idea to ask for less detail if
you don't need all the information. It's up to you...
When 'object_detail_level' is not specified in the request, then:
* For user.list it defaults to 2, which is a "breaking change" in the sense
that it leaves out the "channels" field. To see the "channels" field you
would have to use level 4.
* For user.get it defaults to 4, which results in the same output as 6.0.7.
* This makes sense so user.list is shorter than user.get, just like we
already did in channel.list and channel.get.
By the way, this is all documented in the API calls at
https://www.unrealircd.org/docs/JSON-RPC:User
and for channels at https://www.unrealircd.org/docs/JSON-RPC:Channel
This also changes the Detail level (object_detail_level) for the channel.* calls.
See https://www.unrealircd.org/docs/JSON-RPC:Channel_Object for latest info.
In short: at level 5, we now still hide the members.user.channels because
in general that object is not useful. When you do a channel.* API call
you want a list of users in the channel, and don't really care about
what other channels the user is in, other than the channel you already know.
This is an integer which decides the amount of details in the response object.
For the channel.* calls the object_detail_level is one of:
0: only return the channel name, nothing else
1: basic channel information only
2: this adds bans, ban_exemptions, invite_exceptions
3: also show members, but only level/name/id
4: also show members, level/name/id/hostname/ip/details/geoip
5: also show members, level and full user details like user.get
When no object_detail_level is specified, the following defaults are used:
For channel.list the default is 1 (matches current 6.0.6 behavior)
For channel.get the default is 3 (matches current 6.0.6 behavior)
Using channel.list with object_detail_level=5 is forbidden because
it would cause way too much output (and processing time).
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.
for OpenSSL 1.0.2 anymore, 1.0.2 will use the fallback version.
This changes the include file.
(OpenSSL 1.0.2 is out of support since Jan 1 2020 so one may wonder
why care at all, but i'm trying not to break that during minor
UnrealIRCd releases)
the realhost/IP is communicated on a separate line. This so you now
can see both vhost/cloakedhost and realhost as an IRCOp in a single
WHOWAS request.
This also adds the MAXLINELENGTH define which is set to 4K+4K+512,
it can be used when you are dealing with complete lines (quite rare
in the code, mostly in socket code and labeled response).
And now also #define READBUFSIZE MAXLINELENGTH
but it is used beyond read buffers, als in write buffers of course.
Bram Matthys