Support: Expected response format for WOPI access denied 403

[donquixote]

Hello @hfiguiere,
this is a question for you..

TLDR:

• What is the expected response body format for a WOPI request (e.g. check file info) in case of failure? (access denied, bad token, not found). Is a json response ok? (given that we set the correct http response code)
• What would be the desired behavior of the Collabora editor, if a CheckFileInfo request returns access denied?

About WOPI 403 response

Currently the WopiController sends its own "Access denied" response which is:

• Content: 'Authentication failed.' (just text, no json, no html)
• Http status code: 403
• Headers: Content-type: text/plain

We would like to refactor this so that access handling happens in the router, not in the controller. This will open up more possibilities and help to organize the code better.

If we do this, the default 403 response would be a full html page.
But, we can change it so that we get a json response like {"message": "Sorry, xyz"}.

I did not find anything in the Microsoft WOPI or Collabora Online documentation that gives more information on the expected response format in case of no access or error. Microsoft says which http response code to set (they say 401 or 404), but nothing about the content, see https://learn.microsoft.com/en-us/microsoft-365/cloud-storage-partner-program/rest/files/checkfileinfo/checkfileinfo-response

I assume the response body can be anything, so json would be ok too.

About the editor behavior

Currently when I artificially let the WopiController send an 403, 404 or 401, the editor is stuck forever in "Initializing...".
Is this intentional? Was it always this way, or did we damage something?
Was there a way to make the editor show "Sorry, you cannot edit this file" or "This file was not found"?

[hfiguiere]

In case of error, the content of the response is written into the logs, just as information. Hence the simple text content. The WOPI endpoints are never meant to be displayed in a browser not return HTML content.

COOL should handle the HTTP error code correctly, so if it hangs without error message it's likely a bug and would be interested in knowing the exact scenario.

[donquixote]

Thanks @hfiguiere

With docker-compose logs --tail=20 collabora I see these entries:

collabora_1 | wsd-00001-00034 2024-12-12 14:46:37.800604 +0000 [ websrv_poll ] ERR #28: WOPI::CheckFileInfo failed for URI [http://web.test:8080/cool/wopi/files/1?access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmaWQiOiIxIiwidWlkIjoiMSIsIndyaSI6ZmFsc2UsImV4cCI6MTczNDEwMTE5Ny43NTAzMzF9.4TEqbtu9V9SJcCVTrEYKM8pmsYk5njPtaa4LrMQJPlI&access_token_ttl=0]: 403 (Forbidden) Forbidden. Headers: Date: Thu, 12 Dec 2024 14:46:37 GMT / Server: Apache/2.4.41 (Ubuntu) / X-Powered-By: PHP/8.3.14 / Cache-Control: must-revalidate, no-cache, private / Content-language: en / X-Content-Type-Options: nosniff / X-Frame-Options: SAMEORIGIN / Expires: Sun, 19 Nov 1978 05:00:00 GMT / X-Generator: Drupal 11 (https://www.drupal.org) / Transfer-Encoding: chunked / Content-Type: text/plain; charset=UTF-8 Body: [Authentication failed.]| wsd/wopi/CheckFileInfo.cpp:98
collabora_1 | wsd-00001-00034 2024-12-12 14:46:37.800622 +0000 [ websrv_poll ] ERR #28: Access denied to [http://web.test:8080/cool/wopi/files/1?access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmaWQiOiIxIiwidWlkIjoiMSIsIndyaSI6ZmFsc2UsImV4cCI6MTczNDEwMTE5Ny43NTAzMzF9.4TEqbtu9V9SJcCVTrEYKM8pmsYk5njPtaa4LrMQJPlI&access_token_ttl=0]| wsd/wopi/CheckFileInfo.cpp:112

[donquixote]

This is after inserting return static::permissionDenied(); at the top of WopiController::wopiCheckFileInfo().
And the editor is hanging with "Initializing...".

[donquixote]

Btw @hfiguiere The WOPI specs says that we should return 401 Unauthorized instead of 403 Access denied.
This also matches the general meaning of 401 vs 403, where 401 is "we don't know you" but 403 is "we know you but we don't like you".

Then, we learn that with a 401 response we MUST send a WWW-Authenticate header. But this seems kind of pointless for our context, because there is nothing that Collabora Online would be able to do with that header.

We also learn that for a failed X-WOPI-Proof, we must respond with 500 Internal Server Error. I am not sure why this would be.

For other cases we should return 404 not found.

Currently the WopiController is responding with 403 in all cases, I think.

The main question here is: Does Collabora Online care whether it gets a 401, 403, 404 or 500? Should we expect any difference in behavior if we send a different response code?

The question does have implications on the module architecture:
With Drupal's routing system it is quite easy to produce a 403 or 404 response, using mechanisms that work outside the controller. There is some benefit in separating the access and authorization from the controller.
For a 401 or 500, we have to do something else, or keep the checks inside the controller.

[hfiguiere]

I checked our code and it seems that it treat 403 equally to 401 but then it is good to be strict in what we send. So 401 seems to be what should be done.

As for X-WOPI-Proof, no one use it. At none of the off the shelve integration that we know, except for SharePoint. So I would just ignore it.

[donquixote]

Hi
The point of the X-WOPI-Proof would be to prevent that somebody would make a WOPI request from outside, using the existing token.
Normally a user needs to go through Collabora Online to save a document, which hopefully makes sure to only save valid documents without macros and such.
But, with a valid token, that user can directly use the WOPI save endpoint.
This is equivalent to uploading a file in Drupal.
In a typical site configuration, a user with editor save permission might also have the file upload permission.
But, there can be site configurations where we want users to only use the editor, either for all document-like media, or for specific media types.

[donquixote]

@hfiguiere
Aside of this, would you have an idea why the editor is hanging in case of a failed WOPI file info request, instead of showing some kind of failure message to the user?

[hfiguiere]

The token is associated to a specific file, specific user AND specific permission (write or not). Can't see how it could be used to write a different file or upload a new one, or even to write if it is read-only.

[hfiguiere]

@hfiguiere Aside of this, would you have an idea why the editor is hanging in case of a failed WOPI file info request, instead of showing some kind of failure message to the user?

I haven't investigated the issue yet. (I have seen it, though)

[donquixote]

I have seen it, though

as in reproduced? or just seen the comment here in the issue queue?

[donquixote]

(more in email)

[hfiguiere]

This is after inserting return static::permissionDenied(); at the top of WopiController::wopiCheckFileInfo(). And the editor is hanging with "Initializing...".

Filed this issue: CollaboraOnline/online#10824