- Shipped
- September 23, 2026 at 1:21 AM UTC
- Author
- Kamo
- Commit
- 168cc8a
CheckFileInfo was the only WOPI endpoint that both compared the access token's document against the request path and re-checked live access; GetFile, PutFile, PutRelativeFile, RenameFile and the lock/unlock/refresh/get-lock overrides only verified the token's signature and expiry, then acted on whatever imgId showed up in the URL. A token minted by POST /api/docs/open/{imgId} for one document a member had legitimately opened could read or overwrite any other document in any organization by editing the path, and could lock, unlock or probe the lock of any document the same way. A read-only share recipient's own valid token could also overwrite the document directly, bypassing the UserCanWrite flag checkFileInfo already told the editor to enforce client-side. Every WOPI endpoint now requires the token's JWT subject (the imgId WopiTokenService signs in at mint time) to equal the path's imgId, and re-checks DocumentService.canUserAccess (reads: GetFile, GET_LOCK) or canUserWrite (writes: PutFile, PutRelativeFile, RenameFile, LOCK/UNLOCK/ REFRESH_LOCK) against the database rather than trusting the token's claims — access can be revoked or expire after the token is minted, so a live check is strictly stronger than a static permission claim. Denied token-authenticated byte reads/writes are now recorded through DocumentAccessAuditor the same way an invalid token already was. New test: WopiControllerAccessTest (11 cases covering every endpoint listed above); mutation-checked by reverting the WopiController changes locally, which turns all 11 red, then restoring. WopiControllerAuditTest and WopiEditSessionTest updated to stub the now-required access checks, since their existing cases all assume a permitted caller.