tests for WOPI protocol

[individual-it]

oCIS is offering WOPI as one of its APIs

currently this API is tested using the wopi-validator and some very basic e2e tests

These tests don't cover anything related to:

• security
• spaces
• shares
• antivirus
• public links
• versions
• etc.

currently the WOPI service is also re-implemented in #8374

My question is: do we need to have a separate WOPI API test-suite as we have with e.g. WebDAV, TUS, Graph or can be everything tested via unit test and the underlying code-path are tested already with the existing API testsuites?

@jvillafanez @micbar @phil-davis @DeepDiver1975 @dragotin @ScharfViktor ?

[jvillafanez]

I think we'll need to come up with our own test suite, maybe in parallel with the wopi validator.

The wopi validator runs a series of actions against the the wopi server. Some of them might be preparation of the actual test, and the validator could skip the test if something goes wrong with the preparation, for example if the target file is missing.
This also means that some actions might be difficult to test through the validator. What happens if you try to lock a file but the file doesn't exist? Pretty sure the validator will skip the test because the CheckFileInfo request prior to the Lock fails, so we don't know if the wopi server responds correctly to such Lock request with a 404 code.

There are also potential race conditions or issues regarding the order of operations that we should ensure they don't break anything (we might need to include code to make testing easier). As far as I know, the wopi validator isn't enough for these kind of issues.

The other big thing is that the CheckFileInfo request is tailored to Microsoft so the validator tests pass. Both collabora and onlyoffice include their own set of properties, which I don't think we can test at the moment because the wopi validator will complain.
We'll have to figure out a proper way to support everything (unless we only support microsoft), but we'll need a way to verify that the properties are working, or at least that we send the properties correctly.

[DeepDiver1975]

The other big thing is that the CheckFileInfo request is tailored to Microsoft so the validator tests pass. Both collabora and onlyoffice include their own set of properties, which I don't think we can test at the moment because the wopi validator will complain.

We need to see how the validator handles this situation. We might even run into situations where not only different properties are expected but the same properties with different values.

But let's see how this works out.

the wopi validator is open source - we can extend it to our needs. Which might be a possible way to go.
(it is basically xml + c# - happy to help out)

[individual-it]

1. most things should be covered by unit + integration tests in Go @jvillafanez @rhafer @2403905
2. make the e2e UI tests run on the new WOPI service (assigned to @SagarGi ) @individual-it @saw-jan
   • [QA] Configure ocis collaboration service for e2e tests web#10960
3. add e2e UI tests to cover the smoke-tests that is done in the release @individual-it @saw-jan
   • [QA] increase test coverage for WOPI service web#10750
4. create API tests for CheckFileInfo @individual-it @saw-jan
   • check that all expected values are returned (//TODO add list/documentation link)
     • https://learn.microsoft.com/en-us/microsoft-365/cloud-storage-partner-program/rest/files/checkfileinfo/checkfileinfo-response
     • https://api.onlyoffice.com/editors/wopi/restapi/checkfileinfo
   • future: check that env. variables switch the abilities correctly
5. as more functions are added, more wopi validator tests should be switched on @jvillafanez @rhafer @2403905
6. extend the validator if needed @DeepDiver1975
7. After adding api tests coverage for wopi endpoint, add API tests for /app/open and app/new endpoint on normal files.shares, public links of folders as per request in this comment
   • [QA] API tests for /app/ endpoints #9682
   • Unable to create a file with Collabora in a Space accessed via an edit public link #8691 (comment)

[ScharfViktor]

3. add e2e UI tests to cover the smoke-tests that is done in the release @individual-it @saw-jan

Where should we run app-provider e2e tests? Now we run it only web CI. should we include this tests in the ocis CI?

[SagarGi]

3. add e2e UI tests to cover the smoke-tests that is done in the release @individual-it @saw-jan

Where should we run app-provider e2e tests? Now we run it only web CI. should we include this tests in the ocis CI?

@ScharfViktor since the app-provider tests is not ran in ocis as of now. May be lets stick to running it only web for now ? @saw-jan @individual-it

[ScharfViktor]

@ScharfViktor since the app-provider tests is not ran in ocis as of now. May be lets stick to running it only web for now ? @saw-jan @individual-it

let's make it only in web for now.

[saw-jan]

ℹ️ NOTE: we will wait until the service is stable and there's a deployment example available

Deployment example has been added in #9442

[saw-jan]

4. create API tests for CheckFileInfo

I see endpoint <ocis-wopi-server>/wopi/files/{fileid} that does CheckFileInfo.

• Does it return the file-info?
• Will curl request to this endpoint work with ocis basic-auth? (admin:admin)

CC @jvillafanez @rhafer @2403905

[jvillafanez]

The information is returned as a JSON object in the body of the response. The returned properties will depend on the target WOPI app:

• Microsoft: https://learn.microsoft.com/en-us/microsoft-365/cloud-storage-partner-program/rest/files/checkfileinfo
• OnlyOffice: https://api.onlyoffice.com/editors/wopi/restapi/checkfileinfo
• Collabora: https://sdk.collaboraonline.com/docs/advanced_integration.html#checkfileinfo-response-properties

The wopiserver doesn't have any authentication mechanism by itself, so basic auth isn't needed. However, it uses an access token and it forwards information contained in that access token to the reva storage.
We could build something to generate the url with the fileid and access token we need, but the question is where. An ocis collaboration createWOPIURL might be possible assuming a reva token is provided, although I'm not sure how secure it could be because anyone could use that url to access the file as long as the reva token is valid.

[saw-jan]

Then it looks like it is not possible to have normal API tests for this endpoint. Requires special setup which we don't know yet