- Ya
- 3 Agosti 2026, 04:03 UTC
- Mwandishi
- Kamo
- Ahadi ya
- eb92af9
WOPI serves whole documents to Docs and recorded nothing. GET /wopi/files/{id}/contents is the same disclosure as /download, relayed the same way through APIService, with no trail at all — opening a document in the editor was untraceable. Identity comes from the WOPI access token, not a *** session: DocumentController mints it with the opening member's org and member ids and Docs returns it on every callback, so those claims are the only identity these endpoints have, and the one checkFileInfo already authorizes against. The auditor takes them directly rather than resolving a member a second way that could disagree with the token the request was authorized by. A token that cannot be read records against the unresolved-org sentinel instead of being dropped. PutFile records as VIEW, not DOWNLOAD: a save sends bytes in rather than out, so calling it a disclosure would double-count the GetFile that opened the session, and VIEW fails open so a sick audit sink cannot destroy unsaved work. CheckFileInfo and the lock operations stay unrecorded — no content, and Docs calls both repeatedly through one session, which would bury the row that means bytes actually moved. The sweep for remaining byte-serving paths found two more: - /api/docs/binders/{id}/render merges every document in a binder into one PDF. It is bulk-download in a different wrapper and recorded nothing; now one event per embedded document, separators and generated pages excluded. - **************** wrote only an ImgLogDownload row. That is an imaging-domain record read by the download-history panel, not the cross-surface trail — so the accounting of disclosures showed streams, exports and template PDFs while omitting the service's most-used byte path. Both records are now written; they answer different questions. No entity, @Column or shared-library change.