the sidecar, and the two doors
Officer holds the credential; Linkwarden holds the data and decides who may see it. That split is the whole design and it is why there are two doors that look alike from outside and are not. `/lw/*` is the extension's. Unauthenticated, forwarded verbatim, the credential is the caller's own - the same argument Vault's public router makes, that this is one address instead of two rather than new exposure, and it is what lets Linkwarden stop being reachable on its own. `/api/*` is ours. An Officer session names the caller, we find their mapped account and put THEIR token on the request. A browser holding an Officer session never holds a Linkwarden credential, which is the property Vault exists to give, applied per user. Officer decides whose token goes on; Linkwarden decides what it may see, because re-implementing that here would be a second answer able to disagree with the first. `proxiedSubPath: '/lw'` is load-bearing rather than tidy. Claiming the whole prefix would tell the body parser to leave /config alone too, and every field on it would read as missing - the failure caldav hit the day it was extracted. The sidecar is a plain HTTP proxy with no WebSocket: Vaultwarden pushes over SignalR and Linkwarden does not, so a socket here would be scaffolding for a protocol that does not exist. Its onCommand is empty for the same reason - it forwards bytes, and everything that decides anything happens before a request reaches it. Two things measured rather than assumed while writing this. The port announcement typechecks because SidecarPortAnnouncement was generalised, so a plugin no longer needs a platform pull request to announce its own port. And the config URL is the LOOPBACK address, not the advertised one: on alpha the name Linkwarden now advertises resolves to 127.0.1.1, where nothing is bound, so a sidecar running there would dial the name it publishes and get nothing. Typechecks clean. No provisioning and no panel yet.
This commit is contained in:
+14
-1
@@ -23,7 +23,20 @@ export const linkwardenConfig = pgTable(
|
||||
{
|
||||
/** Always 1. A single-row table wants to say so structurally, or a second row arrives eventually. */
|
||||
id: integer('id').primaryKey().default(1),
|
||||
/** Base URL, no trailing slash (normalised on write). Null before the owner has pointed it anywhere. */
|
||||
/**
|
||||
* Base URL, no trailing slash (normalised on write). Null before the owner has pointed it anywhere.
|
||||
*
|
||||
* ── This is the address the SIDECAR dials, which is not the one clients are told ──
|
||||
*
|
||||
* They come apart whenever Officer and Linkwarden share a host, and on this install they do. Clients
|
||||
* are told `http://alpha:3000` and that is right for them: a browser elsewhere resolves it over the
|
||||
* tailnet to 100.64.0.1. But ON alpha the same name resolves to 127.0.1.1, and Linkwarden binds only
|
||||
* 127.0.0.1 and 100.64.0.1 — so the sidecar, running there, dials the name it advertises and gets
|
||||
* nothing. Measured: `http://alpha:3000` answers 000 from alpha and 200 from anywhere else.
|
||||
*
|
||||
* So this holds the loopback address and `NEXTAUTH_URL` holds the public one. Storing the advertised
|
||||
* name here would work from every machine except the one it runs on.
|
||||
*/
|
||||
url: text('url'),
|
||||
/**
|
||||
* The admin access token, used ONLY to provision accounts — `plugins/USER_PROVISIONING.md`.
|
||||
|
||||
Reference in New Issue
Block a user