Amey-Thakur Realtime permissions
Permissions on a persistent connection are harder than on a request, because the check happened once at connect time and the connection may outlive the grant. Revocation that only applies to new sessions is not revocation.
Method
- Authorise every operation, not just the connection. A connection established with edit rights must still be checked per change, since rights can change mid-session (see authz-design).
- Push permission changes to affected clients immediately. Revoked users are disconnected or downgraded in place, and the interface reflects it without a reload.
- Scope subscriptions to what the user may see. A client that receives updates it should not see has already leaked, whatever the interface renders (see agent-context-isolation for the analogous boundary).
- Handle downgrade gracefully. A user losing edit rights mid-edit needs their pending change resolved honestly, either accepted or clearly rejected with an explanation.
- Separate document sharing from presence visibility. Being able to read a document does not imply being visible to others in it (see presence-and-awareness).
- Make link sharing explicit and revocable. Anyone-with-the-link access must be visible to the owner, expirable, and revocable, since links spread beyond intent.
- Log access changes. Who granted what to whom and when is what answers the later question of how someone saw a document (see audit-logging).
Boundaries
- Server-side enforcement is the only enforcement; hiding controls in the client is presentation, not security.
- Data already delivered cannot be recalled, so revocation limits future access only.
- Fine-grained permissions raise the cost of every operation and need caching designed with invalidation in mind.