Wopi: checkFileInfo request contains multiple bearer tokens

[cagliostro92]

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

[igwyd]

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.

[cagliostro92]

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.

[igwyd]

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.

[igwyd]

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