-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: using proxy, wrong cloud port used when trying to enable / disable an app #45378
Comments
overwritehost should not contain a port. |
@kesselb Thanks for the help. I tried with and without the ':443', but no difference. |
I was wrong, The patch for the trailing slash problem will be released with 28.0.6. |
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..
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 |
This request looks okay. When you enable the app, see the error message and then reload the apps page, is the app enabled then?
server/apps/settings/src/store/apps.js Lines 180 to 190 in 278aafd
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: Idea 2: |
Hello, I'm back after having tested Nextcloud v28.0.6. Unfortunately, if something changed, the problem still remains. When trying to enable an app, here is what I see in the browser console log:
The response here:
This first request is good and the app is, I think, correctly, but just temporally, enabled. In nginx log:
The response here :
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:
From this, the browser console shows this error (the same as before):
The response:
In Nginx logs:
Why the trailing slash is not present when requesting /apps/files ? |
Mind to retest with 28.0.7? |
Hello, Thanks for fix. Same as before. I can disable an app, but still can't enable an app.
Nothing special in Nginx and Nextcloud logs. |
If I'm updating the cloud to v29, will it be different or the same? Will it be easier for you to debug with a v29 cloud? |
I tested on a new v29 (v29.0.3) cloud and it works for both enabling and disabling applications. I'm going to try to update our main cloud to v29 and see if it's also working. |
Thanks for the update 👍 The patch missed the merge window for 28.0.7: #45770 |
Well, that explains this :) I tested an upgrade for a cloud in production from previous version to v29 where the problem was present in v28 and everything seems to work well. I suppose I'll pass quickly v28 for all our clouds to go to v29. Big thanks for all the help. |
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:
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?
Configuration report
No response
List of activated Apps
No response
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: