[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.

[quenenni]

Hello,

I'm back after having tested Nextcloud v28.0.6.

Unfortunately, if something changed, the problem still remains.
Now I can disable an app, but I still can't enable it via the web interface.

When trying to enable an app, here is what I see in the browser console log:

• POST https://cloud.xxxx.be/settings/apps/enable

Status 200
Version HTTP/2
Transferred 870 B (34 B size)
Referrer Policyno-referrer
Request PriorityHighest
DNS ResolutionSystem

Request headers: 
{"appIds":["admin_audit"],"groups":[]}

Response:
{"data":{"update_required":false}}

The response here:

HTTP/2 200 
server: nginx
date: Tue, 04 Jun 2024 17:12:08 GMT
content-type: application/json; charset=utf-8
content-length: 52
expires: Thu, 19 Nov 1981 08:52:00 GMT
pragma: no-cache
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-xss-protection: 1; mode=block
x-request-id: xxxxxx
cache-control: no-cache, no-store, must-revalidate
content-security-policy: default-src 'none';base-uri 'none';manifest-src 'self';frame-ancestors 'none'
feature-policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none'
x-robots-tag: noindex, nofollow
content-encoding: gzip
strict-transport-security: max-age=15768000; includeSubDomains; preload;
X-Firefox-Spdy: h2

This first request is good and the app is, I think, correctly, but just temporally, enabled.

In nginx log:

1.2.3.4 - - [04/Jun/2024:19:12:08 +0200] "POST /settings/apps/enable HTTP/2.0" 200 52 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0" "-" "cloud.xxxx.be"

• The next request, as before, return a 301 and get the wrong port (4431 instead of 443):

GET /apps/files HTTP/2
Host: cloud.xxxx.be
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Accept: application/json, text/plain, */*
Accept-Language: fr-BE,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
requesttoken: yyyyyy
DNT: 1
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Connection: keep-alive
Cookie: __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; nc_username=quenenni; nc_token=zzzzz; nc_session_id=yyyyyy; oc_sessionPassphrase=xxxxxx
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

The response here :

HTTP/2 301 
server: nginx
date: Tue, 04 Jun 2024 17:12:08 GMT
content-type: text/html
content-length: 162
location: https://cloud.xxxxx.be:4431/apps/files/
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
X-Firefox-Spdy: h2

I still see that the request doesn't include the trailing slash (/apps/files instead of /apps/files/) as it was discussed for this problem.

In Nginx logs:

1.2.3.4 - - [04/Jun/2024:19:12:08 +0200] "GET /apps/files HTTP/2.0" 301 162 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0" "-" "cloud.xxxxx.be"

From this, the browser console shows this error (the same as before):

Content-Security-Policy: The page’s settings blocked the loading of a resource at https://cloud.xxxx.be:4431/apps/files/ (“connect-src”).

• As this error occurred, the next request disables the app.
  This request works correctly (I can disable the apps).

POST /settings/apps/disable HTTP/2
Host: cloud.xxxxxx.be
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Accept: application/json, text/plain, */*
Accept-Language: fr-BE,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Content-Length: 26
X-Requested-With: XMLHttpRequest
requesttoken: zzzzzzzzz
Origin: https://cloud.xxxxx.be
DNT: 1
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Connection: keep-alive
Cookie: __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; nc_username=quenenni; nc_token=wwwww; nc_session_id=zzzzzz; oc_sessionPassphrase=yyyyyyy; 5120d64d8f56b=xxxxxxx
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

The response:

HTTP/2 200 
server: nginx
date: Tue, 04 Jun 2024 17:12:08 GMT
content-type: application/json; charset=utf-8
content-length: 22
expires: Thu, 19 Nov 1981 08:52:00 GMT
pragma: no-cache
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-xss-protection: 1; mode=block
x-request-id: xxxxxx
cache-control: no-cache, no-store, must-revalidate
content-security-policy: default-src 'none';base-uri 'none';manifest-src 'self';frame-ancestors 'none'
feature-policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none'
x-robots-tag: noindex, nofollow
content-encoding: gzip
strict-transport-security: max-age=15768000; includeSubDomains; preload;
X-Firefox-Spdy: h2

In Nginx logs:

1.2.3.4 - - [04/Jun/2024:19:12:08 +0200] "POST /settings/apps/disable HTTP/2.0" 200 22 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0" "-" "cloud.xxxxx.be"

Why the trailing slash is not present when requesting /apps/files ?
I understood the proposed fix for this problem (#44685) was to add the slash?