[Bug]: SetupChecks for mjs does not work behind proxy with overwritewebroot

[brad2014]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Using the configuration suggested in https://github.com/nextcloud/docker/blob/master/.examples/docker-compose/with-nginx-proxy/mariadb, with the addition of an overwritewebroot (so that my nextcloud appears at https://redacted.com/nextcloud) the SetupChecks for mjs (new in Nextcloud 7 Hub 28.0.2) configuration fails as in #42989 even with the fix provided by #42999.

Debug log entry (redacting server name):

cURL error 28: Failed to connect to redacted.com port 443 after 10002 ms: Timeout was reached (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://redacted.com/nextcloud/apps/settings/js/esm-test.mjs

Steps to reproduce

1. Deploy the above setup from nextcloud/docker
2. In the app environment, set:

NEXTCLOUD_TRUSTED_DOMAINS=redacted.com
NEXTCLOUD_TRUSTED_PROXIES=172.16.0.0/12
OVERWRITEWEBROOT=/nextcloud

4. In the web environment set:

VIRTUAL_HOST=redacted.com
VIRTUAL_PATH=/nextcloud/
VIRTUAL_DEST=/

Expected behavior

The server is properly configured, so I'd expect the MJS warning to not appear.

Installation method

Community Docker image

Nextcloud Server version

28

Operating system

None

PHP engine version

None

Web server

Nginx

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

The new warning message, while well-intentioned, is guaranteed to be fragile, since it attempts to determine from inside the php app host what the content-type that the end-user browser sees, and in the face of "client browser to proxy to web server to fpm" transformations (which is the docker configuration in the example) and server configuration flexibility (e.g. overwritereboot), that is simply impossible to guarantee if executed from inside the php app.

Another, perhaps more robust, approach could call /settings/ajax/checksetup with a block of data that assesses what the client sees (for example, {"client-observed-mjs-content-type":"application/javascript", etc.}, which the checksetup script could reflect back as warnings where the client-side observation(s) are incorrect.

[brad2014]

To be clear, the only bug is that (a) checksetup takes a long time because it has to wait for the curl to redacted.com (not accessible on the internal network) to timeout, and (b) after the timeout, the app issues a warning.

The manual check in my case does pass (so the warning can be ignored):

# curl -I https://redacted.com/nextcloud/apps/settings/js/esm-test.mjs
HTTP/2 200 
server: nginx/1.25.3
date: Thu, 08 Feb 2024 13:47:51 GMT
content-type: text/javascript
content-length: 109
last-modified: Thu, 08 Feb 2024 10:20:00 GMT
etag: "65c4aad0-6d"
cache-control: public, max-age=15778463,
accept-ranges: bytes
strict-transport-security: max-age=31536000

[brad2014]

This may be my configuration error (not a bug). It seem that from the php app container, curl can connect to hosts on the internet, but cannot connect to the proxy server.

[jameskimmel]

Probably does not help you much, but I have the same issue with an apache2 Nextcloud instance behind a NGINX proxy.
Currently investigating it.

[brad2014]

OK - my app container can curl off remote hosts, but not off the proxy container. I'm going to chalk this up to a configuration problem in docker.

If I set the ip of the proxy host in /etc/hosts on the php app container, it does work, the app is happy, and the warning message is gone:

# docker compose exec app /bin/sh
/var/www/html # ip route | grep default
default via 172.30.0.1 dev eth0 
/var/www/html # echo "172.30.0.1 redacted.com" >> /etc/hosts

That's not a very robust workaround, though, since the gateway net number changes on every boot. Is there a better way to allow the php app container to curl to the proxy container?

[jameskimmel]

Sorry if I am misunderstanding your problem, maybe I am confusing it with mine. And I also don't know anything about Docker, but to me it seems like this is a DNS problem right?
The app container tries to connect to redactec.com, and gets the WAN IP from the DNS.
I had this problem for multiple other apps before and solved it by creating an unbound override rule.
My local DNS now answers all redacted.com requests with the local IPv4 of the proxy (172.30.0.1) instead of the public WAN IP (136.238.12.3).

[brad2014]

Ugh. I figured it out (probably of use to no one, but I'll leave it here for the google foo). My redacted.com host IP address actually a wireguard ip address (it is internal to a VPN), and wireguard's default networking setup drops non-local packets destined to the wireguard ip address if they don't come in through the wireguard gateway. So the docker container sends a packet to the vpn IP address on the host, and it comes through the docker0 bridge, and gets dropped as non-local.

The only thing that is broken is when the nextcloud app tries to fetch from itself using the proxy trusted_domain, and the only place I've seen that happen is in the SetupCheck that validates mjs content-type.

Closing this.