Collabora unable to open documents, coolwsd can't seem to collabora-te with Apache's proxy #2192
Comments
|
I finally was able to find the answer and make it work! For others in the same situation, in my case, it was due to the fact that I was not using the Secure Web Socket protocol (wss) even though I was using HTTPS. So I just had to replace this: With this: |
|
|
|
I have the same problem but with Nginx reverse proxy, I think the official configuration |
|
I've made it work, the problem wasn't in Nginx reverse proxy configuration, but automatically included |
|
@waclaw66 what did you end up doing to bypass the .php processing? I'm facing the same issue and fell on this...which gives me hope! Looking forward to hear back! |
I've used php settings from recommended configuration instead of default php configuration from nginx (/etc/nginx/default.d/php.conf). |
|
Thanks @waclaw66....guess that wasn't my issue...totally. I think I have a combination of issues here....same wss: error after using the recommended configs as suggested. From an infrastructure side, my setup is as follows: INTERNET -> Nginx Reverse-Proxy (secured with Let's encrypt) -> internal processes (collabora and nextcloud on independant VMs using Nginx web server (no proxying, no ssl for the internal servers)). Everything seems to work with NextCloud and the connection to Collabora is confirmed...only when I try to create or open documents does it fail: WebSocket connection to 'wss://COLLABDOMAIN/cool/https%3A%2F%2FNEXTCLOUDDOMAIN%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F166_ocg49un0fzeh%3Faccess_token%3DkHyMlMSrxwLGqgUZ7ez6eZIAE53xk5SZ%26access_token_ttl%3D1673592859000%26permission%3Dedit/ws?WOPISrc=https%3A%2F%2FNEXTCLOUDDOMAIN%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F166_ocg49un0fzeh&compat=/ws' failed: It's clearly failing to create the websocket while looking for wss:// where it doesn't show anywhere in my reverse proxy...a bit lost here...I'm sure it's something simple that I'm overlooking. This is my current websocket clip from the reverse proxy (Nginx): When I change my proxy_pass directive to use ws: (which is what I want) or wss:, nginx -t errors out...and nginx fails to start. I've turned off everything I can think of in terms of SSL Nextcloud server side to force ws:// instead of wss:// as that's handled by the reverse-proxy (secured)...no matter what, it's still trying to open up a secure socket....which if I was a betting man this is probably the issue (paired with no wss:// in the reverse proxy) seeing as both the collabora and nextcloud server don't use ssl internally....I'm just out of ideas where to look. I don't want to hijack anything and I'll start a new thread if needed but I figured given the .php angle that had me hopeful, this might be the best place to carry-on. Appreciate any insight. Cheers! |
|
Im having the same issues. And they came on suddenly and without warning. Everything was working, and now it isnt and Im getting permission errors. |
I spent so much time on this, I knew that when I connect to web socket the |
|
can you share your nginx config settings? |
Please share the nginx config file |
upstream php-handler {
server 127.0.0.1:9001;
}
# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
"" "";
default "immutable";
}
server {
listen 443 ssl http2;
server_name removed;
# Path to the root of your installation
root /home/nextcloud/nextcloud;
ssl_certificate /etc/letsencrypt/live/removed/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/removed/privkey.pem;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
access_log /var/log/nginx/nextcloud.access.log;
error_log /var/log/nginx/nextcloud.error.log;
# Prevent nginx HTTP Server Detection
server_tokens off;
# HSTS settings
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
# set max upload size and increase upload timeout
client_max_body_size 512M;
client_body_timeout 300s;
fastcgi_buffers 64 4K;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Pagespeed is not supported by Nextcloud, so if your server is built
# with the `ngx_pagespeed` module, uncomment this line to disable it.
#pagespeed off;
# The settings allows you to optimize the HTTP2 bandwitdth.
# See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
# for tunning hints
client_body_buffer_size 512k;
# HTTP response headers borrowed from Nextcloud `.htaccess`
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;
# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
# Specify how to handle directories -- specifying `/index.php$request_uri`
# here as the fallback means that Nginx always exhibits the desired behaviour
# when a client requests a path that corresponds to a directory that exists
# on the server. In particular, if that directory contains an index.php file,
# that file is correctly served; if it doesn't, then the request is passed to
# the front-end controller. This consistent behaviour means that we don't need
# to specify custom rules for certain paths (e.g. images and other assets,
# `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
# `try_files $uri $uri/ /index.php$request_uri`
# always provides the desired behaviour.
index index.php index.html /index.php$request_uri;
# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
location = / {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The rules in this block are an adaptation of the rules
# in `.htaccess` that concern `/.well-known`.
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }
# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /index.php$request_uri;
}
# Rules borrowed from `.htaccess` to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }
# main websocket
location ~ ^/cool/(.*)/ws$ {
proxy_pass http://127.0.0.1:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
# Required for legacy support
rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_max_temp_file_size 0;
}
location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463, $asset_immutable";
access_log off; # Optional: Don't log access to assets
location ~ \.wasm$ {
default_type application/wasm;
}
}
location ~ \.woff2?$ {
try_files $uri /index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from `.htaccess`
access_log off; # Optional: Don't log access to assets
}
# Rule borrowed from `.htaccess`
location /remote {
return 301 /remote.php$request_uri;
}
# static files
location ^~ /browser {
proxy_pass http://127.0.0.1:9980;
proxy_set_header Host $http_host;
}
# WOPI discovery URL
location ^~ /hosting/discovery {
proxy_pass http://127.0.0.1:9980;
proxy_set_header Host $http_host;
}
# Capabilities
location ^~ /hosting/capabilities {
proxy_pass http://127.0.0.1:9980;
proxy_set_header Host $http_host;
}
# download, presentation and image upload
location ~ ^/(c|l)ool {
proxy_pass http://127.0.0.1:9980;
proxy_set_header Host $http_host;
}
# Admin Console websocket
location ^~ /cool/adminws {
proxy_pass http://127.0.0.1:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
location ^~ /push/ {
proxy_pass http://127.0.0.1:7867/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location / {
try_files $uri $uri/ /index.php$request_uri;
}
}
server {
listen 80;
server_name removed;
# Prvent nginx HTTP Server Detection
server_tokens off;
# Enforce HTTPS
return 301 https://$server_name$request_uri;
} |
What manual did you use to deploy? |
|
A few I guess, official one plus I combined it with what is written on collabora website, plus something more I guess… |
|
I can confirm that put websocket stanza on top of php settings solved the issue! |
Describe the bug
Hello! I am trying to get Collabora to work on our subdomain (Debian 11). I did a fresh installation (without docker) using the collaboraoffice.com packages here.
I think NextCloud is going to be a game-changer, but I am stuck with this. Can you please help me?
I configured Collabora and it is working and listening on localhost:
NextCloud detects Collabora nicely as you can see.
However, when I try to create or open a new document, I had the dreaded white screen of death:
These are the logs from Apache:
Which seems to indicate some kind of Proxy error. If I navigate to
https:/cloud.mydomain.com/index.php/apps/richdocuments/wopi/files/672_ocmaqq15fyvi?access_token=hWzvsopvM1WhwyRuVxUPJ2EEqtb1nVSy&access_token_ttl=0&permission=edit/wsI see the information perfectly displayed:I also see these from time to time:
But SSLProxyEngine is On.
The browser's log may indicate some kind of issue with the Web Socket connection:
However, my Apache configuration follows the official documentation.
If I go to https://collabora.mydomain.com/cool, I get a "This page is not working" 400 error.
Curl (see log in details below) does not show any particular error, just closes the connection with a 400.
I have tried the solutions shown here, including:
Without success.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I should be able to open and edit the document.
Screenshots
See above.
Client details:
Server details
Operating system: Debian Linux 11
Web server: Apache 2.4.53
Database: MariaDB 1:10.5.15-0+deb11u1
PHP version: PHP 7.4.28 (cli) (built: Feb 17 2022 16:17:19) ( NTS )
Nextcloud version: 24.0.0
Version of the richdocuments app Didn't find this, if this is "Text", it is 3.5.1.
Version of Collabora Online NextCloud Office 6.0.0
Logs
See above
Nextcloud log (data/nextcloud.log)
Browser log
Curl to /cool locally log:
The text was updated successfully, but these errors were encountered: