for the add, like: nick-change, quit, server terminating. Add logon time.
I also think i will move from user.get_whowas to a whowas.XXX since the
returned object is not a user object and getting more different each commit :D.
This way things like the TOPIC will keep their color codes if they have it.
Reported by armyn in https://bugs.unrealircd.org/view.php?id=6259
(And yeah i used a global to achieve this, otherwise it has too much
of a cascading effect in XYZ functions)
It also has an object_detail_level like some other calls.
The "top_countries" are included from object_detail_level 1 and above.
The default object_detail_level is actually 1, so it is included by
default. You can use object_detail_level if you don't want it.
Idea for this was from Valware.
https://www.unrealircd.org/docs/JSON-RPC:Stats#stats.get
will be updated in a minute...
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 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 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).
This ensures that strings are of maximum 510 characters in length
and do not contain \n or \r.
Solves a lot of theoretical problems in many modules that .add
things or do other non-list/non-get actions.
This behavior can be turned off per-method (per handler) by setting
handler->flags = RPC_HANDLER_FLAGS_UNFILTERED;
This is currently not done in any of the modules.
since these are rather noisy and generally not very interesting to log.
Of course, DO log them if they are like add/delete/etc.
The way this works is a new property in the RPCHandler, eg:
memset(&r, 0, sizeof(r));
r.method = "server.list";
+ r.loglevel = ULOG_DEBUG;
r.call = rpc_server_list;
if (!RPCHandlerAdd(modinfo->handle, &r))
All of the .list and .get (and things like .module_list) now use
the debug facility, which is not logged by default.
You can still log ALL the JSON-RPC calls if you wish, for example
to a separate file, through something like:
log {
source { rpc; }
destination {
file "rpc.log" { maxsize 100M; }
}
}
including Lord255, armyn and others.
The issue was not there when running with ASan, which is why it
was non-reproducible for so long. Valgrind picked it up correctly.
The bug was that in rpc_response() and rpc_error() I do:
id = json_object_get(request, "id");
[..]
json_object_set_new(j, "id", id);
which is wrong, since json_object_get() "borrows the reference"
and json_object_set_new "steals the reference".
In this particular case it should be:
json_object_set(j, "id", id);
Fixed in both functions. Would have to audit the code if the mistake
is made elsewhere too though. On first sight, it seems not.
* If the remote server (and all servers in-between) support RRPC
then forward the RPC request as RRPC and let remote handle the
response. The response will be the verbose rehash response.
* If not supported, then simply return boolean true as a response,
and use oldskool :source_server REHASH dest_server over the wire
remote server does not have the JSON-RPC module(s) loaded.
Internally this uses the "rrpc" moddata property that each server will
now set on themselves if the rpc/rpc module is loaded.
Actually I am going to make this more verbose and better later...
(Required RPC modules to be loaded on the remote server, tho)
This adds support for remote async RPC requests that take a little longer,
in such a case we don't call free_client() upon return of rpc_call().
Bram Matthys