- 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.
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"
}
that data coming in will be mixed with several messages at once,
lets parse those properly, and also implement some sanity checking
to make sure we aren't being flooded with a potential buffer overflow
1) Fix the event registration detection (string/array for args, not object/array)
2) Add a 30 second connection timeout for the client to successfully authorize before the server will close the connection.
Current Settings:
1) 5 auth attempts allowed before failover
2) If no communications for 10 minutes, the failover counter gets reset
3) On failover - the IP is placed on the server blacklist for 1 hour
Note: The blacklist system is connection independant, and uses the host IP for unique tracking/blocking.
Now the user's who login are divided up into "Full Access" users or not. This allows for additional restrictions in the backend subsystems to restrict certain types of operations to only the "full access" (root-permissioned) users.
The users are divided up like this:
1) The user must be in either the "wheel" or "operator" groups to get any access whatsoever (restricting automated services from connecting).
2) If the user is in the "wheel" group, they get full access to the server's capabilities
3) If the user is in the "operator" group instead, then they only get limited access to the server's capabilities.
While here, also allow password-less logins to the server if the client is connecting to a server on the same system (local access). User restrictions still apply.
