/.well-known/webfinger

If Nextcloud is sitting behind a proxy you need to set overwriteprotocol in config.php like:
'overwriteprotocol' => 'https',

I do have that, but still the redirect locations are coming without them.

Hmm… after thinking a bit longer about it, I think this is a webserver issue. Because the redirects to the /.well-known URLs are handled by .htaccess files (if you are using apache) or by the nginx configuration (if you are using nginx).
With nginx configuration I could help. Which webserver are you using?

Good point, that’s it. I’m using Apache and will sort that one out and report back about how I got it resolved.

Here is how it works in .htaccess:

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT}  DavClnt
  RewriteRule ^$         https://%{SERVER_NAME}/remote.php/webdav/          [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta https://%{SERVER_NAME}/public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json https://%{SERVER_NAME}/public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/webfinger https://%{SERVER_NAME}/public.php?service=webfinger [QSA,L]
  RewriteRule ^\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) https://%{SERVER_NAME}/remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

Probably not the most elegant solution but it’s working.

1 Like

Hello jurgenhaas and Bernie_O,

i tried the same on my .htaccess and now the error-messages in admin-panel are gone, redirection works; thank you!

But i still can’t follow other fediverse-instances and get a missing resource on blank screen (as above in 3 and 8) for app/social.

I will follow the issues on https://github.com/nextcloud/social/issues/ as it now seems to be an issue of app/social.

Thank you all. (Do i have to close this issue, an if so: how?)

did some test using a subfolder for the installation of nextcloud, can confirm it works.

I just had to put generate a .htaccess file at the root of the webfolder:

RewriteEngine on
RewriteRule ^\.well-known/webfinger https://test.pontapreta.net/nextcloud/public.php?service=webfinger [QSA,L]

It is not the cleanest solution as it does some redirection and this should be hidden with some proxy stuff, but it works™

For those using nginx try this in /sites-available/…
location = /.well-known/webfinger {
rewrite ^/.well-known/webfinger /public.php?service=webfinger last;
}

1 Like

Hello all,

I am getting this error and I’ve tried the following settings below but still failing. Could it be because I’m using self-signed certificate?

RewriteRule ^.well-known/webfinger /nextcloud/public.php?service=webfinger [QSA,L]
RewriteRule ^.well-known/webfinger https://${SERVER_NAME}/public.php?service=webfinger [QSA,L]

here’s part of my httpd.conf setting:
<Directory /var/www/nextcloud/>
Options +FollowSymlinks
AllowOverride All
Satisfy Any
Require all granted

Dav off

SetEnv HOME /var/www/nextcloud
SetEnv HTTP_HOME /var/www/nextcloud

that is also my problem.

carddav and caldav work fine

this is my nginx config:

  location = /.well-known/webfinger {
      rewrite ^/.well-known/webfinger /public.php?service=webfinger last;
  }
  location = /.well-known/carddav {
      return 301 /remote.php/dav;
  }
  location = /.well-known/caldav {
      return 301 /remote.php/dav;
  }
  location / {
      include                     snippets.d/proxy_generic;
      proxy_pass                  http://10.77.77.106:8082;
  }

I have also this problem :
Using Nginx with no problems on Cardav and Caldav :

 location = /.well-known/webfinger {
      rewrite ^/.well-known/webfinger /public.php?service=webfinger last;
  }

hope someone can give us clues

I have a similar problem as well
But when I put that into .htaccess in my cloud (nextcloud) subfolder it broke my nextcloud so I had to do a reinstall of it
Now I’m back at the start also when I click on the menu it doesn’t show anything eg user, settings

I’m running nextcloud 19.0.1 on ubuntu 20.04 with apache and php 7.4
Some photos


There must be someone that can help us with this?
I am also running NC on Ubuntu 20 with PHP7.4 and nginx. I have added the rewrite well-known to nextcloud.conf for nginx, but does not seem to work. When I navigate to https://my-domain.com/.well-known/webfinger?resource=acct:mark@my.domain.com I actually get 403 forbidden warning.

I would really love to start using social, so I am hoping someone can help me with this.

Hi, Also on ubuntu 20.04 with apache and php7.4 and I’m getting the same behaviour.

/nextcloud/index.php/settings/admin/overview sometimes tells me there are three .well-known links missing, othertimes it only tells me webfinger is missing.

Adding https://mydomain.com/ to the rewrites broke it more than fixed it. At least without it I get the pretty Internal Server Error. I get the same Internal Server Error when requesting the raw /webfinger and when I append my user account name.

Log is giving me:
Exception: The requested uri(/.well-known/webfinger) cannot be processed by the script ‘/nextcloud/public.php’)

  1. /var/www/nextcloud/lib/private/AppFramework/Http/Request.php - line 808:OC\AppFramework\Http\Request->getRawPathInfo()
  2. /var/www/nextcloud/public.php - line 47:OC\AppFramework\Http\Request->getPathInfo()

Fixing “@user@localhost” didn’t help.

The app is simply not yet ready for production.

People releasing alpha software usually are eager to have bug reports.

1 Like

even after uninstalling it, still show this error. sillyness

I’m on a webhost installed on mydomain.com/nc and see the same after installing Social.
What I found:

The reason might be same as here - the managed server doesn’t allow my .htaccess to play around with exactly that folder.

So the proposed patches in .htaccess take no effect in my case.