Feature: Password-protected content

[toanalien]

Category: Ideas

Summary

Add WordPress-style password protection as a core feature: authors set a password on a content item, read APIs return a "locked" envelope until the caller submits the correct password.

Why core, not a plugin

• The plugin API has no content:beforeRead hook, can't extend content table schemas, and can't inject middleware. Best a plugin can do is expose its own gated route — every frontend would have to opt in, and the live API would still leak protected content.
• WXR importer already parses wp:post_password (cli/wxr/parser.ts:345) but drops it. Anyone migrating from WordPress silently loses protected posts.

Scope

In: one password per item, gates admin + live read APIs, admin UI toggle, WXR importer wire-up, EDITOR+ bypasses gating.

Out: multiple passwords, encryption at rest, password recovery, replacing auth.

Design

Schema

• One nullable column password_hash TEXT on every content table.
• Add to schema/registry.ts standard columns + new migration that loops _emdash_collections (same pattern as 013_scheduled_publishing.ts).

Hashing

• PBKDF2-HMAC-SHA256, 600k iterations (OWASP 2023). Only KDF in SubtleCrypto, so it works on Workers without a native dep.
• Format: pbkdf2$sha256$<iter>$<salt>$<hash> so iterations can be bumped later.
• New utils/password-hash.ts with hashPassword / verifyPassword (constant-time compare).

Unlock tokens

• Reuse the HMAC token pattern from preview/tokens.ts. Same payload shape, signed with EMDASH_SESSION_SECRET — no new env var.
• Stored in HTTP-only Secure SameSite=Lax cookie. Cookie strategy is an open question (see below).
• TTL default 7d, configurable per collection.

Read API

• password_hash null OR caller is EDITOR+ OR valid unlock cookie → full content.
• Otherwise → 200 with locked envelope: { locked: true, id, slug, status, fields: { /* publicWhenLocked only */ } }. Not 401 — frontends need to render the locked page.
• New per-field flag publicWhenLocked (default false). Standard columns like id, slug, status are always public.

Verify endpoint

• POST /_emdash/api/content/[collection]/[id]/unlock, body { password }, requires X-EmDash-Request: 1.
• Rate limit: 5 attempts / IP / item / 60s, returns 429 + Retry-After.
• Fixed ~200ms minimum response time to kill timing oracles.
• Logs success/failure to the audit log.

Admin UI

• New "Visibility" sidebar panel next to status: protect toggle + password input. Current password never returned to the client.
• Schema editor: per-field "Visible when locked" checkbox.
• Content list: lock icon on protected items.

WXR importer

• When item.postPassword is set, hash it on import. Plaintext is never persisted.

Config

posts: {
  passwordProtect: { enabled: true, tokenTTL: "7d" }
}

Test plan

• Unit: password-hash round-trip, unlock-tokens sign/verify/expire/tamper.
• Integration: locked vs unlocked read paths, EDITOR bypass, rate limit 429, WXR fixture with <wp:post_password>, publicWhenLocked field visibility.
• Migration: existing tables get the new column; new tables get it from the registry.

Open questions

1. Cookie strategy — per-content cookies (WP-style, no size cap but verbose) vs single signed cookie listing unlocked IDs (capped at 4KB). Preference?
2. Locked envelope shape — { locked: true, fields: {...} } vs full envelope with private fields nulled out?
3. Should title default to publicWhenLocked: true? WP shows it by default.
4. Rate limit storage on Workers — in-memory bucket dies across isolates, KV per-attempt is expensive. Existing pattern in the codebase I should reuse?
5. PBKDF2 vs adding a scrypt dep — confirming PBKDF2 is acceptable.

Implementation order

1. password-hash.ts + tests
2. unlock-tokens.ts + tests
3. Migration + schema/registry.ts standard column
4. Read API gating + locked envelope
5. Verify endpoint + rate limit
6. publicWhenLocked field flag
7. Admin UI (visibility panel, field flag, list icon)
8. WXR importer wire-up
9. Docs + changeset (emdash: minor)

Steps 1–6 are backend-only and can land first.

---

Asking maintainers: is the scope and the PBKDF2 hashing choice OK? Happy to adjust before writing code.