[SOLVED] Rewrites to well-known get redirected to sso portal (Nextcloud social)

[wbk]

Does any of you use Nextcloud Social? I’d love to, but struggle to get it to work. Below are details.

My YunoHost server

Hardware: Other ARM board (orange pi zero)
YunoHost version: 3.5.2
I have access to my server : Through SSH | through the webadmin | serial |
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes
If yes, please explain:
No tweaking, but one way or another, Yunohost thinks it is not yet installed anymore. Everything works, installed are Nextcloud, Wordpress, Opensondage and Roundcube, but now when I access the web-admin, it says “Congratulations, please do the post-install now”. Except that the post-install does not work anymore.

Description of my issue

I am trying to get Nextcloud Social to do federation. I have a couple of Yunohost installations for the family and classmates of my children, so they can exchange photo’s and likes and things without commercial centralized solutions.

I followed the instructions on https://docs.nextcloud.com/server/15/admin_manual/installation/nginx.html?highlight=webfinger#nextcloud-in-the-webroot-of-nginx
, taking account of the fact that nextcloud is in a subdirectory.

The nginx nextcloud.conf for the domain (/etc/nginx/conf.d/domain.tld.d/nextcloud.conf ) has lines for user_webfinger , so I added the line
rewrite ^/.well-known/webfinger /nextcloud/public.php?service=webfinger last;

I also used occ social:reset as is adviced.

None of the other Yunohosts with Nextcloud can find the users on this Nextcloud. The firewall is open, and besides that, the devices are behind the same firewall.

If I open the domain.tld/well-known/webfinger-url by hand, I am forwarded to the Yunohost SSO-portal. Could it be that different rewrite rules fight for priority?

If I keep tail -f on /var/log/nginx/access.log, nothing happens when visiting the well-known webfinger url.

How should I continue troubleshooting? On the nextcloud-social forum I read a few people with some troubles, but they got it resolved without writing details that help me further.

PS, edit: in my confusion I noted version 15 as YNH version. That is the Nextcloud version. YNH is 3.5.2:
yunohost:
repo: stable
version: 3.5.2.2
yunohost-admin:
repo: stable
version: 3.5.2
moulinette:
repo: stable
version: 3.5.2
ssowat:
repo: stable
version: 3.5.2.1

[Lapineige]

Indeed, they are blocked by default. You need to tell Yunohost SSO to open such an URL.
ynh_app_setting set nextcloud skipped_regex "domain.tld/.well-known" <- that will remove the SSO protection for that URL.

(see https://github.com/YunoHost-Apps/nextcloud_ynh/issues/198#issuecomment-490527306 and https://github.com/YunoHost-Apps/wordpress_ynh/issues/61#issuecomment-489569716)

[wbk]

Ah, great, merci & thanks

I am unable to run ynh_app_setting as a command, should that work? Searching the forum and google only returns it as a log entry.

yunohost app setting set nextcloud skipped_regex "domain.tld/.well-known"
brought me further, but fails on the last two arguments:
yunohost: error: unrecognized arguments: skipped_regex domain.tld/.well-known

There are blocks redirected/skipped urls and regexes in /etc/ssowat/conf.json:

“redirected_urls”: {},
“skipped_regex”: [
“online%.osba%.nl/%.well%-known/.",
"^[1]/%.well%-known/acme%-challenge/.$",
"^[2]/%.well%-known/autoconfig/mail/config%-v1%.1%.xml.*$”
],
“skipped_urls”: [
“online.osba.nl/pad/admin”,
“online.osba.nl/date”,
“online.osba.nl/yunohost/admin”,
“online.osba.nl/yunohost/api”
]

I’ll change it here and see what happens after a reload of ssowat or a reboot.

I read your comment about changes being reset after upgrades of Yunohost, I am quite sure that will happen to me when manually changing the ssowat config. Do you expect the changes to be recorded when using a Yunohost-settings-command?

(PS: the editor screen doesn’t show my cursor or text selection while editing this post, excuse me for messy formatting.)

---

1. ^/ ↩︎

2. ^/ ↩︎

[wbk]

On editing and second thought, the lines

"skipped_regex": [
    "online%.osba%.nl/%.well%-known/.*",

seems what I need. I don’t think it was added using yunohost app setting, the file was altered last time a day ago (not manually by me).

Is the %-sign used as an escape for - and . in this case?

[wbk]

Using domain.tld/.well-known/webfinger returns 404.
Using domain.tld/nextcloud/public.php?service=webfinger returns missing resource

I get 404 on the webfinger test page as well.
I don’t know and can not find the syntax to use the nextcloud service:
domain.tld/nextcloud/public.php?service=webfinger with anything behind it (for example, the webfinger?resource=acct-bit that is shown in the webfinger test), returns a 404 in tail -f /var/log/nginx/domain.tld-access.log

The actual redirect is in /etc/nginx/conf.d/domain.tld.d/nextcloud.conf :
rewrite ^/.well-known/webfinger /nextcloud/public.php?service=webfinger last;

I tried adding the same rewrite at the domain level instead of in the nextcloud.conf of nginx and restarting nginx, still 404 when surfing to https://domain.tld/.well-known/webfinger .

Off agoin to browes more forum posts. In case there is a mistake in my rewrite rule, or you know how to test the nextcloud webfinger, please let me know!

[wbk]

I overlooked the nextcloud direct URL in the thread @Lapineige mentioned, if I use that syntax, my account is found

https://online.osba.nl/nextcloud/public.php?service=webfinger&resource=acct%3Awbk%40online.osba.nl

returns

{“subject”:“acct:wbk@online.osba.nl”,“links”:[{“rel”:“self”,“type”:“application/activity+json”,“href”:“http://online.osba.nl/nextcloud/nextcloud/index.php/apps/social/@wbk"},{“rel”:“http://ostatus.org/schema/1.0/subscribe”,“template”:"https://online.osba.nl/nextcloud/index.php/apps/social/ostatus/follow/{uri}”}]}

Great, so far, so good!

The Nginx-access log keeps returning 404 for the .well-known/webfinger construction.

In which config should I put the rewrite rule, and where should it point?

[wbk]

It seems I’m replaying @Lapineige’s steps, as documented in the github-issues he mentioned (YNH_NC_198, YNH_WP_61 and PF_WPAH_31)…

I found out by reading that there is a redirect as well as a rewrite.
I found out by trying the stanza in my /etc/nginx/conf.d/domain.tld.d/nextcloud.conf that it is outside of the nextcloud location, so removed it there and moved it to the /etc/nginx/conf.d/domain.tld.conf at the place in the file where there are already rewrites for .well-known urls (mail autoconfig).

Still didn’t work (404), so read the posts more closely. Wondered about the mention of ‘before 301 something something’ and noticed there is indeed a return 301 something in the config file. No idea if it that one has the effect of not reading any more redirects/rewrites starting with a dot, but moved the webfinger-stanza above it just to be sure.

Restart nginx, try again on the domain.tld/.well-known-url, still 404.

What should I see in the access log of nginx? And which log should I check? I expect access on domain.tld, being redirected to domain.tld/nextcloud, but there is only a log for domain.tld and a ‘slow’ log for nextcloud. Is /var/log/nginx/domain.tld-access.log the right log to check?

Hmmm…The error log on /var/log/nginx/domain.tld-error.log returns :

2019/06/16 16:09:52 [error] 22829#22829: *22 open() “/usr/share/nginx/html/.well-known/webfinger” failed (2: No such file or directory), client: 2600:1900:2000:a5::, server: domain.tld, request: “GET /.well-known/webfinger?resource=acct%3Aname%40domain.tld HTTP/2.0”, host: “domain.tld”

I am quite surprised to see /usr/share as path here, that does not feel good!

I see the reference to that path in the error log from today and from yesterday, before that I have to unzip the log.2.gz. Yesterday or the day before I did an upgrade of YNH.

Please let me know whether nginx should (ever) look at /usr/share/nginx based on web requests. I would expect nginx to find all resources in /var/www!

[wbk]

Haha, I got you, you nasty misconfig!

A shared relief and solution to my problem after getting alarmed at the ‘redirects’ to /usr/share/nginx via a question on stackexchange:

In Nginx if there is no matching location for a uri then it usually defaults to looking in /usr/share/nginx/html/

I had been wondering why there were only redirects and rewrites in the http/default port 80 config for nginx, and none for https/443. Guessed it would run ok, because the redirect would work on port 80 and then go to the right location via port 443, on one way or another. No such thing, it seems.

I copied all redirects and rewrites from the port-80-server in /etc/nginx/conf.d/domain.tld.conf and pasted them in the port-443-server below. In my case they were between the include-blocks and the definition of the log files.

The redirect/rewrite for webfinger is a direct copy of the one shared by Lapineige:

location = /.well-known/webfinger {
  rewrite ^ https://online.osba.nl/nextcloud/public.php?service=webfinger&$1 last; # $1 will use the first parameter (?resource=…)
}

WebFinger now returns something useful. I’m off to see if this is the solution for the other yunohosts and give shout back if my problem is solved.

@Lapineige, thanks for pointing me in the right direction and the breadcrumbs in your threads on Github. To all the others: thanks for reading and good luck with your own servers!