4 ms·

I'm curious about security... On one hand it's running inside a container? OTOH, there's no key/password required for clients to connect i.e. any local software

• netgusto 7y ago
  The api listens on 127.0.0.1 by default; so yes, local software can connect (see [1]). File pathes for read/writes and execution are not imperatively ordered by the client, but done declaratively based on the notebook ID. When the toolschains are in docker, the code runs in disposable containers. It would be possible to add creds (for instance, with creds stored in ~/.nodebook.conf); do you think it's mandatory? The cli mode (--cli) does not expose a port, but watches notebooks and outputs them in the terminal (works nicely with $YOUR_EDITOR) --edit-- I guess running this on a remote server through SSH tunnel would workyes, but I think it's safer and easier to version control the notebooks and run them locally. [1] https://github.com/netgusto/nodebook#%EF%B8%8F-a-bit-of-warning-%EF%B8%8F https://github.com/netgusto/nodebook#%EF%B8%8F-a-bit-of-warn...
  • mbreese 7y ago
    One mechanism I’ve seen (Jupyter) is to print out a token when the listening service (Webserver) starts. Then this is the credential needed to login to the web GUI. The token is randomly generated at runtime and unique to each time the server restarts. It would be expected that you’re running this on a computer you already control access to (remote server that you access with an SSH tunnel or a personal workstation). In this case, the token approach is a nice medium between full user accounts and ease of use while still providing some security.
    • netgusto 7y ago
      Oh yes I see, it’s indeed a nice in between. I will do that, like it! Thank you.