RPC guide (Work in progress)

A warning

If you ever expose RPC to the public, you should either add a middleware/proxy to filter out dangerous commands, or adjust your firewall to discard unknown server requests.
All popular lightwallet backends need to have accessible transactional data, so they use the proxy approach, for example "getcanoe/canoed", "cronoh/nanovault-server" and "nano-wallet-company/nano-wallet-server".
I made a standalone reference implementation for a filter in PHP . Just keep in mind that not all hosters have CURL enabled for PHP.

Setting up RPC in a Docker node

The config.json is already pre-set with everything you will probably need to access node RPC from the SSH on localhost.

If you want to expose the RPC access to the public (i.e. a computer outside of localhost), you need to adjust the docker run command.
-p [::1]:7076:7076 maps the RPC port to the local adapter only, whereas -p [::0]:7076:7076 makes it available publicly. Keep in mind that this is potentially unsafe (depending on config.json settings). If you want to limit external access to specific IPs, use a combination of IPtables rules like this: iptables -A INPUT -s 2.3.4.5,11.12.13.14 -p tcp --dport 7076 -j ACCEPT iptables -A INPUT -p tcp --dport 7076 -j DROP where 2.3.4.5,11.12.13.14 is the list of external IPs you want to allow to connect. Localhost will always work with RPC, even if it's not listed there. Also keep in mind that you need to make IPtables rules permanent. You should apply iptables rules before the docker, but you can also do it afterwards. The order of the two iptables commands can't be flipped however (the first ACCEPT or DROP rule that matches will determine the fate of the packet). Note: when leaving [::0]: out, the docker will still be accessible from the public, but the iptables won't have any effect anymore, according to my research. Reason for this is that leaving [::0]: out will automatically create an additional iptables rule -A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 7076 -j ACCEPT which apparently does not harmonize with the custom rules. I am not an IPtables expert. If you don't want to touch IPtables but still want to be able to access the RPC remotely, then a json proxy will help.

Setting up RPC in a self-compiled node

In order to get RPC running with a self-compiled (non-Docker) node, you have to adjust these entries in config.json:
the code "address": "::1", defines the whitelisted IP mask of the hosts that are allowed to query the API. ::1 is localhost. For remote hosts, you can NOT use the ffff:82.124.73.51 IP style, it will error out, so you need other solutions (like json proxies or IPtables filters). If you want to exposing RPC to the public, use: ::ffff:0.0.0.0 (dangerous when "enable_control" is enables).
"port": "7076", is the RPC port to CURL on, could be changed to gain a little more security by obscurity. All node peer IPs are visible, but using a custom RPC port number will make opportunistic attacks a less likely.
"enable_control": "true", to activate potentially dangerous commands. See my other guide for a complete list.
"rpc_enable": "true", to enable or disable RPC completely

Using CURL from the shell

General syntax (demonstrated with the "version" command):
curl -g -d '{ "action": "version"}' '[::1]:7076' (recommended)
but you can also use
curl -d '{ "action":"version"}' [::1]:7076
or
curl -d '{ "action": "version"}' localhost:7076

CURL example 1 - Get info about a list of blocks:
curl -g -d '{ "action": "blocks_info", "hashes": ["87434F8041869A01C8F6F263B87972D7BA443A72E0A97D7A3FD0CCC2358FD6F9","A170D51B94E00371ACE76E35AC81DC9405D5D04D4CEBC399AEACE07AE05DD293"], "source": "true" }' '[::1]:7076'

CURL example 2 - Get all in- and outgoing transactions (without rep-changes) of an account:
curl -d '{"action": "account_history", "account": "xrb_1x7biz69cem95oo7gxkrw6kzhfywq4x5dupw4z1bdzkb74dk9kpxwzjbdhhs", "count": "-1"}' '[::1]:7076'

CURL example 3 - Send from one of the node's accounts
curl -g -d '{ "action": "send","wallet": "1E7611671439EE5F25266355B19650692CBAD80C908DBCCF4245046AF317B9C2", "source": "xrb_1cetkb3dppdprbderhucsg4p1b1fa3x3xci8kf8e1ucdepcnj5ijeeuxdzfi", "destination": "ban_3irc5dijkoihw1xx3wot68smg5rt7grn9rcwixwap9j14r88grah7d6b631x", "amount": "7000000000000000000000000000000", "id": "cet7_75" }' '[::1]:7076'

CURL example 4: Broadcast an offline-signed block in stringified variant (old):
curl -g -d '{ "action": "process", "block": "{ \"type\": \"send\", \"previous\": \"F61A79F286ABC5CC01D3D09686F0567812B889A5C63ADE0E82DD30F3B2D96463\", \"destination\": \"ban_3parsemsxf43okk3usa6ndiywhg5mp8te5mshq96447qqqufweskxamsrgdp\", \"balance\": \"FFFFFFFEBCE1F051928DE8355FFFFFFF\", \"work\": \"01b3d0bf56abf094\", \"signature\": \"E6802D01682524542016174FF0A40166293B0230DFEA7A1D4501A6C83889BF7DAC866CA0E2192B1C8C9AAD7F24C71C1619C6E8306324121CAAE0DC842D91760A\"}" }' '[::1]:7076' The block itself could get rejected if it's not in a single line. In the "link" field, the node will accept both hashes and accounts.