Embedded editor permissions: editing, downloads, and active-session revocation

Viewing, editing, commenting, downloading, sharing, printing, and managing versions are distinct business operations. Start with a matrix of roles and allowed actions, then map it to the controls actually supported by the editor and your application. Avoid assuming that a single read only flag expresses every policy. If the product cannot enforce a required distinction, change the workflow or record the limitation before launch. Server authorization should remain responsible for business endpoints even when the embedded interface also hides controls for a better user experience.

Make the matrix concrete for your deployment. If the editor exposes a download action that goes directly to its own service, testing only your application's download endpoint leaves a gap. If a signed object URL remains valid after revocation, record that lifetime as part of the observed behavior.

Choose the strictest requirement first. An organization that requires immediate loss of all interactive access needs a supported termination or continuously enforced authorization mechanism. Where the product only changes permissions on the next open, that limitation affects workflow design. Do not hide it behind a successful role update in your database. For in-flight work, decide whether previously accepted edits finish publication and how an administrator can recover them without reopening the user's access.