1) Add a "-h" or "help" option which lists all the current CLI flags and their usage.
2) Adjust the "-import_ssl_file" and "-import_ssl_pubkey" options to now take 2 argument, with the first being some nickname for the key.
3) Add a "-remove_ssl [nickname]" option for removing a key.
1) "-import_ssl_file <filepath>": This will import any .crt or .key file such that the designated public key may be used for authentication with this bridge.
2) "-import_ssl_pubkey <pubkey>": This will import the designated pubkey such that it may be used for authentication with this bridge.
- Turn off some debugging in the server.
- Add a "bridge_export_key" CLI flag to the server to export the contents of the public certificate used for bridge connections.
- Fix up the bridge rc.d script so it actually works.
- Ensure that the bridge SSL key/cert is created when starting the server.
- Add the bridge to the overall project build.
This also adds some stand-alone CLI options to the sysadm-binary utility:
"bridge_list": List any bridge connections in the settings file. Output Format: "name (url)"
"bridge_add <name> <url>": Add a bridge connection to the settings with the given name. (if websocket server is running, this change will take effect within 5 minutes).
"bridge_remove <name>": Remove a bridge connection from the settings. If a websocket server is running, this change will take effect within 5 minutes (closing the connection to the removed bridge as needed).
There is also a new option in the global server config file:
BRIDGE_CONNECTIONS_ONLY=[true/false]
If true, this will allow the websocket server to run without listening on any ports, and instead force all traffic through the existing bridge connections.
NOTE: There is a special API/event for the bridge to announce which server/client connections are available (clients will see only servers, and vice versa)
The syntax for this event is:
{
"namespace":"events",
"name":"bridge",
"id":"",
"args":{
"available_connections":["ID1","ID2", etc..]
}
}
Note that the available_connections are *all* the connections available at that time (it is not a difference from a previous state), so there may be both new ID's in the list and ID's which are no longer listed.
This event will get sent out any time a new connection/disconnection is made from the bridge which impacts the current connection (so a client will only get the event when a server connects/disconnects and vice versa).
Add a new API call to the sysadm-server: rpc/identify (no arguments)
This generates a responce identifying the type of sysadm system ("server" in this case). This will be important and I am going to be adding this same API call to all the various sysadm utilities so they can identify which one they are ("server", "bridge", "client").
REST Request:
-------------------------------
PUT /rpc/identify
{}
WebSocket Request:
-------------------------------
{
"args" : {},
"namespace" : "rpc",
"id" : "fooid",
"name" : "identify"
}
Response:
-------------------------------
{
"args": {
"type": "server"
},
"id": "fooid",
"name": "response",
"namespace": "rpc"
}
