Revalidate private API reads without weakening permissions #60

New issue

Open

opened 2026-11-01 20:12:23 +00:00 by viacheslavshuka · 0 comments

viacheslavshuka commented

2026-11-01 20:12:23 +00:00

Owner

Conditional requests can reduce repeated transfer while users refresh session data. Cached representations must not bypass current authorization or time-dependent state.

Scope

Implement private conditional reads for a representative authenticated resource and the corresponding openapi-fetch/TanStack Query handling. Select cache details and lifetimes during implementation. Keep Redis outside this release.

Acceptance criteria

Suitable authenticated reads use private revalidation. Authentication and token responses use no-store. Shared public caches cannot reuse personalized responses.
The server checks current identity and permissions before returning either data or 304 Not Modified. A revoked account cannot retain access through a matching validator.
Representation identity includes relevant account, filters, permissions, ignore rules, availability, and time transitions. Different callers cannot share private cached contents accidentally.
A time-dependent value can invalidate a representation without a database write. Crossing an offer expiry cannot retain an incorrect validator.
Committed changes invalidate relevant representations across web workers. Clearing one process's memory is not the invalidation mechanism for shared state.
Brotli variants use consistent validators and Vary handling. A 304 response has no JSON body, and the client preserves the corresponding previously received data.
The client passes cancellation through its request layer. Account changes and logout cannot reuse another account's private query state.
Capacity, approval, permission, and identity-verification decisions use current authoritative state. Conditional reads cannot authorize a write from stale displayed data.
Measurements report response-byte savings and database work separately. The implementation does not claim that revalidation automatically avoids a query.

Validation

Use two accounts, two workers, changed filters, revoked permissions, and a controlled clock. Check cold 200, matching 304, post-write refresh, and time-only expiry. Verify the generated contract and client correctly handle bodyless 304 responses.

Dependencies

#10: Generate and verify OpenAPI and the TypeScript client. Conditional responses need generated API contracts.
#54: Open Quorum on a filtered list of upcoming tests. The session list provides a real protected query with personal filters and permissions.

Conditional requests can reduce repeated transfer while users refresh session data. Cached representations must not bypass current authorization or time-dependent state. ## Scope Implement private conditional reads for a representative authenticated resource and the corresponding openapi-fetch/TanStack Query handling. Select cache details and lifetimes during implementation. Keep Redis outside this release. ## Acceptance criteria - Suitable authenticated reads use private revalidation. Authentication and token responses use no-store. Shared public caches cannot reuse personalized responses. - The server checks current identity and permissions before returning either data or `304 Not Modified`. A revoked account cannot retain access through a matching validator. - Representation identity includes relevant account, filters, permissions, ignore rules, availability, and time transitions. Different callers cannot share private cached contents accidentally. - A time-dependent value can invalidate a representation without a database write. Crossing an offer expiry cannot retain an incorrect validator. - Committed changes invalidate relevant representations across web workers. Clearing one process's memory is not the invalidation mechanism for shared state. - Brotli variants use consistent validators and `Vary` handling. A `304` response has no JSON body, and the client preserves the corresponding previously received data. - The client passes cancellation through its request layer. Account changes and logout cannot reuse another account's private query state. - Capacity, approval, permission, and identity-verification decisions use current authoritative state. Conditional reads cannot authorize a write from stale displayed data. - Measurements report response-byte savings and database work separately. The implementation does not claim that revalidation automatically avoids a query. ## Validation Use two accounts, two workers, changed filters, revoked permissions, and a controlled clock. Check cold `200`, matching `304`, post-write refresh, and time-only expiry. Verify the generated contract and client correctly handle bodyless `304` responses. ## Dependencies - [#10: Generate and verify OpenAPI and the TypeScript client](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/10). Conditional responses need generated API contracts. - [#54: Open Quorum on a filtered list of upcoming tests](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/54). The session list provides a real protected query with personal filters and permissions. ## Related work - [#24: Keep browser data useful during slow or lost connections](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/24) - [#69: Restrict participation and organizing capabilities with reversible expiry](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/69)

viacheslavshuka added the

labels

2026-11-01 20:14:27 +00:00

viacheslavshuka referenced this issue

2026-11-01 20:15:55 +00:00

Keep browser data useful during slow or lost connections #24

viacheslavshuka added a new dependency