OIDC not working after app migration to another Cloudron & IPv6 error

[humptydumpty]

Issue 1: I migrated Matrix/Synapse & Element apps to another Cloudron. Using the File Manager on the new app Synapse > /app/data/configs/homserver.yaml > oidc_providers (line 82)

It's still listing my older server: my.domain.com/openid. However, I have the server installed on a subdomain at: my.awesome.domain.com. I know I can edit this line, but what are the correct client ID and client secret? Do I need to change these to match the new server or should I just update the URL's and save? I updated the URL's to: my.awesome.domain.com. However, when attempting to login into the Element app via the "Continue with Cloudron" option, it says Client INVALID.

Issue 2: IPv6 error when checking my server https://federationtester.matrix.org. The IPv4 connection report is a "success", all green listed.

Connection Errors
Get "https://[2500:7600:FJ00:22:1000:e5ff:gh33:2355]:443/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Please note, IPv6 above has been anonymized.

I have ports 80 and 443 open in the home router. Is that sufficient for Matrix?

Thanks!

[joseph]

However, when attempting to login into the Element app via the "Continue with Cloudron" option, it says Client INVALID.

@humptydumpty this might be a package bug that the OpenID URL is not adjusted correctly. In the screenshot with "OpenID Connect Error", is it even redirecting to the correct dashboard (i.e the domain in the browser URL bar) ?

[joseph]

Can you check /app/data/configs/homeserver.yaml ? The oidc_providers section inside it.

[humptydumpty]

No, it wasn't redirecting properly. It was set to the old domain. All the links after that section too also pointed to the old domain (authorization_endpoint, token_endpoint, userinfo_endpoint). After updating the links, it started to redirect to my new domain. I just tried to login into Element CR app (web) and the invalid token error persists.

Matrix is working fine though. My previous users, set up, iOS clients, desktop clients, are still functioning without any change required after migration.

[humptydumpty]

Copy of the oidc_providers section:

oidc_providers:
  - idp_id: cloudron
    idp_name: Cloudron
    issuer: https://my.sub.domain.com/openid
    client_id: xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx
    client_secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    scopes:
      - openid
      - email
      - profile
    authorization_endpoint: https://my.sub.domain.com/openid/auth
    token_endpoint: https://my.sub.domain.com/openid/token
    userinfo_endpoint: https://my.sub.domain.com/openid/me
    allow_existing_users: true
    skip_verification: true
    user_mapping_provider:
      config:
        localpart_template: '{{ user.sub }}'
        display_name_template: '{{ user.name }}'

[nebulon]

Maybe there is a package bug in updating the client id/secret in the config file. Can you verify that those match the values from the env variables in the webterminal in the app? You can run env command to see all variables. The ones in question are https://docs.cloudron.io/packaging/addons/#oidc

[humptydumpty]

I don't see any OIDC references when running env in the webterminal in the Matrix app. Here's a screenshot without exposing any private stuff so you can see what lines are in there. Please let me know if you need me to email this instead.

[humptydumpty]

CR turn secret = matches
SMTP pass = matches
CR Postgre DB = matches
CR Postgre Pass= matches

The entire OIDC Providers info in homeserver.yaml aren't referenced in the result of env so there's nothing to check against.

homesever.yaml is 100 lines total if that helps.

[humptydumpty]

I installed matrix/element on another domain on my other Cloudron and compared the homeserver.yaml files. There's some differences with the code formatting like one has " the other doesn't, some lines have [ ... I fixed up my existing install to match the formatting of the test app but that didn't help. The only difference now is the following:

#This is on the broken matrix homeserver.yaml
localdb_enabled: true 

#This is on the new test matrix homeserver.yaml
localdb_enabled: false
pepper: xxxxxx (random characters)

Could this be caused by the IPv6 error I get when checking via the Matrix Federation checker website?

Connection Errors
Get "https://[2500:7600:FJ00:22:1000:e5ff:gh33:2355]:443/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

[nebulon]

If you don't see those env variables, are you sure you installed the app with Cloudron usermanagement even?

[humptydumpty]

This is an old install that I migrated. The users are my Cloudron users from the previous CR, so the answer is yes?

I kept the same usernames on the new CR and migrated the app only - not the entire Cloudron if that makes a difference.

The mobile and desktop clients continue to work as usual. I didn't have to do anything like logout and back in. Now, I'm thinking that if I do log out, I might run into issues getting back in. I'll try logging in on a new desktop app when I get home to see if it works.

BTW, I set up the admin synapse from github (done it before) and I couldn't log in into that either. "e is not defined" or something like that.

[nebulon]

if you miss the OIDC related env variables, then most likely Cloudron user management is not enabled. You can check this in the app configuration view in the access control tab.

Is it possible that you have enabled openid manually using a custom open id client setting instead of the Cloudron user integration? If so that would at least explain the wrong client id

[humptydumpty]

@nebulon if I did, it's definitely not intentional - I'm not a fan of OIDC tbh.

[nebulon]

So that is the root cause then. Since you migrated the app, the new Cloudron does not have the OIDC client credentials which the other Cloudron has. You have to recreate this and configure the app accordingly.

[humptydumpty]

I'm not sure how to do any of that but I'll worry about this later as I received a reply from Hetzner support about my VPS (SMTP issue) and you won't believe what they said.