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 fromsonar-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.