* 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().
Inform the RPC client that the request timed out / server is gone.
The timeout is fixed at 15 seconds, which is fine, I think.
New rpc error codes:
JSON_RPC_ERROR_SERVER_GONE = -32001, /**< The request was forwarded to a remote server, but this server went gone while processing the request */
JSON_RPC_ERROR_TIMEOUT = -32002, /**< The request was forwarded to a remote server, but the request/response timed out (15 seconds) */
Unfortunately we cannot say for sure the action did not succeed at all.
It could be that the request never reached the server, but it could also
be that the request DID reach the server and we timed out during
retrieving the response. Nothing we can do about that.
sent over the IRC network. This makes it possible to fetch information
from remote servers that is not known locally, and also it makes it
possible to do more things, or do it easier.
This does require the remote servers to enable RPC as well, though,
eg: include "rpc.modules.default.conf";
(They don't need any listener or rpc-user blocks)
Code-wise it looks nice, like from rpc_server_module_list it is a simple:
/* Forward to remote */
rpc_send_request_to_remote(client, targetserver, request);
This is work in progress. In particular, there is no handling yet of
timeouts (eg if the request to the remote server, or the response
from it takes ages). Nor does it handle the case where the server
quits half-way through the request/response... that is: it does free
the request and such, but does not notify the RPC client about it.
That will need to be added, of course, likely soon.
Over the IRC network this uses the new RRPC command:
:<server> RRPC <REQ|RES> <source> <destination> <requestid> [S|C|F] :<request data>
A request looks like this (assuming it is short):
:001 RRPC REQ 001ABCDEF 002 abc SF :..this is the json request...
And then the response (assuming it is long) is like:
:001 RRPC REQ 001ABCDEF 002 abc S :..this is the json response...
:001 RRPC REQ 001ABCDEF 002 abc C :..more...
:001 RRPC REQ 001ABCDEF 002 abc C :..more...
:001 RRPC REQ 001ABCDEF 002 abc F :..and that was it.
There is currently no request/response limit, it is limited by memory.
Right now the only call using this is server.module_list when called
with a param of "server":"some.remote.server"
so we can deal with empty fields that get sent f.e. by anope,
like EAUTH=services.test.net,,,Anope-2.0.11
Apparently this is similar to strsep(), or actually hypothetical
strsep_r(), a function which does not seem to exist.
(directly connected server only at the moment)
This also cleans up the linking procedure (now) at 3 places,
to use find_link() and check_deny_link() everywhere.
RPC clients with the RPC user and such.
Most of this work is for server.rehash which causes the request to
be saved, then a rehash begins, and a few seconds later (or whenever)
the entire rehash log and success/failure is indicated in the
JSON-RPC response.
TODO: all documentation for this
This bug exists since 5.2.1 already, so i guess the functionality is
not used much ;). Makes sense, since for simple ~account:* you have +R already,
so it is only useful in stacked bans such as +e ~nickchange:~account:*
We now have a test case so that this bug won't "ever" reoccur.
Reported by rafaelgrether in https://bugs.unrealircd.org/view.php?id=6211
so in name_ban, server_ban, server_ban_exception and spamfilter.
This could be used, for example, by an admin panel to tell which
end-user that authenticated to the panel (eg 'OperX') added/removed
the TKL, instead of showing up as 'RPC:xyz' in the logs and bans.
This gets rid of duplicate code in SETIDENT, CHGIDENT, and soon
in the RPC call. It does not get rid of make_valid_username()
in src/modules/nick.c which does something slightly different.
I don't think it should return the whole channel struct here as if it
was a channel.get. Only thing is that, especially or only with set_mode,
it may actually be 100% success... eg if your mode line is wrong :D.
Also bump API versions on user.* and channel.*
This also makes the "forced nick change" message a bit more
generic, leaving out the "by services" or "due to Services",
since it is now possible to do it via JSON-RPC.
as requested in https://bugs.unrealircd.org/view.php?id=6206
And also for channel.get, in "members", include the UID in "id".
This breaks the current format but we don't have many users yet anyway.
Something tells me that will happen more ;)
This also bumps the user and channel RPC modules from 1.0.0 to 1.0.1
In user.get (and currently user.list too) this shows as:
"channels": [
{
"name": "#test",
"level": "o"
}
]
And in channel.get (not .list) this shows as:
"members": [
{
"name": "abc",
"id": "00129BP02",
"level": "o"
},
{
"name": "def",
"id": "001LFMB05"
}
]
keep them open, but do a websocket ping/pong to check if the
connection is alive.
This is usually handled by browsers themselves, but if you are using
websockets from a non-browser then you may have to PONG back on
a PING, see https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2
(note that PING-PONG is a requirement there)
Eg if there are 10.000 users online and you do user.list.
The old websocket framing assumed no response was >64Kb.
This also creates a new function websocket_create_packet_ex()
Bram Matthys