Wekan version 7.01, cloudron app version 4.38.0 prompting for Sign in with Oidc but not showing the app after authorizing the sign in

[girish]

@ChristopherMag right, we have made tasks internally to investigate and fix . We didn't open them upstream. Thanks for pointing that out. I will open them .

[nebulon]

@ChristopherMag https://github.com/wekan/wekan/issues/5018 was the one which had a fix but apparently either introduced new issues or not solving it fully. Its not clear yet

[girish]

I opened https://github.com/wekan/wekan/issues/5028 now. We need 2 more - one for first login does not work and another for the login flicker.

[ChristopherMag]

@girish and @nebulon The suggestion was made to restore an old version of the app when I had first opened this request but at that time doing so would have lost a days worth of work as all of our office's activities are managed through Wekan with cards and checklists on those cards for all the things we work on.

At the time I was the only user not able to get in on my main computer and I had a laptop that still allowed me access so I was able to work around it and figured we could wait for a fix.

At this time another person in the office has now lost access to wekan and I have worked around it by logging into a computer used by someone who works part time and then having them remotely control that computer and perform actions in wekan as the part time employee but this is a rough work around and it seems clear that this is going to cause a larger impact on us in the not to distant future.

I know it isn't reasonable to be able to monitor all the up stream packages for breaking changes but it would be really nice if there was a feature to have some build system test functionality like logging in when a new app version is created so that if there is a change that breaks login the app wouldn't get published to the gallery.

I see that progress being made on https://github.com/wekan/wekan/issues/5028 which is greatly appreciated but it seems like even if https://github.com/wekan/wekan/issues/5028 was fixed we still wouldn't be able to login as right now we are able to get through the login process wit oidc and click authorize on the pop up but nothing happens after that and refresh just restarts the authentication process.

Am I understanding this correctly and that the resolution of https://github.com/wekan/wekan/issues/5028 would not solve the issue of being able to get into the app to see and work on cards?

[nebulon]

So you are saying you can't log in with those users even if you log in twice in a row (which was that one bug already fixed, but maybe others still lurking)

Generally despite having to double login it should work as such and we are actively using wekan also.

For those UI glitches we also have https://github.com/wekan/wekan/issues/5029 where I have created a pull request to fix this at https://github.com/wekan/wekan/pull/5032

[ChristopherMag]

@nebulon After I click authoirize on the pop up window, that window closes and focus returns to the wekan window but nothing happens at that point.

The sign in with OIDC button is disabled so it cannot be clicked again but the page doesn't respond.

We have our own root CA with a wild card signed certificate from this root ca used in cloudron.

I don't know the authentication flow but maybe there is a problem with the redirect back not trusting the endpoint it is posting something to.

Here is a video of the process:

[nebulon]

Not sure about the custom certificate, but wekan backend does need to contact the OpenID provider at the dashboard domain. Do you see any errors in the process in the browser logs or wekan server side logs?

[ChristopherMag]

@nebulon I should have thought to check, yes it is has the following error Jul 31 10:59:21 {"line":"406","file":"oauth_server.js","message":"Error in OAuth Server: Failed to get token from OIDC https://my.cloudron.magnusonfinancial.com/openid/token: request to https://my.cloudron.magnusonfinancial.com/openid/token failed, reason: unable to verify the first certificate","time":{"$date":1690815561809},"level":"warn"}

[nebulon]

Right so it seems wekan does not accept the certificate then. This would have to be fixed with wekan itself. Not sure how we can proceed quickly here to get this working again.

[ChristopherMag]

@nebulon If a cloudron domain DNS Provider is set to manual and a certificate is provided all apps that are loaded under that same domain should trust that certificate such that if you have cross app https connections, those connections will be trusted for all apps within that same domain at minimum.

So assuming foo.crt was used in the form above then doing the below for each docker container so that they would each trust anything specified in foo.crt:

ADD foo.crt /usr/local/share/ca-certificates/foo.crt
RUN chmod 644/usr/local/share/ca-certificates/foo.crt &&update-ca-certificates

I didn't realize that this was related until we were looking this today I put this in as a request more generally a while back: https://forum.cloudron.io/topic/6381/if-the-custom-certificate-option-is-chosen-please-map-a-path-to-the-public-keys-into-each-container-s-ca-certificates-or-equivalent

I don't want to double dip but we recently had an issue with nextcloud that ended up being related to cloudron apps not trusting the manual certificate and I responded with something similar to @girish here: https://forum.cloudron.io/topic/9705/nextcloud-not-able-to-open-documents-using-the-onlyoffice-document-viewer-editor/37?_=1690813813008

[ChristopherMag]

Is there a way I can manually do the equivelant to doing the following in the app's docker config

ADD foo.crt /usr/local/share/ca-certificates/foo.crt
RUN chmod 644/usr/local/share/ca-certificates/foo.crt &&update-ca-certificates

so that I can get the wekan app to trust the manually specified certificate being used by Cloudron for all its apps and for the dashboard url?

[ChristopherMag]

PS, this workflow with using update-ca-certificates I believe is relevant to containers based on debian/ubuntu but it might be a different workflow for whatever the cloudron base image is, trying to find documentation on what the cloudron base image uses to see if I can provide more correct information.

[girish]

@ChristopherMag Are you loading a self signed cert or a certificate signed by trusted CA? If it's the latter, everything should work. Can you confirm this aspect?

BTW, for the tests you mentioned in another comment, this is actually what we do. We have tests to login via browser automation. But these are tested against valid certs and not with self signed certs. I think it's not possible to support self signed certs reliably across apps especially for single sign on.

[girish]

BTW, is there a reason to use a custom cert in the first place? With DNS automation you can get free wildcard certs and keep your apps totally inside an intranet as well.

[ChristopherMag]

@girish We have our own self signed root-ca that is then signing the wildcard certificate so cloudron isn't using a self signed cert but it is using a certificate that is generated from a self signed root-ca.

I would love to not use a custom cert as it is a pain to manage loading it on all our client systems including mobile devices.

We use domains.google as our dns provider which is different than Google Cloud DNS and so it hasn't been one of the supported DNS providers in Cloudron.

I would love to not have this problem and maybe it is worth it to move to a new DNS domain registrar and DNS provider to get this accomplished as the "Google Domains" product has been sold off to Squarespace and I am not sure what the future will look like after they start to migrate customers over.

Maybe I can also split off our DNS hosting from our domain registrar.

The $12/year flat pricing with anonymization of the whois information, basic site redirection, support for wildcarding an entire subdomain so that any A record requests for hosts under that subdomain respond with the same ip address, all without upselling and spamming us was the motivation to move everything to domains.google.

The have been such a breath of fresh air compared to the godaddy's and networksolutions of the world.

Do any of the providers you support provide DNS for free as long as you register the domain name through them like domains.google does?

[nebulon]

Actually you could use for example DigitalOcean DNS api only. It is free. You can keep your domain registrar and just set the nameservers from DigitalOcean there.

Being able to use LetsEncrypt certificates will surely spare you lots of side-effects and time.

[ChristopherMag]

@nebulon I will look into this and try to get this implemented, hopefully today, assuming that they handle all of our use cases.

Currently domains.google will redirect all requests from a domain that is an alias we have of another domain to the other domain both accross http and https and will preserving the path and query string parameters.

So a request for https://www.mainalias.com/somepath?some=value is redirected to https://www.main.com/somepath?some=value which requires domains.google to get a free https certificate issued for mainaliasl.com, to run a webserver that has the ability to receive http requests, and then to set that webserver up to do the redirects, and they do this for free as a part of them being the registrar for that domain.

As I write this I realize that maybe I just leave the dns servers as domains.google's dns servers for those domains and only change the name servers for the domain being used for our cloudron instance.

Thank you for helping me work through this and I will report back once I have gotten this setup with a test domain.

[ChristopherMag]

@girish @nebulon Thank you so much, I now have our domain registrar as domains.google but the authoritative name servers for our base domain and the subdomain we use to host cloudron as digital ocean and we now are able to use let's encrypt certs and login to wekan again!

The biggest trip up was the fact that domains.google defaults to returning its authoritative name servers for every subdomain of a domain it is hosting but digital ocean didn't so I needed to create name server records in the root domain configured in digital ocean that pointed back to digital ocean's name servers again before the subdomain which was also on digital ocean started working properly.

I did have to restart cloudron, sync dns, and renew all certs several times each as I worked through changing things and trying to get those changes to propagate, it at minimum took a reboot before the system stopped using the wildcard cert we had configured previously and started actually using the let's encrypt wildcard even though I had done multiple sync dns and renewa all certs before that.

This is a much better setup than before and it looks like it isn't going to cost anything more than what we were paying before, definitely a great solution and will hopefully stop us from hitting these weird issues with apps having trouble because they don't trust secure connections between each other.

Thank you both so much for helping me work through this!

[girish]

@ChristopherMag yes, having valid certs is the best way forward. Certs are also used in various non-HTTP protocols (irc, jabber, DoT, DoH etc) and most mobile apps will pretty much refuse to connect without valid certs. You are just fighting a battle which you will lose eventually. If not now, in the next update of the app.

Cloudron has support for self signed certs, but Cloudron started even before Let's Encrypt was a reality . These days all that code is just legacy. There is really no reason to use self signed certs for most purposes.