pastilhas
05d51302ec
The owner installed it, landed on the configuration form, and could not get off it. Not a bug in the form: there was nothing behind it. One panel was registered and it was the settings. That is the wrong shape for a plugin regardless of how much is finished. A screen whose only content is its own configuration reads as broken rather than unfinished, because the first thing anybody does after installing is look for the way forward. So: collections on the left, links on the right, and the settings behind the gear in the collections panel - reachable when something is wrong and out of the way when it is not. Selection is `?collection=` in the URL rather than a channel, so which collection you are looking at survives a reload and can be linked to. Search is Linkwarden's own `searchQueryString`, which searches names, descriptions, tags AND the archived page text - the thing a bookmark bar cannot do, and the reason this is worth more than a list of addresses. Doing it here would mean pulling every link to the browser and would still only see the fields we happened to fetch. Verified against the instance: 50 unfiltered, 8 for "arch", 0 for a string matching nothing. The panel holds no credential and could not send one. Every request goes through the authenticated door, which finds the caller's mapped account and puts their token on. `no Linkwarden account is mapped to you` is the state every user starts in, so it is said as an instruction rather than rendered as an outage.
72 lines
3.4 KiB
TypeScript
72 lines
3.4 KiB
TypeScript
import type { PluginManifest } from '@@/plugins/manifest';
|
|
|
|
/**
|
|
* Linkwarden — your bookmarks, behind an Officer session.
|
|
*
|
|
* ── The model, which is Vault's ──
|
|
*
|
|
* One Linkwarden per Officer install, pointed at by the owner. Officer does not install it and does not
|
|
* store bookmarks: Linkwarden owns the data, and this plugin owns the CREDENTIAL and the door. Where
|
|
* Vault brokers one account, this maps EVERY Officer user onto a Linkwarden account of their own — see
|
|
* `db/schema.ts`, and `plugins/USER_PROVISIONING.md` for the contract that governs creating one.
|
|
*
|
|
* ── What is different from Vault, and it is not small ──
|
|
*
|
|
* Vaultwarden speaks a host-agnostic bearer protocol, so its sidecar can be a dumb pass-through and a
|
|
* Bitwarden client does not care what address it is reached at. Linkwarden is a Next.js app using
|
|
* NextAuth: it issues host-scoped session cookies, checks CSRF against the host, and hands clients
|
|
* ABSOLUTE urls built from `NEXTAUTH_URL`.
|
|
*
|
|
* Measured on the live instance rather than inferred — a sign-in posted to `100.64.0.1:3000` answers
|
|
* with `{"url":"https://linkwarden.home.pastilhas.eu/api/v1/auth/signin?csrf=true"}`. So serving the
|
|
* browser extension through Officer requires that `NEXTAUTH_URL` name the address Officer serves it at.
|
|
* That is a change to the container, not to this plugin, and it is a prerequisite rather than a
|
|
* preference: without it the extension is bounced out of the proxy mid-login.
|
|
*
|
|
* The API half is unaffected. `/api/v1/*` accepts `Authorization: Bearer <access token>` and never
|
|
* touches NextAuth, so the panel and anything an agent does work regardless of the above.
|
|
*
|
|
* ── No `osDependencies` ──
|
|
*
|
|
* Nothing shells out. The sidecar is a Bun HTTP proxy and the upstream is reached with `fetch`.
|
|
*/
|
|
export const manifest: PluginManifest = {
|
|
publisher: 'officerdev',
|
|
version: '2026.09.05.04',
|
|
platform: '>=1.0.0',
|
|
|
|
label: 'Linkwarden',
|
|
summary: 'Your bookmarks, behind an Officer session — saved, archived and searchable',
|
|
tags: ['Personal', 'Degoogling'],
|
|
icon: 'Bookmark',
|
|
color: '#0ea5e9',
|
|
|
|
permissions: [
|
|
{
|
|
key: 'linkwarden',
|
|
label: 'Linkwarden',
|
|
description: 'Your saved links, collections and their archived pages',
|
|
/*
|
|
Reading and saving links is every user's; pointing the install at a server and creating accounts
|
|
on it is not. `/config` holds the URL the whole install uses and `/accounts` provisions against
|
|
an admin credential — both are prefix-matched, so the trees beneath them are covered.
|
|
*/
|
|
ownerOnly: ['/config', '/accounts'],
|
|
},
|
|
],
|
|
|
|
/*
|
|
The extension's door, served without an Officer session.
|
|
|
|
Same reasoning as Vault's `/bw`: a stock Linkwarden extension carries its own credential and has
|
|
nowhere to put an Officer JWT. It is the same exposure through one address instead of two, and it is
|
|
what lets Linkwarden stop being reachable on its own.
|
|
|
|
ONE prefix and no root claims, which is where this is simpler than Vault. A Bitwarden client derives
|
|
`/api`, `/identity`, `/icons` and `/notifications` from a bare server URL and therefore needed four
|
|
root-level mounts; the Linkwarden extension is given a base and appends `/api/v1/...` beneath it, so
|
|
everything the protocol needs already sits under one declared path.
|
|
*/
|
|
unauthenticatedPaths: ['/lw/*'],
|
|
};
|