How do you handle session revocation while a request is still in flight?
I’m working on a Node.js and PostgreSQL web app and reviewing its access controls before moving a local prototype to Linux hosting. The requests involve sensitive form data.
The case I’m trying to handle is:
- A user submits a save.
- Their access is revoked while the request is still running.
- The database transaction or its response is still pending.
The current design separates stopping new work from recording that the session has ended:
- Once the server applies the cutoff, it refuses new work and stops further sensitive response writes to the socket.
- A transaction that received a single-use, transaction-specific commit permit before the cutoff may still commit before the session’s end is durably recorded. Simply receiving a request before the cutoff is insufficient.
- Bytes already handed to the operating system or a proxy may still reach the browser afterward. We’re not trying to recall those.
- If a save commits but its response is lost, that uncertainty must be resolved without blindly repeating the save.
The prototype uses a native Rust/rustls component to control commit permissions and socket writes. Before investing in porting that layer, I want to understand whether the requirement justifies the complexity.
How would you enforce this cutoff using a conventional Node/PostgreSQL architecture behind a reverse proxy? In particular, where would you enforce the response-write guarantee, and what limitations would remain?
I’m also open to questioning the requirement itself. Examples from systems you’ve operated would be especially helpful.
Drafted with AI assistance. Project is real and in progress, so please let me know if anything needs clarification.
Top comments (1)
I'd question the response-write part first. behind a reverse proxy you don't really own the socket, the proxy can buffer the whole response, so the guarantee you can actually keep is "no commit after the cutoff" and not "no bytes after the cutoff". in plain postgres you could get that by checking the session row inside the same transaction right before commit (select ... for share on the session, revocation does an update on it), so revoke and commit just serialize on that row. for the lost response case an idempotency key stored in the same transaction as the save covers the "did it commit or not" question without repeating it.