Can't sign in to a Solid app

[Vinnl]

I just installed the Nextcloud plugin, and while the admin UI works, actually trying to sign in to one of the listed Solid apps, or into Penny, doesn't seem to work. I'm supposed to just pass in the root of the Nextcloud instance as the IDP, correct?

I don't think it matters, but for completeness I should mention that this Nextcloud instance is running in my local network, not on the public internet. But I'm signing in to client-side apps, so AFAIK this should be fine.

[ylebre]

Running it on a local instance should not be an issue for Penny. Could you take a peek what is happening in the request headers when calling openid-configuration?
Are there any errors in the errorlog happening?

[Vinnl]

Request headers:

GET /.well-known/openid-configuration HTTP/2
Host: pi
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0
Accept: */*
Accept-Language: en-GB,en-US;q=0.8,en;q=0.5,nl;q=0.3
Accept-Encoding: gzip, deflate, br, zstd
Referer: https://penny.vincenttunru.com/
Origin: https://penny.vincenttunru.com
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Priority: u=0
Pragma: no-cache
Cache-Control: no-cache

Response headers:

HTTP/2 301 
server: nginx
date: Fri, 14 Feb 2025 20:52:27 GMT
content-type: text/html
content-length: 162
location: /index.php/.well-known/openid-configuration
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-robots-tag: noindex, nofollow
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: sameorigin
referrer-policy: no-referrer
strict-transport-security: max-age=15552000; includeSubDomains
X-Firefox-Spdy: h2

The logs show the same message as in the screenshot:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://pi/.well-known/openid-configuration. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 301.

And indeed, I don't see any ACAO headers above, but I don't see any clues as to why they should be missing.

[ylebre]

Hm, a 301 redirect is not what I would expect to see there - I would expect it to serve the well-known directly from the first URL. That feels like a nextcloud / webserver configuration issue to me.

My setup has this set of rewrites in the .htaccess in the root of the nextcloud installation:

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

Which looks to redirect any .well-known requests directly to the index.php. Maybe the nginx configuration needs something similar?

[Vinnl]

Hmm, I'm running Nextcloud from the NixOS package, which indeed sets up a 301 redirect from well-known URLs other than carddav, caldav, acme-challenge and pki-validation to index.php. However, that does seem to follow the recommended configuration for Nginx, so if it's feasible, maybe it's best to support that as well?

In the meantime I can try to see if there's a way I can make it just be an alias instead of a redirect rule.

[ylebre]

I think it should also be sufficient to add a cors header to the 301 redirect? So in before the 301 to index.php rule, adding an add_header ACAO rule would probably suffice. Bonus points for restricting it to only .well-known/openid-configuration and .well-known/solid.