Cannot login anymore after switch to OIDC in latest update

[nebulon]

With OpenID the apps backends have to be able to reach the OpenID provider, which on Cloudron is running on the dashboard domain. So any app with OpenID will fail if your system can't call the Cloudron APIs from within its app containers.

For a start, can you resolve the dashboard domain from the webterminal of an app?
host my.domain.com

If this is a system hosted behind a router (like a homesetup) make sure hairpinning is supported.

[buesching]

@nebulon It returns the public IP address. The system is behind a reverse proxy. The webinterface is reachable over the internet. Should I be able to open https://my.<your cloudron domain>/.well-known/openid-configuration from a browser?
I only get a server error.

[nebulon]

Yes that should be publicly reachable. Can you check the server side logs at /home/yellowtent/platformdata/logs/box.log about any errors?

[buesching]

@nebulon It isnt even reachable from a local system, which uses the local address for my.<your cloudron domain>. The webinterface is still reachable. Do I have to set the well known location as I asked before?

[buesching]

Where can I change the dns settings? I would like to resolve the local address for my.<your cloudron domain>. I want to bypass my firewall. Maybe it should work then.

[nebulon]

If the local systems can resolve the public IP then this seems fine.
What kind of reverse proxy setup is this, maybe it interferes with the requests? Can you maybe disable that and expose the system directly just to see if it works as expected then?

[buesching]

We are using an Securepoint firewall with integrated reverse proxy. I will talk to the support.

[buesching]

Hello, we solved the problem. It was a wrong configuration in our firewall.

[nebulon]

Thanks for sharing and glad it worked out in the end.

[abuyuy]

@nebulon Have you marked the topic as solved because you found a way to migrate users in old setup to OIDC properly, or because the issue that hijacked the original topic of the thread solved itself (see posts above)?

[nebulon]

The package contains a user migration script https://git.cloudron.io/cloudron/bookstack-app/-/blob/master/migrateUsers.js?ref_type=heads
By now this should have been applied and it will be removed again from the start.sh

[abuyuy]

Thank you for the quick support!

[buesching]

Hello,

Now, I have the same problem at a customer. Cloudron and bookstack are not accessible from the internet. It is used only internal. I created a custom.conf for the unbound dns. But it is still not working. How do I have to configure the dns setting that OpenID Connect is working? We use a wildcard certificate.

[girish]

@buesching said in Cannot login anymore after switch to OIDC in latest update:

But it is still not working

Can you tell us what is not working?

a) Can users reach the cloudron dashboard?
b) Is the app not able to reach the cloudron oidc api? Like maybe nothing appears after you click oidc button in browser?
c) Is that wildcard certificate self signed?

If c) is the issue then fixing unbound won't help here. Most apps do not accept self signed certs for oidc. I recommend simply using a proper wildcard cert. You can either switch to one of the Cloudron supported DNS providers OR purchase a wildcard cert (it's only 45usd at https://www.garrisonhost.com/ssl-certificates/alphassl). In either case, you can keep your setup completely private as now.

[buesching]

@girish
a) yes
b) same error as in the 4th post. See above.
c) it is not self signed. Its from geotrust.

We had the same problem in our environment. It was an misconfiguration of our reverse proxy (from the firewall).
In the environment of the customer the dashboards are note accessible from the internet. In that case the traffic does not run over the reverse proxy. The connection is established locally.

[girish]

@buesching Ah, all right. So, your issue looks like bookstack cannot contact cloudron dashboard because of the reverseproxy not looping back http requests. Is this sorted out now? Or are you still looking for assistance?

[girish]

If you are looking for some DNS solution to avoid the reverse proxy, you have to add something like this to unbound custom config:

server:

local-zone: example.com typetransparent
local-data: "my.example.com A 172.18.0.1"

example.com is your dashboard domain . 172.18.0.1 is the internal oidc server for the app can reach.

[buesching]

@girish In our environment everything ist working fine now.

[buesching]

@girish
I changed my unbound config. I restarted the unbound service. Still get this error when trying to login.

[girish]

@buesching This is what I have in /etc/unbound/unbound.conf.d/custom.conf:

server:

local-zone: smartserver.io typetransparent
local-data: "my.smartserver.io A 172.18.0.1"
local-data: "my.smartserver.io AAAA fd00:c107:d509::1"

Then, systemctl restart unbound

To verify (44dea384c5b0 is the bookstack container. you can do docker ps to find the bookstack container) :

root@ubuntu-8gb-nbg1-1:~# docker exec -ti 44dea384c5b0 /bin/bash
root@ff31e413-a6d2-4914-bccb-5eeef305839c:/app/code# host my.smartserver.io
my.smartserver.io has address 172.18.0.1
my.smartserver.io has IPv6 address fd00:c107:d509::1

The above confirms our unbound is working.

Then:

root@ff31e413-a6d2-4914-bccb-5eeef305839c:/app/code# curl https://my.smartserver.io/openid/.well-known/openid-configuration
{"authorization_endpoint":"https://my.smartserver.io/openid/auth","claims_parameter_supported":false,"claims_supported":["sub","email","email_verified","family_name","given_name","locale","name","preferred_username","sid","auth_time","iss"],"code_challenge_methods_supported":["S256"],"grant_types_supported":["authorization_code","implicit","refresh_token"],"issuer":"https://my.smartserver.io/openid","jwks_uri":"https://my.smartserver.io/openid/jwks","authorization_response_iss_parameter_supported":true,"response_modes_supported":["form_post","fragment","query"],"response_types_supported":["code","id_token","id_token token","code id_token","code token","code id_token token","none"],"scopes_supported":["openid","offline_access","email","profile"],"subject_types_supported":["public"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_jwt","client_secret_post","private_key_jwt","none"],"token_endpoint_auth_signing_alg_values_supported":["HS256","RS256","PS256","ES256","EdDSA"],"token_endpoint":"https://my.smartserver.io/openid/token","id_token_signing_alg_values_supported":["RS256"],"pushed_authorization_request_endpoint":"https://my.smartserver.io/openid/request","request_parameter_supported":false,"request_uri_parameter_supported":false,"userinfo_endpoint":"https://my.smartserver.io/openid/me","claim_types_supported":["normal"]}

We get OIDC response. Can you check where it fails above for you?