Allow listen to all interfaces instead of localhost

[olevitt]

Hi !

The UI server is currently hardcoded to listen to localhost only (see

duckdb-ui/src/http_server.cpp

Line 188 in 963e0e4

server.listen("localhost", local_port);

).
Listening to only localhost instead of all interfaces (e.g 0.0.0.0) prevents running this in cloud-native setups such as within containers.
Most web servers allow configuring the interface just like for port and other configurations.

Would it be possible to add a configuration parameter for overriding this localhost ?

Thank you !

[Y--]

Great suggestion! Started a PR here #25
I'll need to think a bit more about the other implications but this shouldn't be too far off.

[albertog]

Is there an open API on the internal HTTP server that can be used from another process and this away have the same connection?

[keiththompson]

+1 I've started using this on Github Codespaces which automatically opens http://127.0.0.1:4213/ when I run duckdb -ui.
I'm currently able to workaround this by manually changing the url to http://localhost:4213.

[jraymakers]

It's clear this is desirable, but it presents a security challenge. Opening the server to connections from off-box means malicious actors on the network could modify your database or steal your secrets.

[tdunning]

It is clear that this would be a security issue without some kind of security handshake, but the difference is just the size of the zero security zone.

Port forwarding is another alternative, but it would be very nice if it were possible to suppress the urge for duck to launch a browser.

[jraymakers]

Port forwarding is another alternative, but it would be very nice if it were possible to suppress the urge for duck to launch a browser.

This is possible today! Instead of duckdb -ui, do duckdb -cmd "call start_ui_server()".

[jfmontanaro]

It's clear this is desirable, but it presents a security challenge. Opening the server to connections from off-box means malicious actors on the network could modify your database or steal your secrets.

Just chiming in here because this is something I would also like to see: Would it be acceptable to default to binding to localhost, but expose an option to explicitly specify a bind address, which could be 0.0.0.0 or anything else the user specifies? A lot of dev tooling works that way (e.g. vite, just to pick a random example) and it seems like a reasonable compromise to me.

My use-case is, I'm teaching a class on SQL this summer, and I'm thinking about having a system that spins up containers on-demand as users connect and drops them into a pre-configured duck-ui instance. Not the end of the world if it isn't available, since I can always just run another proxy inside the container, but certainly simpler if there were just an option to manually set the bind address.

[tdunning]

Combining this feature with an unguessable URL would mitigate the security issues.

Such a URL can be generated by simply adding a large-ish number of hex-digits generated from /dev/random and a secure hash. This URL suffix could even be injected from the command line as the signal to allow promiscuous binding.

With the external hashing, I could imagine that the containers would be launched from a control panel on a separate web site. This control panel would select a port, generate the suffix and stuff these into a newly launched container. It could then show the URL with a link and a QR code to simplify getting to the UI for the newly launched container.

[tdunning]

I have an implementation ready to test, but I have been unable to clone this repository correctly so that I can test it.

The problem looks like this:

$ git clone --recurse-submodules --remote-submodules git@github.com:tdunning/duckdb-ui.git
Cloning into 'duckdb-ui'...
Warning: Permanently added the ECDSA host key for IP address '140.82.116.4' to the list of known hosts.
remote: Enumerating objects: 460, done.
remote: Counting objects: 100% (81/81), done.
remote: Compressing objects: 100% (59/59), done.
remote: Total 460 (delta 39), reused 44 (delta 20), pack-reused 379 (from 1)
Receiving objects: 100% (460/460), 173.32 KiB | 1.31 MiB/s, done.
Resolving deltas: 100% (252/252), done.
Submodule 'duckdb' (https://github.com/duckdb/duckdb) registered for path 'duckdb'
Submodule 'extension-ci-tools' (https://github.com/duckdb/extension-ci-tools) registered for path 'extension-ci-tools'
Cloning into '/home/tdunning/duckdb-ui/duckdb'...
remote: Enumerating objects: 665135, done.        
remote: Counting objects: 100% (5/5), done.        
remote: Compressing objects: 100% (5/5), done.        
remote: Total 665135 (delta 0), reused 0 (delta 0), pack-reused 665130 (from 1)        
Receiving objects: 100% (665135/665135), 324.62 MiB | 12.97 MiB/s, done.
Resolving deltas: 100% (556243/556243), done.
Cloning into '/home/tdunning/duckdb-ui/extension-ci-tools'...
remote: Enumerating objects: 1555, done.        
remote: Counting objects: 100% (555/555), done.        
remote: Compressing objects: 100% (157/157), done.        
remote: Total 1555 (delta 464), reused 413 (delta 392), pack-reused 1000 (from 2)        
Receiving objects: 100% (1555/1555), 283.87 KiB | 3.02 MiB/s, done.
Resolving deltas: 100% (692/692), done.
fatal: Needed a single revision
Unable to find current origin/v1.2.1 revision in submodule path 'duckdb'

This is odd since the revision exists in the duckdb repo.

[tdunning]

My problem is insufficient git-foo.

I have a PR almost ready that does this.

The idea is that you can define a URL randomizer string. If you set this to a non-empty string, it is added to the connection URL and the listen command binds to "0.0.0.0" instead of "localhost"

[tdunning]

Making the server listen to 0.0.0.0 is a dead end. The JS libraries used by the interface itself detect that the server is insecure and refuses to proceed.

The only reasonable way forward is either a proxy approach or establishing an https connection. The https connection will require a trusted host signature which is a pain to handle with lots of VMs or containers. That leaves the proxy approach.

[jraymakers]

Could you share more details about the problem you encountered with 0.0.0.0? I'm not sure which part of the JS led to the problem, but we're open to changing it if possible (without breaking anything).

[tdunning]

here is the error: