[GH-ISSUE #780] Wopi: checkFileInfo request contains multiple bearer tokens #358

Closed
opened 2026-02-26 10:32:06 +03:00 by kerem · 5 comments
Owner

Originally created by @astrologic7 on GitHub (Nov 11, 2024).
Original GitHub issue: https://github.com/ONLYOFFICE/Docker-DocumentServer/issues/780

This issue is unique.

  • I have used the search tool and did not find an issue describing my bug.

Operating System of DocumentServer

Docker

Version information

8.2.0

Expected Behavior

As per RFC 6750 there are three methods to send a bearer token:

  • Authorization Request Header Field
  • Form-Encoded Body Parameter
  • URI Query Parameter

and clients must not use more than one method to transmit the token in each request.

Actual Behavior

Actually, the code sends the token both in query param and header:

request uri=http://xxx.xxx.xxx.xxx:8080/wopi/files/1?access_token=token

{
    "Authorization": "Bearer <token>",
    "X-WOPI-ClientVersion": "8.2.0.143",
    "X-WOPI-Proof": "AqIH0mBHPGY832wpSVIP+or7cMVrteY6qVVZNBsFt+102UJq5CQgWYORTPlIz+QVnSaF3V21VgOi5/rz33O9WVmCZdJhJg+RIfDedcHEiNT5T8imtxy36lpbEpHBijWu8VRGd3g21XIKCjqJQD+uEOs0b9TR3/6cTnRMQAHWXHJcnbFZZ4t7+HlTqhfSFeBxc2JZ0vBDSHUGiHl2Kfbi4YTso9wJP8PCPACp7MTzfT3TXG1ApM48xECLMFYX2BUg4NGBDoN8bZ92u4dFERLaKIAoaf3wU3lmqrssRoHpx7Rn/mxyADpviQi1ggSQadbuIZg4LC+++9v7U9tRQVPMlQ==",
    "X-WOPI-ProofOld": "AqIH0mBHPGY832wpSVIP+or7cMVrteY6qVVZNBsFt+102UJq5CQgWYORTPlIz+QVnSaF3V21VgOi5/rz33O9WVmCZdJhJg+RIfDedcHEiNT5T8imtxy36lpbEpHBijWu8VRGd3g21XIKCjqJQD+uEOs0b9TR3/6cTnRMQAHWXHJcnbFZZ4t7+HlTqhfSFeBxc2JZ0vBDSHUGiHl2Kfbi4YTso9wJP8PCPACp7MTzfT3TXG1ApM48xECLMFYX2BUg4NGBDoN8bZ92u4dFERLaKIAoaf3wU3lmqrssRoHpx7Rn/mxyADpviQi1ggSQadbuIZg4LC+++9v7U9tRQVPMlQ==",
    "X-WOPI-TimeStamp": "638669291764170000"
}

Reproduction Steps

No response

Additional information

No response

Originally created by @astrologic7 on GitHub (Nov 11, 2024). Original GitHub issue: https://github.com/ONLYOFFICE/Docker-DocumentServer/issues/780 ### This issue is unique. - [X] I have used the [search tool](https://github.com/ONLYOFFICE/DocumentServer/issues?q=) and did not find an issue describing my bug. ### Operating System of DocumentServer Docker ### Version information 8.2.0 ### Expected Behavior As per [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750#section-2) there are three methods to send a bearer token: - Authorization Request Header Field - Form-Encoded Body Parameter - URI Query Parameter and clients must not use more than one method to transmit the token in each request. ### Actual Behavior Actually, the code sends the token both in query param and header: request uri=http://xxx.xxx.xxx.xxx:8080/wopi/files/1?access_token=token ```json { "Authorization": "Bearer <token>", "X-WOPI-ClientVersion": "8.2.0.143", "X-WOPI-Proof": "AqIH0mBHPGY832wpSVIP+or7cMVrteY6qVVZNBsFt+102UJq5CQgWYORTPlIz+QVnSaF3V21VgOi5/rz33O9WVmCZdJhJg+RIfDedcHEiNT5T8imtxy36lpbEpHBijWu8VRGd3g21XIKCjqJQD+uEOs0b9TR3/6cTnRMQAHWXHJcnbFZZ4t7+HlTqhfSFeBxc2JZ0vBDSHUGiHl2Kfbi4YTso9wJP8PCPACp7MTzfT3TXG1ApM48xECLMFYX2BUg4NGBDoN8bZ92u4dFERLaKIAoaf3wU3lmqrssRoHpx7Rn/mxyADpviQi1ggSQadbuIZg4LC+++9v7U9tRQVPMlQ==", "X-WOPI-ProofOld": "AqIH0mBHPGY832wpSVIP+or7cMVrteY6qVVZNBsFt+102UJq5CQgWYORTPlIz+QVnSaF3V21VgOi5/rz33O9WVmCZdJhJg+RIfDedcHEiNT5T8imtxy36lpbEpHBijWu8VRGd3g21XIKCjqJQD+uEOs0b9TR3/6cTnRMQAHWXHJcnbFZZ4t7+HlTqhfSFeBxc2JZ0vBDSHUGiHl2Kfbi4YTso9wJP8PCPACp7MTzfT3TXG1ApM48xECLMFYX2BUg4NGBDoN8bZ92u4dFERLaKIAoaf3wU3lmqrssRoHpx7Rn/mxyADpviQi1ggSQadbuIZg4LC+++9v7U9tRQVPMlQ==", "X-WOPI-TimeStamp": "638669291764170000" } ``` ### Reproduction Steps _No response_ ### Additional information _No response_
kerem 2026-02-26 10:32:06 +03:00
Author
Owner

@igwyd commented on GitHub (Nov 19, 2024):

Hello @cagliostro92. This is for compatibility with possible WOPI hosts. In the documentation from the WOPI protocol developer does not clearly indicate where it should be.

<!-- gh-comment-id:2485215533 --> @igwyd commented on GitHub (Nov 19, 2024): Hello @cagliostro92. This is for compatibility with possible WOPI hosts. In the documentation from the WOPI protocol [developer](https://learn.microsoft.com/en-us/microsoft-365/cloud-storage-partner-program/rest/common-headers#request-headers) does not clearly indicate where it should be.
Author
Owner

@astrologic7 commented on GitHub (Nov 19, 2024):

Hello @igwyd,
based on that specification, I understood WOPI hosts could make a double check while looking for the token. Please note that looking for the token among the query parameters takes precedence over the authorization header, can be made in all cases, and can also be used as a fallback in case the authorization header is not present. The clients, instead, must always send the token along with query parameters for all WOPI operations. I think sending the token only in query parameters would allow you to be compliant with both the WOPI specification and RFC 6750 (which is also important) and would be fair enough from a compatibility perspective. Saying that, you can also evaluate to introduce a new variable to include/exclude the authorization header, but also in this case, in my humble opinion, the default behavior should be to exclude the authorization header.

<!-- gh-comment-id:2485532449 --> @astrologic7 commented on GitHub (Nov 19, 2024): Hello @igwyd, based on that specification, I understood WOPI hosts could make a double check while looking for the token. Please note that looking for the token among the query parameters takes precedence over the authorization header, can be made in all cases, and can also be used as a fallback in case the authorization header is not present. The clients, instead, must always send the token along with query parameters for all WOPI operations. I think sending the token only in query parameters would allow you to be compliant with both the WOPI specification and RFC 6750 (which is also important) and would be fair enough from a compatibility perspective. Saying that, you can also evaluate to introduce a new variable to include/exclude the authorization header, but also in this case, in my humble opinion, the default behavior should be to exclude the authorization header.
Author
Owner

@igwyd commented on GitHub (Nov 20, 2024):

As far as I can tell this is a recommendation and not a requirement, I don't see a threat in this, but I agree that it is worth paying attention to, I created a ticket #71766 for the developers.

<!-- gh-comment-id:2487609473 --> @igwyd commented on GitHub (Nov 20, 2024): As far as I can tell this is a recommendation and not a requirement, I don't see a threat in this, but I agree that it is worth paying attention to, I created a ticket #71766 for the developers.
Author
Owner

@igwyd commented on GitHub (Dec 6, 2024):

It's fixed at github.com/ONLYOFFICE/server@b8f95f353c and will be released in next release.

<!-- gh-comment-id:2522250146 --> @igwyd commented on GitHub (Dec 6, 2024): It's fixed at https://github.com/ONLYOFFICE/server/commit/b8f95f353c67d08d63969e258e06815ab2fc58c5 and will be released in next release.
Author
Owner

@Rita-Bubnova commented on GitHub (Feb 6, 2025):

DocumentServer v8.3.0 is released so I close this issue. Feel free to comment or reopen it if you got further questions.

<!-- gh-comment-id:2639787701 --> @Rita-Bubnova commented on GitHub (Feb 6, 2025): DocumentServer v8.3.0 is released so I close this issue. Feel free to comment or reopen it if you got further questions.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Docker-DocumentServer-ONLYOFFICE#358
No description provided.