- Shipped
- 23 września 2026 01:21 UTC
- Author
- Kamo
- Commit
- 168cc8a
CheckFileInfo był jedynym punktem końcowym WOPI, który porównał token dostępu. dokument przeciwko ścieżce żądania i ponownie sprawdzony dostęp na żywo; GetFile, PutFile, PutRelativeFile, RenameFile i blokada/odblokowanie/odświeć/refresh/get-lock tylko Zweryfikowano podpis tokena i wygaśnięcie, a następnie działał na podstawie tego, co pokazał imgId W górę w punkcie URL. Token wybity przez POST /api/docs/open/'imgId' dla jednego dokumentu Członek, który zgodnie z prawem otworzył, mógł odczytać lub nadpisać jakikolwiek inny dokument w Każda organizacja poprzez edycję ścieżki i może zablokować, odblokować lub sondować zamek Każdy dokument w ten sam sposób. Własny ważny token odbiorcy tylko do dzielenia się Może również nadpisać dokument bezpośrednio, pomijając flagę UserCanWrite CheckFileInfo już powiedział redaktorowi, aby egzekwował stronę klienta. Każdy punkt końcowy WOPI wymaga teraz podmiotu JWT tokena (impgId Znaki WopiTokenService w czasie mięty) do wyrównania imgID ścieżki, i Sprawdza ponownie DocumentService.canUserAccess (odbłyski: GetFile, GET_LOCK) lub canUserWrite (zapisy: PutFile, PutRelativeFile, RenameFile, LOCK/UNLOCK/ REFRESH_LOCK) w oparciu o bazę danych, zamiast ufać twierdzeniom tokena — Dostęp może zostać cofnięty lub wygasł po wybiciu tokena, więc czek na żywo jest Surowo silniejsze niż roszczenie o pozwolenie statyczne. Odmowakena - autentyczność odczyty/pisy są teraz nagrywane za pośrednictwem DocumentAccessAuditor w ten sam sposób Nieprawidłowy token był już. Nowy test: WopiControllerAccessTest (11 przypadków obejmujących każdy punkt końcowy powyżej); mutacja-sprawdzona przez odwrócenie zmian WopiController lokalnie, które Obraca wszystkie 11 czerwonych, a następnie przywraca. WopiControllerAuditTest i WopiEditSesjonalna Test Zaktualizowane, aby zaktualizować wymagane obecnie kontrole dostępu, ponieważ ich istniejące przypadki Załóż dozwolony rozmówcę.