Listen address: the case where authentication exists but is not in STUdio

[lgnap]

Follow-up to the exchange on #43, opened separately so that PR stays about the frontend.

You closed the -Dstudio.host question with a criterion I think is the right one:

What would change my mind is authentication, not configurability — if the API is ever safe to expose, studio.host becomes reasonable the same day.

I dropped it from the PR and I am not asking you to reverse that. But I want to put one topology in front of you, because I think it meets your criterion rather than dodging it, and I had not stated it properly before.

The topology

A Raspberry Pi sits where the Lunii is, with the device plugged into it, running STUdio. The reverse proxy is not on the Pi — it is the machine that already fronts the household's other services, and it is where authentication already lives. It forwards to the Pi over the LAN.

The device has to be physically plugged into something, and an always-on Pi next to where the toy lives is a better answer than a laptop that has to be fetched each time.

This is not hypothetical on the architecture side: libusb4java 1.3.0 publishes both linux-aarch64 and linux-arm on Central, so 64-bit and 32-bit Raspberry Pi OS are both covered by the existing dependency. Nothing about the driver needs to change.

Why a proxy does not remove the need here

If the proxy runs on the same machine, it reaches 127.0.0.1:8080 and your fixed binding is untouched — no setting needed, and that is a real answer for a desktop install. I said as much before thinking about the other case.

When the proxy is on a different machine, that stops working: it has to reach the Pi across the network, so STUdio on the Pi has to bind something other than the loopback. There is no arrangement of proxies that avoids it.

So the request is narrower than "let me expose the API": it is "let me bind an address an authenticating proxy can reach". The authentication you want exists in that setup. It is just not inside STUdio — which, for a tool this size, seems like the right place for it not to be.

What I would not want you to accept without noticing

Three things, because I would rather state them than have you find them:

1. The proxy-to-STUdio hop is unauthenticated and in the clear. Anyone on the LAN who can reach the Pi's port bypasses the proxy completely. This arrangement is only as good as a firewall rule restricting that port to the proxy's address, and that rule lives outside the application where nothing verifies it. That is a genuine weakening compared to the loopback, not a technicality.

2. This is why the setting should be an address, not a flag. -Dstudio.host=192.168.1.42 binds one interface; a boolean would only ever mean 0.0.0.0. The implementation I dropped took an address for that reason.

3. It does not solve CSRF, and neither does any proxy. uploadToLibrary calls xhr.send(formData) with no custom header, so the request is multipart/form-data — a CORS-simple content type, no preflight. A page in the user's browser can fire it, and CORS will stop the response being read but not the write from happening. Proxy authentication authenticates the browser, so a session would ride along. That is true on a loopback-only install today; it is not an argument against binding wider, but it is the hole I would fix first if remote use is ever supported. I can open that separately with a reproduction if it is useful.

What I am actually asking

Not for the setting back. For your read on whether "authentication exists, at a proxy, on another host" counts as meeting your condition, or whether your position is specifically that STUdio itself must authenticate before its socket may widen.

Both are defensible and it is your project. If it is the second, say so and I will stop raising it — the answer being written down somewhere is worth more to me than the answer going my way.

[antoinevalentinHA]

Thanks — this is a useful distinction, and I think it lets me state the rule more precisely.

My requirement is not that authentication must live inside STUdio itself.

It is that an unauthenticated STUdio socket must not become directly reachable from the network.

With the topology described here, widening STUdio's bind address would not meet that condition: as you point out yourself, any host able to reach the Pi directly could bypass the authenticating proxy. Making that safe would therefore depend on an external firewall rule that STUdio neither owns nor verifies.

That does not mean your Raspberry Pi topology is excluded, though.

An authenticating proxy can run on the Pi itself:

client
  → household reverse proxy
  → authenticating proxy on the Pi
  → 127.0.0.1:8080 STUdio

In that arrangement STUdio can keep its current loopback-only binding, while the Pi exposes only the authenticated entry point. So I don't think a configurable studio.host is required for this use case.

That is the rule I intend to keep: STUdio may sit behind external authentication, but its own unauthenticated listener should remain unreachable except from the local host.

You also asked for that answer to be written down somewhere rather than only living in this issue. Agreed. I will record that invariant alongside the existing listen-address rationale in MainVerticle.listenHost().

One separate note on point 3: I tested the current upload endpoint against the running application. A multipart request carrying Origin: http://evil.example is rejected by Vert.x with HTTP 403 before the upload handler is reached, and no file is written — CorsHandler refuses the request server-side rather than only stopping the response being read, so the mechanism you describe does not work from an arbitrary site.

It does reproduce from a narrower origin, which I would not have found without your note. The CORS pattern is http://localhost:.*, so every localhost origin is allowed regardless of port: http://localhost:3000 and http://localhost:1 both return 200 and write the file. Any other application serving a page on any local port is therefore a permitted origin.

That is a real hole, smaller than the one you described and present on a loopback-only install today. Please do open it — with that framing rather than the general one, and I have the measurements if they are useful.

None of which makes the API safe to expose on a LAN: a non-browser client sends no Origin at all and is not constrained by any of this.

Thanks for spelling the topology out this carefully; it helped clarify the boundary.

[lgnap]

Your rule is better than the one I was arguing against, and I accept it.

an unauthenticated STUdio socket must not become directly reachable from the network

That names what must not happen rather than who has to authenticate, which is why it settles the case cleanly where mine did not. And you used the right objection: the unauthenticated hop between proxy and application was the weakness I listed against my own proposal, and treating it as disqualifying rather than as an acceptable caveat is the correct call. Safety that depends on a firewall rule the application neither owns nor verifies is not safety the application can claim.

The chained proxy on the Pi does solve the topology, and I had not considered it. STUdio stays on the loopback, the Pi exposes only an authenticated entry point, and nothing needs to be configurable. Dropping the request — not deferring it.

Glad the invariant is going into listenHost(). That was the part I actually wanted.

On the CORS point

Already open as #46, from about five minutes before your comment, so you had no way of seeing it. It is written with the narrow framing rather than the general one, and it opens with the retraction of my CSRF claim, for the same reason you tested it: I had asserted the mechanism from reading the client code without ever sending a request.

Our measurements agree, and yours goes further than mine: I probed without a file part, deliberately, because I was testing against a real library and did not want to write into it. So I confirmed the request reaches the handler; you confirmed the file is actually written. That is the version worth having in the issue — please do add the measurements.

#46 also records a second thing from the same table, which I have not seen mentioned anywhere: Origin: http://127.0.0.1:8080 is refused. The pattern is written over localhost, so opening the UI by IP rather than by name makes every state-changing request fail with 403 while reads keep working, since browsers omit Origin on same-origin GETs. A half-working UI with no visible cause.

The line I would keep

a non-browser client sends no Origin at all and is not constrained by any of this

That is the conclusion, and it is worth stating in #46 too. Everything CORS does here is browser-mediated. It is not access control, and it never was — which is exactly why the loopback rule you just wrote down is doing the actual work.