Changing Permissions

Role assignments can change after a user starts using the application. In HopPress, an administrator may remove the editor role when someone leaves the publication team. That person may remain an author, but they should no longer be able to publish other people’s posts.

Withdrawing a previously granted permission is called revocation. Removing a role revokes the permissions that the user obtained through that role, unless another role they retain grants them too.

Suppose the former editor still has a submitted post open in their browser. The page was loaded before the role was removed, so it still shows a “Publish” button. Clicking it sends a new request. The server needs to use the updated role assignment when deciding whether to allow that request.

The requirements should say how quickly a permission change must affect new requests, and whether a delay is acceptable. For HopPress, I would require that, within one minute of a role’s removal, the server stops allowing new requests that only that role permitted.

That requirement affects how the server obtains the caller’s roles. If it remembered their roles from sign-in, checking those same roles on every request would not detect a removal. HopPress uses the same design as the shop API: the authentication middleware reads the caller’s current roles from the database on every request. So the removal affects the former editor’s next request, well within the one minute.

Removing a role affects only the requests the user sends after the change. It does not undo what they already did. If they downloaded a draft, they still have that copy. If they published a post, the post is still published. To reverse a completed action, someone needs a separate operation and permission to perform it.