-
-
Notifications
You must be signed in to change notification settings - Fork 502
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
DietPi-LetsEncrypt | Adjust ownCloud/Nextcloud CLI URL when HTTPS redirect is enabled #4353
Comments
did you checked on the nextcloud forum as I suggested on the forum? |
Many thanks for your report. The HSTS warning is expected as long as you didn't enable it intentionally via e.g. The webfinger and nodeinfo warnings should actually be solved. I'll have a look tomorrow. |
@Joulinar, i tried to understand the nextcloud documentation for nginx (thats not the forum), but i get mixed up since dietpi uses not the same way how to configure nginx - sites enabled. I do not understand the syntax and do not have knowledge and experience to figure out and just tried copy and paste in hopefully the correct file. |
Just in case: "uncomment" means to remove the leading hash
So it changes from a config code comment into an actual directive. While the config has it commented by default, to work with plain HTTP setups or with HTTPS but no HSTS, we uncomment it when running |
@MichaIng, when using the dps_114 original complete code i was able to uncomment this line, but still have the webfinger/nodeinfo issue. thanks for explanation. (offtopic: i just renewed letsencrypt certificate, but i had to open port 80 on router which is usually not forwarded, so no automatic renewals possible?) |
|
Yes. With HTTPS redirect enabled there is also no reason to keep port 80 closed. Read the statement of Let's Encrypt about this: https://letsencrypt.org/docs/allow-port-80/ |
Strange, I cannot replicate the issue. Installed Nextcloud + Nginx on a clean DietPi Buster image and the redirects solve the warnings as expected. If it doesn't work in your case, please provide your Nginx config via |
Hello MichaIng, |
Strange, tested another time and it really works here OOTB. Also the method matches 100% the one from Nextcloud docs (where I just recently helped updating). Can you please run the following from the command line:
|
when i run the the command i get this result: |
So the redirect is done as intended. Of course the final access fails, as it you cannot authenticate via curl, only the first redirect is relevant. Strange that the Nextcloud admin panel shows it otherwise. Did you try to restart the webserver and PHP and clear the browser cache as well to rule that all out?
And |
i always restarted nginx, (also restarted dietpi), now i also restarted php7.3-fpm, cleared cache in firefox and chrome, reloaded page, still get the warning. |
Is this still an issue? Whatever I do, I cannot replicate it, so it is neither a general bug in Nextcloud, not on our config. All configs and tests (aside of the admin panel) look correct and have exactly expected results. So I'm puzzled. |
I updated to 21.0.2 stable about 2 weeks ago, nextcloud still displays webfinger / nodeinfo error message. Since i am using Nextcloud only private for me and my family, and the installation and connected devices work well, its no problem for me. I do not have any disadvantages when the message is displayed. If you were interested to solve, i could give you an account/ssh, but i am fine when its not solved. |
Looping through old open issues. Another attempt: In 'overwrite.cli.url' => 'http://localhost/nextcloud', right? I never though about that a HTTPS redirect means this is redirected to I'll add this to |
dietpi 7.5.2 & nextcloud 22.1.1 The warning in nextcloud is still there. I attached my current
and
(in windows a system32/config/host has to be configured to redirect the domain to localhost, where is this done here?) |
Did you restart PHP to assure possible caches are cleared? systemctl restart php7.3-fpm The config is as expected:
|
Okay I tested it the other way round, and indeed Another thing you could try is to update the `.htaccess to rule out any possibly old conflicting rewrite: ncc maintenance:update:htaccess |
Thanks for the detailed explanation. I updated the `.htaccess, without success. Next big aim for me it's to upgrade to 64 bit to get OpenOffice in nextcloud (when wireguard works) and import all certificates. |
Okay, let me keep it open to have the |
+ DietPi-LetsEncrypt | If webserver access via plain HTTP is not possible anymore (redirect or HSTS enabled), replace ownCloud/Nextcloud CLI URL with the primary domain HTTPS URL, so that cron jobs and occ/ncc commands can correctly access the ownCloud/Nextcloud instance via webserver. This may be required on other cases, but those are the first known ones: #4353
Done: 9909a4f I know it was not the solution for your actual issue, but it is a solution for other potential issues, e.g. in combination with apps who do check via access through the webserver. I'm still wondering how the admin panel redirect check can succeed when the invalid localhost URL is given while a HTTPS redirect or HSTS is present. There shouldn't be any other reliable way than accessing Nextcloud externally through the webserver. I'll check the related code at Nextcloud by times. |
sorry i cannot code, only report...
my nextcloud 21.0.1 installation on dietpi 7.1.2 says its not well configured because of missing webnode and nodeinfo configuration. (nginx)
i added /etc/nginx/sites-dietpi/dietpi-nextcloud.conf in line 4-5 with
location ~ ^/.well-known/(?:webfinger|nodeinfo) {
return 301 /nextcloud/index.php$request_uri;
}
as you write in /.conf/dps_114/nginx.nextcloud.conf
after restarting service nginx i still have same error message in nextcloud
(in forum https://dietpi.com/phpbb/viewtopic.php?p=33770#p33770)
when i copy the complete code from dps_114 in a new nginx.nextcloud.conf i get a third safety hint:
Strict-Transport-Security" is not min. 15552000 Seconds, activation of hsts is recommended.
Do you have any advice?
Regards, droogi
The text was updated successfully, but these errors were encountered: