richdocuments icon indicating copy to clipboard operation
richdocuments copied to clipboard
verified publisher icon nextcloud

feat: Add setup checks and verify WOPI connectivity

Open juliusknorr opened this issue 10 months ago • 17 comments

  • Add a setup check to verify that we are running the latest Collabora release
  • Add a setup check to verify connectivity with the collabora server
  • Extend the connectivity checks with using the new Collabora endpoint to verify WOPI access (that Collabora can reach Nextcloud)

Fixes https://github.com/nextcloud/richdocuments/issues/4267

Needs https://github.com/CollaboraOnline/online/issues/11162 for self-signed certificates that are not trusted on Collabora (without validation)

Screenshot 2025-02-13 at 23 03 14 Screenshot 2025-02-13 at 23 26 25

juliusknorr avatar Feb 13 '25 21:02 juliusknorr

Host "localhost" violates local access rules

Interesting integration test failure, wondering why it still worked fine before, maybe another collabora bug there or we just did not run into any WOPI call that could trigger it before?

juliusknorr avatar Feb 13 '25 22:02 juliusknorr

Host "localhost" violates local access rules

Interesting integration test failure, wondering why it still worked fine before, maybe another collabora bug there or we just did not run into any WOPI call that could trigger it before?

Maybe need to specify 'allow_local_remote_servers' => true, in the config.php.

Cf. \OC\Http\Client\Client::preventLocalAddress() on server

blizzz avatar Feb 13 '25 23:02 blizzz

Right, assumed it on the wrong (collabora) end.

juliusknorr avatar Feb 14 '25 00:02 juliusknorr

@meven I'm struggling to get CI passing as when the check runs Collabora returns an UnspecifiedError, however the status code is a 200 as far as I see in the logs.

Do you have any clue why that is not passing?

wsd-00001-00032 2025-03-20 21:32:08.932036 +0000 [ websrv_poll ] DBG  #30: Handling request: /hosting/wopiAccessCheck, closeConnection false| wsd/ClientRequestDispatcher.cpp:700
  wsd-00001-00032 2025-03-20 21:32:08.932046 +0000 [ websrv_poll ] DBG  #30: Wopi Access Check request: /hosting/wopiAccessCheck| wsd/ClientRequestDispatcher.cpp:1140
  wsd-00001-00032 2025-03-20 21:32:08.932087 +0000 [ websrv_poll ] DBG  Connecting to 172.17.0.1:8081 (Unencrypted)| net/NetUtil.cpp:458
  wsd-00001-00032 2025-03-20 21:32:08.932105 +0000 [ websrv_poll ] DBG  #-1: starting asyncRequest: GET 172.17.0.1:8081 /status.php| net/HttpRequest.hpp:1340
  wsd-00001-00032 2025-03-20 21:32:08.932112 +0000 [ websrv_poll ] DBG  #30: Handled request: /hosting/wopiAccessCheck, inBuf[sz 231 -> 54, rm 177], connection open true| wsd/ClientRequestDispatcher.cpp:994
  wsd-00001-00022 2025-03-20 21:32:08.932537 +0000 [ asyncdns ] DBG  #31: Created socket. Thread affinity set to 0x7fd3450006c0, Socket[#31, IPv4 @ :0]| net/Socket.hpp:474
  wsd-00001-00022 2025-03-20 21:32:08.932558 +0000 [ asyncdns ] DBG  #31 New socket connected to 172.17.0.1:8081 (Unencrypted)| net/NetUtil.cpp:517
  wsd-00001-00032 2025-03-20 21:32:09.116401 +0000 [ websrv_poll ] DBG  #31: Closed after reading. Read result: 0 errno: 0| net/Socket.hpp:1515
  wsd-00001-00032 2025-03-20 21:32:09.116470 +0000 [ websrv_poll ] DBG  #30: Wopi Access Check: got response state: State::Error , response status code: 200 (OK) , last errno: 0| wsd/ClientRequestDispatcher.cpp:1316
  wsd-00001-00032 2025-03-20 21:32:09.116522 +0000 [ websrv_poll ] INF  #30: Wopi Access Check request, result: UnspecifiedError| wsd/ClientRequestDispatcher.cpp:1226
  wsd-00001-00032 2025-03-20 21:32:09.116552 +0000 [ websrv_poll ] DBG  #31: Closed socket Socket[#31, IPv4 @ :0]| net/Socket.hpp:171
  wsd-00001-00032 2025-03-20 21:32:09.116588 +0000 [ websrv_poll ] DBG  #30: Closed socket Socket[#30, IPv6 @ ::ffff:172.18.0.1:64643]| net/Socket.hpp:171

juliusknorr avatar Mar 20 '25 21:03 juliusknorr

@meven Any further hint? Would be great to get this in

juliusknorr avatar Apr 29 '25 16:04 juliusknorr

@meven Any further hint? Would be great to get this in

Thank you for the ping, was really busy back in March.

  wsd-00001-00032 2025-03-20 21:32:09.116470 +0000 [ websrv_poll ] DBG  #30: Wopi Access Check: got response state: State::Error , response status code: 200 (OK) , last errno: 0| wsd/ClientRequestDispatcher.cpp:1316

Points toward an explicit error contacting the wopi/nextcloud host. The error could be improved, the fact the response Status code is 200 might point toward a bug.

This might be a bug in the insecure/HTTP code path.

Looking

meven avatar Apr 30 '25 13:04 meven

I haven't managed to find the origin. With 25.04, code has changed, would be curious to know if that changes something. A bit busy ATM, will be back on it.

meven avatar May 13 '25 13:05 meven

I'll do a rebase to see if the nightly code build now behaves different (that is one built from online master branch)

juliusknorr avatar May 14 '25 11:05 juliusknorr

It seems like your callballUrl request's response was empty and wasn't in one of the three case:

  • Response code was 10*
  • Response code was 204 (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/204)
  • Header had Content-Length = 0
  • The answer body had any content ("OK" for instance)

Consequently our http client considered this answer erroneous, as it prematurely disconnected.

(A 200 with no Content-Length, must have some content, as 204 is to be used when no Content is needed).

A curl -v request to your callback to your endpoint should reveal it.

Thanks @Ashod for helping on this.

meven avatar Jun 04 '25 12:06 meven

Thanks that is very helpful, let me push a step in CI run run that curl.

Content-Length missing rings a bell (https://cweiske.de/tagebuch/content-length-header-missing.htm) and locally i do see it sent back as a response header.

juliusknorr avatar Jun 04 '25 13:06 juliusknorr

Yes, it seems that when running the tests with the built-in webserver in CI we have a content but no content length.

I'm not sure that is expected as the response header should be optional even if we have some body.

I'll test if the tests pass if i switch to an empty response with 204 instead

 [4351] [Wed Jun  4 16:23:54 2025] [::1]:38488 [200]: GET /status.php
< HTTP/1.1 200 OK
< Host: localhost:8081
< Date: Wed, 04 Jun 2025 16:23:54 GMT
< Connection: close
< X-Powered-By: PHP/8.1.32
< Content-Security-Policy:default-src 'self'; script-src 'self' 'nonce-9WBcjYjKqk8FWft6yHCr/3ufHhm2GuyxynXmlilspWA='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: noindex, nofollow
< X-XSS-Protection: 1; mode=block
< Set-Cookie: nc_sameSiteCookielax=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: nc_sameSiteCookiestrict=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Access-Control-Allow-Origin: *
< Content-Type: application/json

@Ashod

juliusknorr avatar Jun 06 '25 10:06 juliusknorr

Yes, it seems that when running the tests with the built-in webserver in CI we have a content but no content length. I'm not sure that is expected as the response header should be optional even if we have some body.

It should be optional if you have some body (http streaming then), which coolwsd can detect. The only condition then, is the socket not to be closing with data mid-flight (as for other cases). If not that's a bug on coolwsd side. I am looking into it.

meven avatar Jun 06 '25 13:06 meven

I'll test if the tests pass if i switch to an empty response with 204 instead

Did you have the time for this ?

meven avatar Jul 16 '25 10:07 meven

Rebased again, Ci should tell if that makes a difference

juliusknorr avatar Oct 09 '25 19:10 juliusknorr

Failed to verify WOPI connectivity The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ The host for this request is not allowed to be used as a WOPI Host, this is likely a configuration issue in coolwsd.xml

From https://github.com/nextcloud/richdocuments/actions/runs/18386970418/job/52387713241?pr=4470

Is that a valid failure case, or is it that the Collabora instance has no wopi host set ? Just as a reminder Wopi host is set to host of the first incoming request by default. If a second host is needed it needs to be set in coolwsd.xml host (this can be done through command-line too).

meven avatar Oct 15 '25 08:10 meven

For the integration test that was the case. The interesting failure is in the cypress ones:

https://github.com/nextcloud/richdocuments/actions/runs/18386970434/job/52387705950?pr=4470

Checking configuration
🛈 Configured WOPI URL: http://localhost:9980
🛈 Configured public WOPI URL: http://localhost:9980
🛈 Configured callback URL: http://172.17.0.1:8081/

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.7.0
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Accepted
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 [200]: GET /status.php
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Closing
Failed to verify WOPI connectivity
The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ Unknown error "UnspecifiedError". Check the server logs of Collabora for more details.

You can also find the Collabora logs there if you unfold the stop container step: Screenshot 2025-10-16 at 08 37 05

juliusknorr avatar Oct 16 '25 06:10 juliusknorr

For the integration test that was the case. The interesting failure is in the cypress ones:

https://github.com/nextcloud/richdocuments/actions/runs/18386970434/job/52387705950?pr=4470

Checking configuration
🛈 Configured WOPI URL: http://localhost:9980
🛈 Configured public WOPI URL: http://localhost:9980
🛈 Configured callback URL: http://172.17.0.1:8081/

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.7.0
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Accepted
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 [200]: GET /status.php
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Closing
Failed to verify WOPI connectivity
The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ Unknown error "UnspecifiedError". Check the server logs of Collabora for more details.

You can also find the Collabora logs there if you unfold the stop container step: Screenshot 2025-10-16 at 08 37 05

For the integration test that was the case. The interesting failure is in the cypress ones:

https://github.com/nextcloud/richdocuments/actions/runs/18386970434/job/52387705950?pr=4470

Checking configuration
🛈 Configured WOPI URL: http://localhost:9980
🛈 Configured public WOPI URL: http://localhost:9980
🛈 Configured callback URL: http://172.17.0.1:8081/

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.7.0
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Accepted
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 [200]: GET /status.php
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Closing
Failed to verify WOPI connectivity
The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ Unknown error "UnspecifiedError". Check the server logs of Collabora for more details.

You can also find the Collabora logs there if you unfold the stop container step: Screenshot 2025-10-16 at 08 37 05

We can see in the logs that curl -v 172.17.0.1:8081/status.php returns 400 :

* Connected to 172.17.0.1 (172.17.0.1) port 8081
> GET /status.php HTTP/1.1
> Host: 172.17.0.1:8081
> User-Agent: curl/8.5.0
> Accept: */*
> 
[5002] [Thu Oct  9 19:33:34 2025] 10.197.43.98:58716 Accepted
[5002] [Thu Oct  9 19:33:34 2025] 10.197.43.98:58716 [400]: GET /status.php
< HTTP/1.1 400 Bad Request
< Host: 172.17.0.1:8081
< Date: Thu, 09 Oct 2025 19:33:34 GMT
< Connection: close
< X-Powered-By: PHP/8.2.29
< Content-Security-Policy:default-src 'self'; script-src 'self' 'nonce-GwaA7Hz0A+QiPtELP3PbPRvWlUzQ2lo8kPRVuB3chRw='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: noindex, nofollow
< Set-Cookie: nc_sameSiteCookielax=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: nc_sameSiteCookiestrict=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Content-Type: application/json

I checked the current wopiAccesCheck should send NotHttpSuccess, but it doesn't, I am checking if there is a bug.

meven avatar Oct 22 '25 13:10 meven