pastilhas
2f2529d8d5
The fourth plugin out, after offscale, music and email. Two routers, a sidecar,
three tables and — new — a settings screen, since the vault never had a UI in
the platform.
What it is: a reverse-proxy to a Vaultwarden you already run, plus a credential
broker that keeps the vault session server-side so devices never hold one. It
stores no passwords and cannot read any; every byte through it is ciphertext.
Two things changed rather than moved:
• VAULTWARDEN_URL left .env for a one-row `vault_config` table with a panel
writing it. A plugin cannot ask the owner to edit a file and restart a
process, so the env var could not survive the move. Server-wide, decided
with the owner: one Vaultwarden per install. The sidecar reads it on a 10s
cache rather than per request, since it sits in front of every proxied byte.
• Core stopped importing clearVaultTokens/clearVaultUnlockKey from three auth
handlers. That is the security property behind the distress and panic
buttons, so it could not simply be dropped — the platform gained a small
account-lifecycle hook instead, and the severity mapping moved here where it
belongs. Core now names no table and no column of this plugin.
Two things were deleted rather than carried, both already dark since
2026-08-13 and both recorded in PLUGIN.md:
• The unauthenticated Bitwarden passthrough. A plugin's routes mount behind
Officer's account gate; top-level unauthenticated prefixes are not something
a manifest can declare. Its own comments already called it TEMPORARY,
pending a first-party browser extension that authenticates to Officer.
• The notifications websocket. No plugin owns a socket on this platform yet.
SignalR falls back to HTTP long-polling on its own, so clients still sync.
25 lines
1023 B
TypeScript
25 lines
1023 B
TypeScript
import * as sidecar from '@@/sidecar-registry';
|
|
|
|
// The officer-vault sidecar starts its Vaultwarden reverse-proxy on a random loopback port and reports it
|
|
// here on connect. We remember it so `/api/vault/*` (HTTP) and the notifications WebSocket always forward
|
|
// to the current sidecar. The platform holds NO knowledge of Vaultwarden itself — only where the sidecar is.
|
|
|
|
let serverPort: number | null = null;
|
|
|
|
sidecar.on('vault:server', (msg) => {
|
|
const port = (msg as { port?: number }).port;
|
|
if (typeof port !== 'number') return;
|
|
serverPort = port;
|
|
console.log(`[vault] sidecar proxy registered on port ${port}`);
|
|
});
|
|
|
|
/** Base URL of the sidecar's HTTP proxy, or null if the sidecar hasn't reported in yet. */
|
|
export function getVaultServerUrl(): string | null {
|
|
return serverPort ? `http://127.0.0.1:${serverPort}` : null;
|
|
}
|
|
|
|
/** Same, as a WebSocket base for the notifications hub. */
|
|
export function getVaultServerWsUrl(): string | null {
|
|
return serverPort ? `ws://127.0.0.1:${serverPort}` : null;
|
|
}
|