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.
From: [rpc] Client RPC:adminpanel (Syzop): RPC call channel.set_mode: channel='#test', modes='+b', parameters='some!silly@ban'
To: [rpc] RPC call channel.set_mode by RPC:adminpanel (Syzop): channel='#test', modes='+b', parameters='some!silly@ban'
This so the most important information is shown first (generally a good principle :D)
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
Bram Matthys