Record-scoped write authorization: per-record allowDelete on query deletes, per-element allow* on array puts

[kriszyp]

Write-side corollary to #1786 (Record-scoped allowRead): allowUpdate/allowCreate/allowDelete were enforced once per request on multi-record writes, so a record-scoped override was silently under-enforced on conditional deletes and array puts.

The model

Mirrors #1786's marker/deferral design, with the write-path differences:

• Query-shaped delete with an application-overridden allowDelete (marker isDefaultAllowDelete) defers its entry check and is enforced once per matching record — FILTER semantics: denied (or throwing/rejecting — fail closed) rows are skipped, permitted rows deleted; limit/offset count allowed rows, mirroring the read guard filtering before the query limit.
• Array puts (REST collection PUT and direct instance put) with an overridden allowUpdate/allowCreate are authorized per element — create-vs-update chosen by that element's existence — with FAIL semantics: one denial throws AccessViolation, aborting the whole transaction (no partial batch).
• this binding: mutating allow* hooks stay on the resource (no RecordObject delegate); per-record evaluation binds this to a per-row resource instance with the record loaded, so this.ownerId and super.allow* composition both work (the SWR-instance idiom from allowStaleWhileRevalidate is never consulted for query-driven revalidation #1578).
• Async overrides participate: the write paths are async, so unlike the sync search traversal in Record-scoped allowRead: unified row-level read access control (#1422 gap 2) #1786, async allow* overrides are awaited per record (fail-closed).
• Default allowCreate consistently means INSERT: record creation and record-targeted publish both check INSERT RBAC; publish creates an audit/message entry and does not update the record. Framework-default array puts still keep their single collection-entry check.
• The deferred put check runs in the static put action against the resolved body, so a promise body can't bypass it and enforcement is framework-owned for every resource class. A subclass overriding delete() loses the enforcesCheckPermission marker → keeps today's entry check (warned once per class).

Deliberately out of scope: operations-API/SQL writes stay on operation-level RBAC (they never arm checkPermission; raw tables have no override surface).

Where to look

• resources/Resource.ts — the write-deferral gate in the authorize wrapper (the security-critical predicate set) and the per-element checks in the static put action.
• resources/Table.ts — #deleteWithRecordScopedCheck (scan-param save/restore around search() preserves the checkPermission permission operand for super.allowDelete), and the per-element branch in instance put.
• resources/DatabaseTransaction.ts / LMDBTransaction.ts — aborted transactions are terminally poisoned: addWrite()/save()/commit() reject, while successfully completed transactions retain their existing post-commit behavior; abort cascades across the multi-database chain.
• transactional() arg parsing now carries collection-ness onto the fallback-constructed query (programmatic put(records, context) previously never resolved a collection resource — latent inconsistency).

Cross-model review (Codex + Opus adjudication; Gemini leg failed — agy hung 3×)

Findings fixed in-branch: limit=0 off-by-one; scan-param restore in finally; default-table array-PUT INSERT→UPDATE operand shift; insert RBAC on record-scoped creates; two-phase async batch authorization; aborted-transaction write rejection. Remaining accepted limitations:

• Commit-retry TOCTOU (ownership changes between authorization and a conflict-retried commit) is a pre-existing gap across all single-record auth — follow-up issue to file, not widened here.
• Approximate-index (HNSW) conditional deletes filter after the bounded candidate set, and denied-heavy deletes with limit scan the full matching set — same class of limitation as the Record-scoped allowRead: unified row-level read access control (#1422 gap 2) #1786 read filter.

Docs: companion PR HarperFast/documentation#593 (extends the #1786 allowRead docs page with the write-side model).

Generated by KrAIs (Claude Fable 5).

[gemini-code-assist]

Code Review

This pull request introduces record-scoped write authorization as a write-side corollary to record-scoped read authorization. It defers permission checks for collection-shaped writes (array PUTs and query-shaped DELETEs) to evaluate them per-record or per-element when application-overridden allowDelete, allowUpdate, or allowCreate hooks are present. Query-shaped deletes now utilize filter semantics (skipping denied rows), while array PUTs enforce fail-fast semantics (aborting the transaction on any denial). The feedback recommends improving the thenable check in Resource.ts by verifying that then is a function rather than just checking its truthiness.

[claude]

Reviewed; no blockers found. Prior blocker (insert-RBAC regression on post/publish/copy) is resolved — kept intentionally with a regression test and updated PR description. New commits since last review (insert-RBAC/async-batch-authorization split, and reject-writes-after-abort) both check out with solid regression tests.

[heskew]

Both notes are specific to tables that override an allow* hook — the default path is correct and covered by t8–t14. An override re-routes authorization through the per-element resource, and that's where the two issues live. Left inline.

_{🤖 Draft prepared with Claude (cross-model review pipeline); reviewed and posted by @heskew.}