3 Commits

Include renames

Author	SHA1	Message	Date
poslop	91568c0598	fix #63: require deletion token on DELETE /api/pastes/{id} ... - DELETE now demands the create-time deletion token (Authorization header: Bearer/Token/bare, or ?token= query param), compared with the constant-time store.DeletionTokenEqual. 403 otherwise. - Creator-browser deletes via the /mine button (matching vwr cookie, #37) remain allowed; other browsers and plain API clients get 403. - Regression tests: no token, wrong token (header+query), correct token (header+query), creator-cookie path, token extraction. - Adapted TestSoftDelete to pass the deletion token. - docs/API.md delete section updated. - Based on #58's SoftDelete (bool, error) signature.	2026-09-09 09:21:28 -05:00
agent	78374b2d49	fix: atomic burn-after-read claim (#58) ... SoftDelete now reports whether it performed the delete (conditional UPDATE ... WHERE deleted_at IS NULL checked via RowsAffected). RegisterRead returns an admitted flag: legacy burn pastes admit exactly one reader (the atomic soft-delete winner), and burn-after-N pastes increment reads_used via a conditional UPDATE guarded on reads_used < reads_limit, so concurrent readers cannot both consume the final read. API, HTML, and raw read paths return 404 when the reader loses the burn claim; content is never served twice. OpenStore pins the SQLite pool to one connection: concurrent writes on separate pooled connections surfaced SQLITE_BUSY as spurious 500s instead of serializing. Adds concurrency regression tests: 24 parallel readers of a burn paste (exactly one receives content, none of the others leak it) and 30 parallel readers vs a 3-read budget (exactly 3 admitted, then 404).	2026-09-09 09:18:42 -05:00
poslop	4f1e901f04	Refactor: split monolith into cmd/palette + internal/{store,api,web,lang} (#35)	2026-09-09 01:33:39 -05:00