[Bug]: using proxy, wrong cloud port used when trying to enable / disable an app

[quenenni]

⚠️ 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

I wrote the bug report #44685 not long ago.
(My setup is still exactly the same as reported there, so I'll just add the new infos in this one)

That report showed that there was a problem with a missing trailing slash at the end of apps/files when testing stuff.

It seems, for me at least, there was 2 problems and if I can't say the missing trailing slash fixed something for me, the major problem is that the test to /apps/files/ get the wrong server port.

As @joshtrichards pointed out in this comment (#44685 (comment)), the test was trying to use the port 4431 from my nginx instead of the normal https port 443.

I updated my cloud from v28.0.4 to v28.0.5.
I tried all I could do to understand that problem, but nothing is working, it always try the port 4431.

From my previous report, I added these settings in my config.php:

  'overwrite.cli.url' => 'https://cloud.xxxx.be:443/',  -> I tried with and without the ':443'
  'overwriteprotocol' => 'https',
  'overwritehost' => 'cloud.xxxx.be:443',

In my Nginx vhost, I tried the option "fastcgi_param SERVER_PORT 443;" on several lines.
I modified my /etc/nginx/fastcgi_params forcing the value 443 for the SERVER_PORT option.

I searched the haproxy documentation to see if I could use something like the "X-Forwarded-Port" option, but as I'm using TCP mode, from what I understand, I can't use it here (and I shouldn't need it here as far as I understand the TCP mode).

I searched the Nextcloud code to try to understand why it finds that port instead of the 443, but no luck (not easy to understand all the code, there are lots of stuffs).

I cheked the browser console on every cloud page (apps, settings, users) and for all requests I could see in the browser console, it always has the correct port.

The only one not having the right port is when I'm trying to enable / disable an app.

So how this test get the wrong port?

Steps to reproduce

.

Expected behavior

.

Installation method

Community Manual installation with Archive

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Nginx

Database engine version

MariaDB

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

Upgraded to a MAJOR version (ex. 22 to 23)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

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

No response

[kesselb]

'overwritehost' => 'cloud.xxxx.be:443',

overwritehost should not contain a port.

[quenenni]

@kesselb Thanks for the help.

I tried with and without the ':443', but no difference.

[kesselb]

overwritehost should not contain a port.

I was wrong, overwritehost may contain a port.
In your case, it should contain 443 because nginx is using 4431.

The patch for the trailing slash problem will be released with 28.0.6.
Please let us know if the problem persists then.

[quenenni]

Maybe the trailing slash was a problem in my setup, but I don't think the patch will fix the fact that NC get the wrong port when building the url when trying to enable or disable an app..

And with all my sweat & will, I don't have a clue on how it does it..

Content-Security-Policy : Les paramètres de la page ont empêché le chargement d’une ressource à 
https://cloud.yyyyy.be:4431/apps/files/ (« connect-src »).

But I'll wait to have update to v28.0.6 to be sure and will come back here after.

Thanks for the tips and time @kesselb

[kesselb]

1.2.3.4 - - [05/Apr/2024:15:58:51 +0200] "POST /settings/apps/enable HTTP/2.0" 200 52 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0" "-" "cloud.yyyyy.be"

This request looks okay. When you enable the app, see the error message and then reload the apps page, is the app enabled then?

the fact that NC get the wrong port when building the url when trying to enable or disable an app..

server/apps/settings/src/store/apps.js

Lines 180 to 190 in 278aafd

	return api.post(generateUrl('settings/apps/enable'), { appIds: apps, groups })
	.then((response) => {
	context.commit('stopLoading', apps)
	context.commit('stopLoading', 'install')
	apps.forEach(_appId => {
	context.commit('enableApp', { appId: _appId, groups })
	})
	// check for server health
	return api.get(generateUrl('apps/files/'))
	.then(() => {

The same code is used to generate the URL for app enable and server health check, the latter is responsible for the error message shown to you.

Idea 1:
Open the browser's network tool, check preserve logs, try to enable an app and check the xhr requests.

Idea 2:
You can use the browser's developer tools to search for "settings/apps/enable" in the JavaScript sources, set a breakpoint for the two places and check if the url really contains the port.