Sorry havn’t been back. I eventually just gave up on the nodeinfo and web finger options, wiped my server and moved back to NC20.09.
I’m not using the social app. Couldn’t get it to install even manually. Even moving back to NC 20 the social app still wouldn’t install. At this point I’m just going to wait until futher updates from 21 are available and the social app install is fixed and then give 21 a try again.
This time around I have installed NC20 as a VM on an ESXi host server so that the next time I’m ready to try and update to 21 I can snap shot first and move back to 20 without the full re-install.
Hi,
thanks you for caring.
Did anything happen on this issue?
I receive the same attention grabbing orange code. I read as much as i could but did not succeed to obtain a green light.
Is there any further development in the making?
Thank you
For anybody else beating their heads over this issue:
The issue is caused by that the Nextcloud .well-known checks do not account for relative paths. Yes, a relative path is valid, and will work perfectly well for CardDAV, CalDAV, … The check on the Administration Overview page thinks otherwise, though.
To remove the errors, you can replace the relative paths with absolute paths in your configuration. Look at the following two nginx configuration snippets, which should be easy to adopt to other web server software.
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The following 6 rules are borrowed from `.htaccess`
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
}
Make all the redirects absolute URLs (inspired by this page):
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The following 6 rules are borrowed from `.htaccess`
location = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav/; }
location = /.well-known/caldav { return 301 $scheme://$host/remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 $scheme://$host/index.php$uri; }
try_files $uri $uri/ =404;
}
If you use a reverse proxy for TLS offloading, replace $scheme with https!
The result of this is that the “Your web server is not set up correctly to resolve(…)” warnings will be gone.
Consider this a workaround, not a solution. Obviously, the check should be changed so that it also supports relative paths.
Thanks heaps. Alas I tried putting an absolute path there and it still reports the error.
Take note though:
It reports no error for carddav and caldav only for webfinger and nodeinfo
It points to a documentation link, but neither is there documented.
I have them directing to /public.php?service=webfinger and /public.php?service=nodeinfo respectively, but I can’t find public.php nore those two services documented anywhere and if I surf to them I get no response (just a blank page).
The problem, aside from the error message, that remains pertinent is where is this documented, what is it, why does no-one know what it’s about, why is it checked for, what results should webfinger and nodeinfo produce, and why? etc. etc. Questions, questions, questions… I mean I can’t even get any response out of public.php and don’t know its API or what it’s for and would love some documentation.
Nextcloud documentation is often disappointing. This should be fixed as well.
Nowhere in the documentation I linked does it state that you should do anything with public.php. See 1.
Based on a known good configuration, /.well-known/webfinger (which redirects to /index.php/.well-known/webfinger due to the last catchall nginx redirect rule in my snippet) reponds: {"message":"webfinger not supported"}. This is the correct response for me, since I do not have webfinger enabled. The same is true for nodeinfo: {"message":"nodeinfo not supported"}.
Since you note public.php (which is irrelevant, and probably comes from outdated documentation/configuration examples), your configuration seems flawed. Please try my nginx snippet.
I don’t use nginx ;-). I know it’s the little shining star of web servers out there but for better or for worse because my OpenWRT routers all come with lighttpd bundled and lighttpd is as performant as nginx on fronts (both of which leave apache dead in the water) and unlike nginx is FOSS (so community dependence not vendor dependence is the price which is a matter of taste) I have lighttpd skills not nginx skills.
I can share the config but alas lighttpd is a little niche club methinks and not many use it (as exemplified by endless nginx snippets).
Which is all why I’m not a fan of sharing web server config snippets alone (sure they help for plug and play people) but wish to see them with an explanation of the intended effect (which I can implement in lightttpd).
But for the record here is a lighttpd config snippet:
But yes, I was experimenting with this because of 1337omega’s claim to success here:
I haven’t implemented webfinger or nodeinfo explicitly either, in fact know nothing about them, only found these error messages on the settings overview after a Nextcloud upgrade. Wishing indeed, to know why Nextcloud reports:
With no supporting documentation that explains what webfinger and nodeinfo are , why it wants them and how we can provide them if necessary to suppress the message if it’s not.
Converting my nginx snippets to lighttpd snippets is trivial. All you need are the correct absolute destination redirect URLs. For example (requiring lighttpd 1.4.50+):
Again, if you offload TLS, you should replace ${url.scheme} with https. If you use an older lighttpd version, see this for inspiration.
You will not find much documentation or support only Apache is supported and NGINX is tolerated. I do not care about webfinger or nodeinfo. They are apparently disabled by default/on my server anyway, and all I am interested in is getting rid of the errors (which I did, and so can you).
Yes, likewise I don’t care one jot about webfinger and nodeinfo, I just want to understand why Nextcloud complains about them, and how to get rid of the complaint of if they happen to be needed (why else complain about it) to enable them.
I’m not familiar with nginx syntax so not sure how to read $uri. And while I am quite familiar with lighttpd (managing it for some years now on numerous servers) I remain frustrated by it’s lack of documentation on the ${} parameters available in substitutions.
Oddly this snippet works. It gets rid of the errors reported but implements nothing (i.e. redirects to URLs that return 404). I tried earlier with redirects hardcoding the target URL, eg:
And don’t recall finding joy. There are two possible reasons for this (I’ve not diagnosed yet):
I didn’t actually test the Nextcloud page. Because I did numerous cycles of testing just testing the URLs to see what I got and interpreted a 404 as fail. But today you have provided me with empirical evidence that a redirect to a URL that returns 404 works nonetheless in ridding us of this error message.
It could also be that this redirect does not present the qsa (untested) and that the test that Nextcloud performs is with a query string. This dubious and I suspect reason 1. is at play, mainly because it’s a 404 one way or the other.
I remain further frustrated that no-one seems to know or be willing to report, WTF this is all about? Why does Nextcloud suddenly want webfinger and nodeinfo? And why is it content simply to with a 404 returned?
With the slight possibility existing that the tester provides a query string that turns this into a non 404 result I checked the lighttpd logs will reloading that page and nope:
It seems completely content to receive a 404 or maybe it’s the 301 it wants? Aaargh the ridiculous mystery. You’d think at Nextcloud central given the number of admins scratching their heads about these mysterious new messages after an upgrade, there’d be some priority to fixing it or documenting what is up.
As a Nextcloud user without a support contract, I search for information I need myself. That is how I learned about this topic, and how I came up with a solution. This keeps me from becoming frustrated due to a product I use freely, and for which nobody owes me anything.
Searching also brought me to a GitHub discussion, that explains that nodeinfo and webfinger are used or will be used by Nextcloud Social. Nextcloud Social is optional, but whether a Nextcloud instance supports it or not can be made publicly ‘well known’ using the correct options.
My tip:
Instead of venting on a forum, learn to search for yourself. All information is out there, as I have shown multiple times. If you do not like Nextcloud, you are welcome to contribute to it so that one day you might like it, and you are welcome to not use it at all.
Same .well-known problem in my setup. Using apache httpd, I got rid of those annoying messages by redirecting matching URLS to a location returning a 2XX status and adding an header. I prefer to configure things server side, avoiding .htaccess manipulation, so this is my suggestion:
maybe this should be added to the documentation page that is mentioned in the error message?
NB: nextcloud is installed in the directory /owncloud/ on my system. Remove (or replace) /owncloud if you have nextcloud in the main directory (or in another subdirectory).
1.) The browser caches redirects. So when you test post changes to proxy server, you have to clear cache or go into incognito / private browsing mode.
2.) index.php/.well-known/webfinger returns nothing (404) when manually entering the URL in the browser. So even if you get the nginix / apache config to correctly redirect, it will only work if the index.php knows how to manage the URI. In this case I am not sure index.php/.well-known/webfinger is the correct redirect path.
3.) Its unclear to my why the dashboard tool even checks for a .well-know/webfinger unless its just a general check based on this specification ForgeRock Access Management 7.0.2 > OpenID Connect 1.0 Guide > /.well-known/webfinger
4.) nodeinfo is in the same boat as above. Why check, redirect, etc…
My Config… I just redirect it to the index.php (unit I know the proper place) and it still fails the Overview security and setup warnings…
This worked for me, and only commenting error page config of 404 will be OK because by doing this the /index.php/.well-known/webfinger could return a JSON but not 404.
I tried a lot but could not get it right until I checked the page in an incognito window in my Chrome-browser. Et voila no errror. I cleared the browsers memory cache (ctrl+F5) and now I had no errors also in ordinary browser window.
If you encounter just Webfinger to be unknown/not set properly, it might be that you just installed Social beta 0.6 which has an issue there – took me a while searching for the general issue with .well-known until I noticed "Exception": "OCA\\**Social**\\… in the log:
