Compare commits

..

3 commits

Author SHA1 Message Date
59295318f8 test(acl)(#28): integration cases for windowed + stacked usage caps
Some checks failed
Docker image / build-and-push-image (push) Has been cancelled
9 cases: under/at limit, signings outside the window excluded, uncapped,
lifetime (null window) all-time count, kind-specific counting, both
stacked-cap directions (hourly binds vs daily binds), and the
record->count->deny loop via recordSigning. 22 integration + 7 unit green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-20 21:51:05 +02:00
f332559b59 feat(acl)(#28): per-rule windowed usage caps enforced live at sign time
Completes the lifecycle family from #25 — usage caps were the third
sibling (after expiry #24 and revoke), written-but-never-enforced.

Model:
- PolicyRule gains windowSeconds; drops the never-enforced mutable
  currentUsageCount. A cap = (maxUsageCount, windowSeconds): at most N
  signings of this (method,kind) per rolling window. windowSeconds NULL
  = lifetime; maxUsageCount NULL = uncapped.
- New SigningLog: durable append-only record of allowed signings — the
  source of truth caps count against (derive-don't-count; no counter to
  drift).

Enforcement (checkIfPubkeyAllowed step 4): among the live token's
matching rules, every capped rule must have remaining budget in its
window (COUNT(SigningLog) < maxUsageCount), counted live. Stacked caps
all bind — 20/hr AND 200/day enforced together. recordSigning() writes
a SigningLog row from the permit callback when a consequential request
(sign_event / encrypt / decrypt) is allowed.

Retune live: new update_policy_rule admin RPC patches maxUsageCount/
windowSeconds/method/kind in place; takes effect next request, no
re-pairing (a payoff of the #27 Option D design). get_policies now
returns each rule's id + window_seconds so callers can target it.

Retention/pruning of SigningLog is a follow-up.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-20 21:51:05 +02:00
bbcc9cd998 test(acl)(#29): DB-backed integration tests for checkIfPubkeyAllowed
Some checks failed
Docker image / build-and-push-image (push) Has been cancelled
Closes the gap flagged in #27 review: the wiring that actually closes
#24 (step-4 Token join filtered by liveWhere) was untested — only the
pure predicate was. Now covered end-to-end against a throwaway SQLite DB
+ the real prisma client.

Harness (no new dependency; pnpm add is blocked by the nix node_modules
hoist pattern):
- tests/register-ts.cjs: ts-node (transpile-only) + a CommonJS resolver
  that maps the app's '.js' ESM-style specifiers to their '.ts' sources.
- node:test temp DB via 'prisma db push'; a before() guard refuses to run
  unless DATABASE_URL points at tests/.tmp/ (never truncates a real DB).
- npm run test:integration / test:all.

13 cases incl. the #24 regression guard (expired token -> denied),
revoke, connect-off-live-token, override expiry/revoke ignored,
deny-beats-grant, kind mismatch, no-KeyUser.

Also: acl/index.ts NDK import -> 'import type' (NostrEvent/NIP46Method are
type-only) so the ACL module no longer pulls ESM-only NDK at runtime —
required for the CommonJS test import, and a correct cleanup besides.

Requires the prisma engine env (CI/nix ok; devShell pending #30).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 23:03:39 +02:00

View file

@ -1,65 +0,0 @@
# nsecbunkerd migration & DB-maintenance runbook
Operational notes for applying schema migrations and ACL/pairing maintenance on
deployed, **LNbits-connected** nsecbunkerd instances.
## ⚠️ Never full-wipe `nsecbunker.db` on an LNbits-connected instance
The nsecbunkerd ↔ LNbits pairing is **split across both systems**:
- **Bunker** (`nsecbunker.db`): per-account `KeyUser` binding (keyed by LNbits's
stable client pubkey) + redeemed `Token` + a shared `Policy`.
- **LNbits** (`accounts.signer_config`, `RemoteBunkerSigner`):
`{token, client_nsec, policy_id}`.
`RemoteBunkerSigner.sign_event()` signs **directly with the stored `client_nsec`**
— it does NOT re-connect/re-redeem, and there is **no auto-repair** on restart or
sign-failure. `provision()` runs only at new-account creation and mints a NEW
npub (which changes the user's nostr identity).
**Consequence of a full `nsecbunker.db` wipe:** the `KeyUser` bindings are
deleted → every LNbits account's stored config dangles → all signing fails, and
the only standard "repair" (`provision()`) changes identities. **Do not do it.**
### Correct way to strip the #24 materialized photocopies
Post-#27, token grants are evaluated live via the ACL step-4 `Token → Policy →
PolicyRule` join, so the old materialized `SigningCondition` rows are redundant
— and, written with `expiresAt = NULL`, they would keep granting past a token's
expiry (silently re-opening #24 for already-paired clients). Strip them with a
**targeted delete** that preserves the pairing:
```sql
-- Verify first.
SELECT COUNT(*) FROM Token WHERE redeemedAt IS NOT NULL; -- bindings to preserve
SELECT COUNT(*) FROM SigningCondition; -- photocopies to strip
-- Keeps KeyUser + Token + Policy intact. Live-token clients keep working
-- untouched; only the stale photocopies are removed.
DELETE FROM SigningCondition;
```
Run against each instance's `nsecbunker.db`. If an instance was already
full-wiped, recover by restoring the pre-wipe `nsecbunker.db` backup, then run
the targeted delete.
> Manual-override grants (`add_signing_condition`, web-approval) also live in
> `SigningCondition`. On an LNbits-only bunker there typically are none, so a
> blanket `DELETE FROM SigningCondition` is safe. If an instance uses manual
> overrides, delete only the policy-derived rows you intend to strip.
## Keys are never in the DB
Key material lives in `nsecbunker.json` (`keys`), never in `nsecbunker.db`. A DB
wipe loses ACL/pairing state, never keys. LNbits holds the bunker **admin nsec**
(`LNBITS_NSEC_BUNKER_ADMIN_NSEC`) and is the sole admin client.
## Schema migrations
Migrations are applied by the deploy's `prisma migrate deploy`, **not** by the
daemon on boot — the in-`start.js` `npm run prisma:migrate` step is a no-op
(tracked in #31). After adding a migration, make sure the deploy applies it.
Prisma on NixOS needs the engine env pinned to `prisma-engines_6` (the bare
`prisma-engines` attr is now 7.x with no `libquery_engine.node`; devShell fix
tracked in #30). The deploy's `package.nix` already pins `_6`.