arso-project/sonar

Expose user interface and API outside of localhost

Closed this issue · 1 comments

Currently, the sonar ui serve command starts an HTTP server on localhost:55555 to serve the UI statically. The sonar server start command starts the Sonar API HTTP server on localhost:9191. The API has no authentication at all, but also is only served on localhost and not exposed to the network.

We want to expose the UI, to allow different devices to access the UI without having to run sonar themselves.

To do that, we need:

  • Add a token-based authentication to the api server. There's different options, both where to set the tokens (query parameter, HTTP header) and between very simple access token and more complex solutions (like setting up access per island). Also look JSON Web Tokens, it seems to gain some support. Also the browser has some special case handling about the Authorization header that makes some things easier possibly.
  • Save these tokens and have a way to create them. The config.json is ok for now with a list of tokens. And a CLI command to create and list tokens
  • We'll likely also want to serve both the API and the UI over a single port, that makes things much easier if you want to expose sonar over a hostname. So either we create a way for "http plugins" where sonar-server would require a module from sonar-ui that allows it to hook into the express app, or we create a HTTP proxy between the two. The latter might be nice for future stuff also (like tunneling HTTP uis through hyperswarm 🎉 🤓 ).
  • Have a setting on which network interfaces and ports the combined server listens with a CLI command like sonar set-interface localhost, sonar set-interface public. For that we need a minimal introspection into networking interfaces.
  • When exposing you in a LAN setting its not necessarily straightforward / easy to find you from other devices. Have a page in the UI that displays my url where you can also select to display a URL to copy paste with an auth token included (like `http://192.168.2.201:31'). We could then also auto generate a QR code for that URL so people can scan it from your screen.

For the access token, we will at least want to have read only and write access to sonar. That's a distinction that isn't there yet, we'll have to be careful. Then not much is missing to just have tokens per island. Those could even be derivations of a base token and the island's private key so the actual auth checking is just a crypto call. But the auth-per-island case is not needed for a first version.

We merged a basic authentication API, so this is fixed. See #62 for remaining issues.