DocumentServer
DocumentServer copied to clipboard
OnlyOffice uses HTTP instead of HTTPS in browser requests (reverse proxy)
This issue is unique.
- [x] I have used the search tool and did not find an issue describing my bug.
Note: This issue may be related to https://github.com/ONLYOFFICE/DocumentServer/issues/2083 because some of the errors seem similar, but there are also many other errors mentioned that I have not seen
Operating System of DocumentServer
Docker
Version information
v7.3.2.8 & v7.3.3.49
Expected Behavior
I expected the request from the JS code in the web-browser to send requests using HTTPS not using HTTP.
Note: The browser connects to Nextcloud over HTTPS
I was unable to verify if this worked on older versions of OnlyOffice
Actual Behavior
The JS code running in the browser send the request using HTTP, not HTTPS
Note: The browser connects to Nextcloud over HTTPS
Reproduction Steps
- Go to the Nextcloud instance in the web-browser
- Create a "New spreadsheet" file
- Click on the "New spreadsheet.xlsx" file to open it, see screenshot
- Now you will see the error message from OnlyOffice, see the screenshot
- If you open the browser console, you will see that the error saying that the content is blocked because you try to load content from both HTTP and HTTPS (seems to be a security policy enabled by something in a header or metadata on an HTML page - Learn More).
Blocked loading mixed active content “http://onlyoffice.EXAMPLE.COM/cache/files/data/3304616191/Editor.bin/Editor.bin?md5=EV5BqECOklqjXAMkT6PXCg&expires=1682113345&filename=Editor.bin”
- If we go to the source code, by clicking on
sdk-all-min.js:512:36
(orsdk-all-min.js:formatted:14179
if you have selected "Pretty print source") and set a breakpoint and retry the hole think we will get something looking like the following screenshot - In the screenshot we can see that the URL for the variable
Wb
is HTTP and not HTTPS and that is there the problem lies, changing thehttp://
tohttps://
resolves the problem.
I really hope this can help someone track down and fix this bug.
Additional information
Setup
Docker setup files: onlyoffice_bug.zip
-
cd
into the folder from the unpacked zip-file - Run the command to start Traefik
docker-compose -f traefik-docker/docker-compose.yml up -d
- Config the
DOMAIN_BASE
variable for innextcloud-docker/.env
- Run the command to start Nextcloud with OnlyOffice
docker-compose -f nextcloud-docker/docker-compose.yml up -d
- Login to the Nextcloud setup
- Install OnlyOffice App
- Config Nextcloud according to the screenshot
(Hacky) Workaround — The original way I tried to get around this
- Run the following command
# Patch file
docker compose exec onlyoffice sed -E -i 's|(function +\w+\(\w+\) *\{ *function +\w+\(\)) *\{ *(\w+)\.open\((\w+),(\w+),(\w+)\);|\1{\nif (\4 \&\& \4.length > 5) {if (\4.substring(0, 5) == "http:") {\4 = \4.replace("http://", "https://");}};\n\2.open(\3,\4,\5);\n|' /var/www/onlyoffice/documentserver/sdkjs/cell/sdk-all-min.js
# Restart container
docker-compose restart onlyoffice
-
Clean all cached data for Nextcloud and OnlyOffice in your browser, or try with browser in private mode.
-
Now everything should work for spreadsheet files, but if you want it to work for document- & presentation-files you also need to patch
/var/www/onlyoffice/documentserver/sdkjs/word/sdk-all-min.js
and/var/www/onlyoffice/documentserver/sdkjs/word/sdk-all-min.js
.
(Update) Workaround — The better way to work around this
Added the header Content-Security-Policy
with upgrade-insecure-requests
to the config for your chosen reverse proxy.
Thanks to @Cryxto for the solutions: https://github.com/ONLYOFFICE/DocumentServer/issues/2186#issuecomment-1673182604
I also updated the docker-compose.yml so Traefik will apply the workaround: https://github.com/ONLYOFFICE/DocumentServer/issues/2186#issuecomment-1676150397
Showing that the X-Forwarded-*
headers are set by the reverse proxy
The IP of:
- The docker subnet gateway: 172.18.0.1
- OnlyOffice container: 172.18.0.2
- The server IP (Real IP): 192.168.1.131
I am using Traefik as the reverse-proxy/ssl off-loading, so to make sure that Traefik sets the X-Forwarded-*
headers I used Wireshark to capture the decrypted trafic between Traefik and the OnlyOffice container.
I wonder if this is specific to the use of Docker, I haven't had an issue like this with the .deb
package and I have Firefox set to Enable HTTPS-Only Mode in all windows.
I'd suggest raising this issue on the forum, issues raised here don't always get the same attention as they get when raised on their Discourse instance.
What version of OnlyOffice are you running? And have you configured "Advanced server settings" Nextcloud?
Regarding raising the problem on the forum, I added a link to this issue in a thread, there it sounds like the original poster is having the same problem. https://forum.onlyoffice.com/t/adding-documentserver-to-existing-traefik-proxy-works-halfway-but-cannot-open-documents/3239/6
For now, this is my workaround, having docker-compose apply the workaround to the container
FROM onlyoffice/documentserver:latest
### Apply patch to fix bug
# Source: https://github.com/ONLYOFFICE/DocumentServer/issues/2186
# Worked on the 01/04/2023 with version 7.3.3.49
RUN find /var/www/onlyoffice/documentserver -name sdk-all-min.js | xargs -n 1 sed -E -i 's|(function +\w+\(\w+\) *\{ *function +\w+\(\)) *\{ *(\w+)\.open\((\w+),(\w+),(\w+)\);|\1{\nif (\4 \&\& \4.length > 5) {if (\4.substring(0, 5) == "http:") {\4 = \4.replace("http://", "https://");}};\n\2.open(\3,\4,\5);\n|'
I'm not using Docker:
apt-cache policy onlyoffice-documentserver | grep Installed
Installed: 7.3.3-49~stretch
But so far only on a development server, for these fields:
- ONLYOFFICE Docs address
- ONLYOFFICE Docs address for internal requests from the server
- Server address for internal requests from ONLYOFFICE Docs
I have the same fully qualified HTTPS URL, Nginx is proxying all the traffic to the application.
These files:
find /var/www/onlyoffice/documentserver/ -name sdk-all-min.js
/var/www/onlyoffice/documentserver/sdkjs/word/sdk-all-min.js
/var/www/onlyoffice/documentserver/sdkjs/slide/sdk-all-min.js
/var/www/onlyoffice/documentserver/sdkjs/cell/sdk-all-min.js
Do contain http:
strings:
grep "http:" /var/www/onlyoffice/documentserver/sdkjs/word/sdk-all-min.js
var wb=Fa.slice(0,6);return 0===wb.indexOf("theme")&&editor.pO?editor.pO.sQb+Fa:0!==wb.indexOf("http:")&&0!==wb.indexOf("data:")&&0!==wb.indexOf("https:")&&0!==wb.indexOf("file:")&&0!==wb.indexOf("ftp:")&&(wb=vs.Cda(Fa))?wb:Fa}function Hd(Fa){return 55296<=Fa&&57343>=Fa}function Td(Fa,wb){return 56320>Fa&&56320<=wb&&57343>=wb?65536+((Fa&1023)<<10)|wb&1023:null}function Vd(Fa){if(65536>Fa)return String.fromCharCode(Fa);Fa-=65536;var wb=56320|Fa&1023;return String.fromCharCode(55296|Fa>>10)+String.fromCharCode(wb)}
Fa.ZZb(Ci)?AscCommon.Nxa.aNc:AscCommon.Nxa.dNb:Fa.ZZb(Zm)?AscCommon.Nxa.aNc:AscCommon.Nxa.dNb};I.AscCommon.ngd=function(Fa,wb){Zm.test(Fa)||(Fa=(AscCommon.Nxa.ZGb==wb?"mailto:":"http://")+Fa);return Fa.replace(/%20/g," ")};I.AscCommon.oIb=function(Fa,wb,ac,rc){if(!(Fa&&""!==Fa||wb&&""!==wb))return new Pn(0,0,0,255);if(of.hasOwnProperty(Fa))Fa=of[Fa];else if(of.hasOwnProperty(wb))Fa=of[wb];else{var oc=Asc.b8e[gv%Asc.b8e.length];++gv;Fa=of[Fa||wb]=new ra(oc)}if(!Fa)return new Pn(0,0,0,255);ac=!0===
Asc.nme,Nc)||Nc(!1,D)}};Lc.prototype.r8c=function(Gb){(editor||Asc.editor).jNf(Gb)};Lc.prototype.Ywe=function(){var Gb=editor||Asc.editor,Ea=[],xc,Nc={},rd=this.Oza,md={};for(xc=0;xc<rd.length;++xc){var xb=rd[xc];md[xb]||(md[xb]=1,0===xb.indexOf("theme")&&Gb.pO?Nc[xb]=Gb.pO.sQb+xb:0!==xb.indexOf("http:")&&0!==xb.indexOf("data:")&&0!==xb.indexOf("https:")&&0!==xb.indexOf("file:")&&0!==xb.indexOf("ftp:")&&(xb=AscCommon.OA.Fla+xb,AscCommon.OA.xUc(xb)||Ea.push(xb)))}AscCommon.OA.jGa(Nc);return Ea};Lc.prototype.OMe=
grep "http:" /var/www/onlyoffice/documentserver/sdkjs/slide/sdk-all-min.js
var wb=Fa.slice(0,6);return 0===wb.indexOf("theme")&&editor.pO?editor.pO.sQb+Fa:0!==wb.indexOf("http:")&&0!==wb.indexOf("data:")&&0!==wb.indexOf("https:")&&0!==wb.indexOf("file:")&&0!==wb.indexOf("ftp:")&&(wb=vs.Cda(Fa))?wb:Fa}function Hd(Fa){return 55296<=Fa&&57343>=Fa}function Td(Fa,wb){return 56320>Fa&&56320<=wb&&57343>=wb?65536+((Fa&1023)<<10)|wb&1023:null}function Vd(Fa){if(65536>Fa)return String.fromCharCode(Fa);Fa-=65536;var wb=56320|Fa&1023;return String.fromCharCode(55296|Fa>>10)+String.fromCharCode(wb)}
Fa.ZZb(Ci)?AscCommon.Nxa.aNc:AscCommon.Nxa.dNb:Fa.ZZb(Zm)?AscCommon.Nxa.aNc:AscCommon.Nxa.dNb};I.AscCommon.ngd=function(Fa,wb){Zm.test(Fa)||(Fa=(AscCommon.Nxa.ZGb==wb?"mailto:":"http://")+Fa);return Fa.replace(/%20/g," ")};I.AscCommon.oIb=function(Fa,wb,ac,rc){if(!(Fa&&""!==Fa||wb&&""!==wb))return new Pn(0,0,0,255);if(of.hasOwnProperty(Fa))Fa=of[Fa];else if(of.hasOwnProperty(wb))Fa=of[wb];else{var oc=Asc.b8e[gv%Asc.b8e.length];++gv;Fa=of[Fa||wb]=new ra(oc)}if(!Fa)return new Pn(0,0,0,255);ac=!0===
Asc.nme,Nc)||Nc(!1,D)}};Lc.prototype.r8c=function(Gb){(editor||Asc.editor).jNf(Gb)};Lc.prototype.Ywe=function(){var Gb=editor||Asc.editor,Ea=[],xc,Nc={},rd=this.Oza,md={};for(xc=0;xc<rd.length;++xc){var xb=rd[xc];md[xb]||(md[xb]=1,0===xb.indexOf("theme")&&Gb.pO?Nc[xb]=Gb.pO.sQb+xb:0!==xb.indexOf("http:")&&0!==xb.indexOf("data:")&&0!==xb.indexOf("https:")&&0!==xb.indexOf("file:")&&0!==xb.indexOf("ftp:")&&(xb=AscCommon.OA.Fla+xb,AscCommon.OA.xUc(xb)||Ea.push(xb)))}AscCommon.OA.jGa(Nc);return Ea};Lc.prototype.OMe=
grep "http:" /var/www/onlyoffice/documentserver/sdkjs/cell/sdk-all-min.js
var wb=Fa.slice(0,6);return 0===wb.indexOf("theme")&&editor.pO?editor.pO.sQb+Fa:0!==wb.indexOf("http:")&&0!==wb.indexOf("data:")&&0!==wb.indexOf("https:")&&0!==wb.indexOf("file:")&&0!==wb.indexOf("ftp:")&&(wb=vs.Cda(Fa))?wb:Fa}function Hd(Fa){return 55296<=Fa&&57343>=Fa}function Td(Fa,wb){return 56320>Fa&&56320<=wb&&57343>=wb?65536+((Fa&1023)<<10)|wb&1023:null}function Vd(Fa){if(65536>Fa)return String.fromCharCode(Fa);Fa-=65536;var wb=56320|Fa&1023;return String.fromCharCode(55296|Fa>>10)+String.fromCharCode(wb)}
Fa.ZZb(Ci)?AscCommon.Nxa.aNc:AscCommon.Nxa.dNb:Fa.ZZb(Zm)?AscCommon.Nxa.aNc:AscCommon.Nxa.dNb};I.AscCommon.ngd=function(Fa,wb){Zm.test(Fa)||(Fa=(AscCommon.Nxa.ZGb==wb?"mailto:":"http://")+Fa);return Fa.replace(/%20/g," ")};I.AscCommon.oIb=function(Fa,wb,ac,rc){if(!(Fa&&""!==Fa||wb&&""!==wb))return new Pn(0,0,0,255);if(of.hasOwnProperty(Fa))Fa=of[Fa];else if(of.hasOwnProperty(wb))Fa=of[wb];else{var oc=Asc.b8e[gv%Asc.b8e.length];++gv;Fa=of[Fa||wb]=new ra(oc)}if(!Fa)return new Pn(0,0,0,255);ac=!0===
Asc.nme,Nc)||Nc(!1,D)}};Lc.prototype.r8c=function(Gb){(editor||Asc.editor).jNf(Gb)};Lc.prototype.Ywe=function(){var Gb=editor||Asc.editor,Ea=[],xc,Nc={},rd=this.Oza,md={};for(xc=0;xc<rd.length;++xc){var xb=rd[xc];md[xb]||(md[xb]=1,0===xb.indexOf("theme")&&Gb.pO?Nc[xb]=Gb.pO.sQb+xb:0!==xb.indexOf("http:")&&0!==xb.indexOf("data:")&&0!==xb.indexOf("https:")&&0!==xb.indexOf("file:")&&0!==xb.indexOf("ftp:")&&(xb=AscCommon.OA.Fla+xb,AscCommon.OA.xUc(xb)||Ea.push(xb)))}AscCommon.OA.jGa(Nc);return Ea};Lc.prototype.OMe=
But there are no mixed content issues when editing document via Nextcloud.
We encounter the same issue. Do you have an idea for the resolution date? Thank you
@jm-bertheas-datailor I'd suggest asking about this on the ONLYOFFICE forum as threads there appear to get more attention than issues here.
@chriscroome http:
strings hardcoded in js files shouldn't be an issue (those are used for e. g. hyperlinks in documents, not for communicating with DocumentServer). The http:
that causes this bug is rather passed from the backend over a websocket, so it's most likely a server bug (and JS patches here are just hotfixes). Perhaps it doesn't reproduce in your config? You can check by opening devtools and looking for a websocket connection when you open a document, then look for a string like this: http://onlyoffice.example.com/cache/files/data/42......
– if it starts with https:
, your setup is working (for now :^)
I don't really want to rebuild an image just to patch this bug. So, I've came up with an even more hacky workaround – you can modify the entrypoint!
services:
onlyoffice-document-server:
image: onlyoffice/documentserver:latest
entrypoint:
- "sh"
- "-c"
- |
echo 'patching https://github.com/ONLYOFFICE/DocumentServer/issues/2186...'
find /var/www/onlyoffice/documentserver -name sdk-all-min.js -exec sed -E -i 's|(function +\w+\(\w+\) *\{ *function +\w+\(\)) *\{ *(\w+)\.open\((\w+),(\w+),(\w+)\);|\1{\nif (\4 \&\& \4.length > 5) {if (\4.substring(0, 5) == "http:") {\4 = \4.replace("http://", "https://");}};\n\2.open(\3,\4,\5);\n|' '{}' ';'
echo 'done! starting server...'
/app/ds/run-document-server.sh
...
This kinda works (don't forget to clear your browser cache), but I haven't tested this very extensively, so YMMV.
I don't really want to rebuild an image just to patch this bug. So, I've came up with an even more hacky workaround
I love it :joy: but hopefully, someone at OnlyOffice is going to resolve :sweat_smile:
Thanks @notpushkin, all the requests I can see via the Firefox debugger use HTTPS including the ones that have sdk-all-min.js
listed as the initiator, perhaps I don't appear to have this issue as a result of using the deb package rather than the Docker version? :man_shrugging:
Having the same issue. @notpushkin thank you for that workaround
Having the same issue.
Same issue, sad thing we cant push issues on https://github.com/ONLYOFFICE/sdkjs, because its clearly the source of the problem. Thanks for the workarounds and congratulations to @dvaerum for this detailled issue report
I finally resolved this issue temporarily by modifying sdk js to replace "http"
with "https"
.
./sdkjs/cell/sdk-all-min.js ./sdkjs/word/sdk-all-min.js ./sdkjs/slide/sdk-all-min.js
function ve(uc){function wd(){
// modify variable < Rd >
.......
}}
Ryc: function(uc) {
var _urls = this.urls ? this.urls[uc] : null;
// modify variable < _urls >
return _urls;
},
@Ramon403 Yeah, this is pretty much the way to go. Above in the thread you can see a couple variants of bash one-liners that will patch those for you, too.
@GoshaZotov I've noticed you're a maintainer on the sdkjs repo. Could you please take a look at the bug described above (and maybe help escalate it internally)?
i am using cloudflare tunnel that point to nginx proxy manager to become a router , proxy, and ssl manager of my docker service. I managed to do it on local network but not if each (owncloud and onlyoffice doc server) on public domain . I already try to do thing that mentioned above but still. If i click the link it is loading but like forever
Hey @Cryxto, have you cleaned you web-browser cache after applying the workaround? Also, I have never used cloudflare myself, but it is my understanding that they also caches stuff, so you should probably verify that they didn’t cache the old file either.
Hope this helps
@dvaerum , yep i already clean the cache. For local network it is cannot download , the request using local address is https (which is good). But for my domain with https (as describe above in my previous comment) not work and it still http.
Hej @Cryxto
I just checked my setup, which used onlyoffice/documentserver:latest
and pull every Monday, and OnlyOffice was also broken for me. So, I re-deploy v7.3 (onlyoffice/documentserver:7.3
) and now it works :smiley:
So it looks like the work workaround is broken for v7.4.* of OnlyOffice which was released to Docker Hub on the Jun 13, 2023 at 13:47 https://hub.docker.com/layers/onlyoffice/documentserver/7.4.0.1/images/sha256-3aa7e2f5e6c1b5949284e1adedcc9b129d343b68227a00358d44224410e2482b?context=explore
So, give onlyoffice/documentserver:7.3
a try and if that works for you with the workaround when we know what the problem was, and we either need to update the workaround or try to fix the root cause fixed, be it by a patch or pushing to OnlyOffice.
Ah thanks @dvaerum , i will give it a try 👌
btw when do the docker compose version, how to get the v7.3 version? when i see the docker compose on official onlyoffice example, it downloaded the latest.
@dvaerum i manage to set for 7.3 version , but the result still the same
@Cryxto I am mostly out of ideas then, I guess you can try to do the setup without Cloudflare and see if that works, mostly just to try to isolate the problem to as few variables as possible.
You can also try to use my demo setup using docker-compose onlyoffice_bug.zip, that should give you a starting point.
@dvaerum thx for the suggestion and advice, maybe i will stay on local for onlyoffice (which is left me a bit unsatisfied). I use cf tunnel because i don't want to directly expose my home lab port. Dem i don't know why when under cf tunnel and nginx proxy manager the edit request made on http LMAO.
just note here @dvaerum , i finally able to make it work by add this config on owncloud side
CMIIW , i think it tell the browser to force connect to https.
I am using only docker compose and production dockerfile from official docker document server
Hey @Cryxto Base on what Mozilla writes https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests I will say you are correct, I'm going to try this because that looks like a way better workaround for OnlyOffice when trying patch opacificated JavaScript files.
Also, awesome you were able to find a way to make it work :tada:
Hey @Cryxto
I spent most of my evening playing around with this, and I can confirm that your workaround works for me on version 7.3. I just have to add it into the docker-compose.yml file, by injecting in between line 183 and 184 :tada:
- "traefik.http.routers.onlyoffice_https.rule=Host(`${DOMAIN_ONLYOFFICE}`)"
# Workaround a bug in OnlyOffice, see the issue tracker: https://github.com/ONLYOFFICE/DocumentServer/issues/2186
- "traefik.http.middlewares.onlyoffice_redirect_http2https_header.headers.contentSecurityPolicy=upgrade-insecure-requests"
- "traefik.http.routers.onlyoffice_https.middlewares=onlyoffice_redirect_http2https_header"
# Get SSL/TLS certificate from Let's Encrypt by resolving the HTTPS challenge.
The entire file: docker-compose.yml
I have also been playing around with version 7.4, and I found that the reason I could not make it work (when I tried previously https://github.com/ONLYOFFICE/DocumentServer/issues/2186#issuecomment-1650105259) was not because of the original bug I reported, but because OnlyOffice would not connect to a Nextcloud running on a private IP (which I guess makes sense if one is selling OnlyOffice SAAS (Software As A Service).
I found that the following gets written to the containers log every time I try to open a document in Nextcloud
[2023-08-12T22:36:45.682] [ERROR] [localhost] [4038710854] [oce2k2hppxz7_dennis] nodeJS - error downloadFile:url=http://nextcloud.varum.dk/apps/onlyoffice/download?doc=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhY3Rpb24iOiJkb3dubG9hZCIsImZpbGVJZCI6MTY3LCJ1c2VySWQiOiJkZW5uaXMifQ.mOT2We9m6--NIEo7lK-ZKrutWMSUPyAJYu0TtlVfh9M;attempt=1;code:undefined;connect:undefined Error: DNS lookup 192.168.48.6(family:4, host:nextcloud.varum.dk) is not allowed. Because, It is private IP address.
So after some searching, I found this. https://helpcenter.onlyoffice.com/installation/docs-developer-configuring.aspx#RequestFilteringAgent
So I did a quick grep
inside the OnlyOffice container
root@c015fcaa67fd:/# grep -r allowPrivateIPAddress /etc
/etc/onlyoffice/documentserver/development-mac.json: "allowPrivateIPAddress": true,
/etc/onlyoffice/documentserver/development-windows.json: "allowPrivateIPAddress": true,
/etc/onlyoffice/documentserver/default.json: "allowPrivateIPAddress": false,
/etc/onlyoffice/documentserver/development-linux.json: "allowPrivateIPAddress": true,
and found that allowPrivateIPAddress
in /etc/onlyoffice/documentserver/default.json
was set to false
.
Therefore, added to my Dockerfile for OnlyOffice
RUN sed -i -E 's|("allowPrivateIPAddress":) *false *,|\1 true,|' /etc/onlyoffice/documentserver/default.json
but I am certain that the trick from @notpushkin also will work (https://github.com/ONLYOFFICE/DocumentServer/issues/2186#issuecomment-1546698178)
services:
onlyoffice-document-server:
image: onlyoffice/documentserver:latest
entrypoint:
- "sh"
- "-c"
- |
echo 'patching https://github.com/ONLYOFFICE/DocumentServer/issues/2186...'
sed -i -E 's|("allowPrivateIPAddress":) *false *,|\1 true,|' /etc/onlyoffice/documentserver/default.json
echo 'done! starting server...'
/app/ds/run-document-server.sh
...
and that is it. Now, OnlyOffice v7.4 also works for me, but I still to work around the bug I originally reported.
I would, however, recommend the added the header Content-Security-Policy: upgrade-insecure-requests
which @Cryxto found/discovered.
Hey @Cryxto
I spent most of my evening playing around with this, and I can confirm that your workaround works for me on version 7.3. I just have to add it into the docker-compose.yml file, by injecting in between line 183 and 184 🎉
- "traefik.http.routers.onlyoffice_https.rule=Host(`${DOMAIN_ONLYOFFICE}`)" # Workaround a bug in OnlyOffice, see the issue tracker: https://github.com/ONLYOFFICE/DocumentServer/issues/2186 - "traefik.http.middlewares.onlyoffice_redirect_http2https_header.headers.contentSecurityPolicy=upgrade-insecure-requests" - "traefik.http.routers.onlyoffice_https.middlewares=onlyoffice_redirect_http2https_header" # Get SSL/TLS certificate from Let's Encrypt by resolving the HTTPS challenge.
The entire file: docker-compose.yml
i forget to mention that i use 7.3 too
I'm encountering this issue as well. Nextcloud app is set to use https, traefik is set to redirect everything to https.
Traefik:
[http.middlewares.noindex.headers.customResponseHeaders]
X-Robots-Tag = "noindex,nofollow,nosnippet,noarchive,notranslate,noimageindex"
frameDeny="true"
[http.routers.onlyoffice]
rule = "Host(`onlyoffice.example.com`)"
entrypoints = "websecure"
middlewares = ["noindex", "onlyoffice"]
service = "onlyoffice"
[http.routers.onlyoffice.tls]
certResolver = "lets-encrypt"
[http.middlewares.onlyoffice.headers.customResponseHeaders]
X-Forwarded-Proto = "https"
accessControlAllowOriginList = "nextcloud.example.com"
[http.services.onlyoffice]
[http.services.onlyoffice.loadBalancer]
[[http.services.onlyoffice.loadBalancer.servers]]
url = "http://192.168.1.5:88"
Nextcloud: