-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests for WOPI protocol #8712
Comments
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. 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 |
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. |
|
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 |
let's make it only in web for now. |
Deployment example has been added in #9442 |
I see endpoint
|
The information is returned as a JSON object in the body of the response. The returned properties will depend on the target WOPI app:
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. |
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 |
Maybe we can make use of this to get the required token: Lines 1098 to 1109 in f2c5077
|
That might work, yes.
I think you can get the wopisrc directly from the You'll likely need to send the access token (in the created "accesstoken" file) to the wopi server. Something like |
{
"BaseFileName": "afile.txt",
"DisablePrint": false,
"OwnerId": "33653562613161642d313433662d343137622d386265342d3232303863653733623737364068747470733a2f2f686f73742e646f636b65722e696e7465726e616c3a39323030",
"PostMessageOrigin": "https://localhost:9200",
"Size": 0,
"UserCanWrite": true,
"UserCanNotWriteRelative": false,
"UserId": "33653562613161642d313433662d343137622d386265342d3232303863653733623737364068747470733a2f2f686f73742e646f636b65722e696e7465726e616c3a39323030",
"UserFriendlyName": "Admin",
"EnableOwnerTermination": true,
"SupportsLocks": true,
"SupportsRename": true,
"UserCanRename": true,
"BreadcrumbDocName": "afile.txt"
} @jvillafanez I made a request with access_token and got this response. Is it the correct one? |
Yes, that's a good response. It will return the file info from the
Likely a bug, although I'm not entirely sure. |
Closing this one. API tests for |
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:
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 ?
The text was updated successfully, but these errors were encountered: