Onlyoffice vs Collabora in Nextcloud
-
@brandon220 said in Onlyoffice vs Collabora in Nextcloud:
@stacksofplates I am accessing as HTTPS. That is my issue with the proxy. It is breaking the connection to the document server somehow. I installed podman and I get errors when trying to pull down the container. Troubleshooting that now.
What address are you using for the document server? Are you using the internal address or the FQDN from the proxy and doing it through the proxy?
-
Will you show us your nginx config for OnlyOffice?
-
@stacksofplates FQDN because of the requirement for https. I only have 1 static ip on the WAN side hence the reason for the proxy. I could try putting certs directly on the OO server and using a different port. Just seems like a bunch of extra steps versus they way I would think it should work.
-
@black3dynamite Yes, I can grab it and post it this afternoon.
-
@brandon220 said in Onlyoffice vs Collabora in Nextcloud:
@stacksofplates FQDN because of the requirement for https. I only have 1 static ip on the WAN side hence the reason for the proxy. I could try putting certs directly on the OO server and using a different port. Just seems like a bunch of extra steps versus they way I would think it should work.
No you shouldn't need to do that. So you're accessing Nextcloud through HTTPS and it's forcing you to use HTTP to connect to OO? I wonder if it's because the interface on Nextcloud isn't using HTTPS because you're terminating the TLS at NGINX not the Nextcloud server itself. Just to get it working see if you can enter the IP of the OO server through HTTP there.
-
@stacksofplates True.... I was overthinking it.
If I try to use the local ip, it throws a mixed content error regarding https.Error when trying to connect (Mixed Active Content is not allowed. HTTPS address for Document Server is required.)
-
@brandon220 said in Onlyoffice vs Collabora in Nextcloud:
@stacksofplates True.... I was overthinking it.
If I try to use the local ip, it throws a mixed content error regarding https.Error when trying to connect (Mixed Active Content is not allowed. HTTPS address for Document Server is required.)
ok kind of cheating but what if you do
-p 443:80
to the container instead of-p 80:80
? Does it let you fake https then? I mean this would happen regardless of if it's a container or not. I guess I can see the point of Nextcloud wanting to not have mixed protocols but what about running things on localhost beside it? That seems like a strange decision. -
server { client_max_body_size 40M; server_name office.domain.org; proxy_set_header X-Forwarded-Host $http_host/editors; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-NginX-Proxy true; proxy_redirect off; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass http://192.168.1.106; add_header X-Frame-Options "ALLOW-FROM https://nc.domain.org/" always; proxy_redirect off; # Socket.IO Support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } ssl_stapling on; ssl_stapling_verify on; ssl_session_cache shared:SSL:10m; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; # listen 80; listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/office.domain.org/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/office.domain.org/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { listen 80; location / { proxy_pass_header Server; proxy_pass http://nc/; } } server { client_max_body_size 40M; listen 80; server_name office.domain.org; return 301 https://$host$request_uri;
-
So even without HTTPS and pointing Nextcloud to NGINX for accessing Onlyoffice it doesn't work. I would run Onlyoffice with both https and http ports open and see if it works directly accessing Onlyoffice like you did above.
podman run -it -d -p 443:443 -p 80:80 --restart=always onlyoffice/documentserver
-
@brandon220 said in Onlyoffice vs Collabora in Nextcloud:
proxy_pass http://192.168.1.106;
Your backend box has no SSL. Likely something is getting confused. Wordpress has problems like this when behind a proxy.
Make a snapshot, add a self signed cert on your backend system and change the proxy to point to that.
What does that do to your functoinality?
-
@JaredBusch I’m sure you are right. I can access the document server via https through the proxy with the current config. Nextcloud can connect to it https. There is an error however in the browser (when you open the developer tools and view the console) and the document content never loads. I am trying so hard to avoid installing Docker, podman, etc on the NC server.
-
@brandon220 said in Onlyoffice vs Collabora in Nextcloud:
@JaredBusch I’m sure you are right. I can access the document server via https through the proxy with the current config. Nextcloud can connect to it https. There is an error however in the browser (when you open the developer tools and view the console) and the document content never loads. I am trying so hard to avoid installing Docker, podman, etc on the NC server.
I honestly have no clue. It is simply speculation based on prior experience with shit behind a proxy.
-
@JaredBusch Understood. Just frustrating when all the other hosts I have behind a proxy work perfect.
I’m just afraid it would work ok with the document server running on the NC server (as a container) but not be able to keep up with heavy use. I have learned to keep workloads separate.
-
I’ll have to take my test vm and put the cert directly on it and test the functionality.
-
@brandon220 said in Onlyoffice vs Collabora in Nextcloud:
I’ll have to take my test vm and put the cert directly on it and test the functionality.
You don't need a valid cert from a CA behind the proxy.
You just need a cert. That is why I said self signed. It is still encrypted. There is nothing wrong with the encryption of self signed certs.
For your Proxy to talk to the backend piece, you control it all so there is no trust issue with the public. The self signed cert will never be seen.
-
@JaredBusch makes sense. I’ll give it a try tomorrow.
-
This post is deleted! -
Update:
I was able to get it working with a self-signed certificate and the functionality is great. I had NC connected to the OO server with https://localip That worked fine but once left my LAN, from the web it tried to resolve the local ip. That of course will not work and it does zero good to only work while you are on the LAN. I was unsuccessful at getting the self-signed cert to work behind nginx reverse proxy.
Is it possible to just have nginx forward http to the OO server and:- Allow Letsencrypt to verify and issue the certs
- Actually function behind the proxy if the actual cert is on the OO server directly. I cannot find any good documentation of OO working properly behind the reverse proxy in the normal sense.