Problem Description
When I try to access both apps from the outside I get 404 Not found
Other app like kiwix or miniflux work. I can access the apps inside the local network. Running diagnostics shows no problems.
Expected Results
Access Synthing Admin and access Calibre from the outside,
Actual results
I get an error with the following message:
Not Found
The requested URL was not found on this server.
Apache/2.4.67 (Debian) Server at mydomain Port 443
No I can’t even get to the login screen of the apps.
If I enter mydomain/syncthing/ or mydomain/calibre/
I get The requested URL was not found on this server.
With the OpenID callback
again accessing it over internal network like 192.168.1.2/calibre or 192.168.1.2/syncthing all works as expected, without aforementioned callback
Question would be why the callback to OpenID Connect when trying to access it over the internet and not the internal network?
I had a similar problem ? a couple of days ago with login to Deluge-web with a internet domain name.
When I use the freedombox.local all works OK with login to deluge-web but fails when I use the internet domain name to login into deluge-web.
Hope the info below explain some of the problem.
I think the login problem as come about since the passkeys setup became a part of freedombox ?
Regards: peter
Reasons Passkeys Fail on.localDomains
HTTPS Requirement (Secure Context): Passkeys require a secure, encrypted connection (HTTPS). Localhost is considered a “secure context” by default, but custom .local domains typically require valid SSL/TLS certificates, which are harder to set up, causing browsers to block WebAuthn API calls.
Registrable Domain Restriction: The passkey (Relying Party ID) must be a registrable domain or a valid public suffix. .local is not a registrable domain suffix, which prevents passkeys from being properly bound to the website.
Thank you, it ain’t a login problem, it is a apache problem as the redirect isn’t working. 404 seems to be a common problem if redirect is aparently not handled as it should be (according to web search), so the solution should lie somewhere in the apache configs for syncthing, calibre with oidc, as login through plinth works flawlessly local and external, traditional login and with passkey.
Will setup new on a different machine to see if it is a general problem or some problems related to an update.
I just had a similar issue and found a workaround. I detailed it in my post. (Is there a way to link it here?) Checkout my post, and see if any of what I managed to find out about OpenID helps you.
I got Calibre working by bypassing the OID auth and exchanging it for a different method - there are a few options for how to achieve that.
I think it’d be useful to know if it’s the same root issue.
Thanks for your exploration on the OpenID problem and detailing a workaround , which as you pointed out isn’t a final solution or solves the underlying problem with mod_auth_openidc in general, as I believe it will cause more problems along the way, as it means messing with internal workings on a f-server by f-server basis.
Went for a new install, still no cigar. Seems to be the problem is deeply rooted in the apache setup. Tried to create a provider file for the domain which brought me to a login screen but not further.
I hope that ppl with a better understanding of the inner workings of apache are getting luckier by solving this mystery.
I don’t use calibre, but for syncthing, I normally first log in to the default page and only then try accessing the syncthing page, for which there is no separate login. What happens if you do that way?
Note that I am not using passkeys (which is perhaps related to this “OpenID”?).
Same behavior as if I directly try to access calibre or syncthing through the internet. Local network as said before works.
If I create a provider file in /var/cache/apache2/mod_auth_openidc/metadata for the domain I at least get on to the login page can login and but then are stuck with # Bad Request
Your browser sent a request that this server could not understand.
Also in the /var/cache/apache2/mod_auth_openidc/metadata directory there are random provider and client files (so far 50) created.They have the form of %5B2003%3Ad3%3A370d%3Ae900%3A13a2%3A736d%3A627d%3A8b2a%5D%2Ffreedombox%2Fo.client %5B2003%3Ad3%3A370d%3Ae900%3A13a2%3A736d%3A627d%3A8b2a%5D%2Ffreedombox%2Fo.provider
, which as you pointed out isn’t a final solution or solves the underlying problem with mod_auth_openidc in general, as I believe it will cause more problems along the way, as it means messing with internal workings on a f-server by f-server basis.