-
I have Wekan version 7.01, cloudron app version 4.38.0 installed on cloudron 7.4.3.
It is now showing the only sign in method as a button with
Sign in with Oidc. When I click the button I get a popup requesting me to put in my cloudron credentials, I do that, I click authorize, and then the pop up goes away but the wekan app still stays on the same page with theSign in with Oidcbutton.After clicking the button again without refreshing the page does nothing, no pop up appears and nothing output to the javascript console for the page.
If I refresh the page and click the button I get the popup again but this time it seems to recognize I am signed in to cloudron already as it no longer asks for the username and password but just has an Authorize button.
After clicking the button the pop up disappears but the wekan page doesn't redirect and clicking the
Sign in with Oidcbutton another time does nothing on that page until it is refreshed. -
That is an upstream bug, or more likely a multiple ones. The first one identified as already fixed https://github.com/wekan/wekan/issues/5018
We are looking into debugging this more. For the moment one has to initially basically double login in wekan.
There are also other UI issues where it flickers too much or shows initially the wrong UI elements.
-
Is there anyway I can work around this, something I can edit, comment out, different url to try, some way to force the old authentication flow with user name and password for the time being?
-
G girish moved this topic from Support on
-
Not really, since due to upstream changes we had to get rid of our local package fixes for ldap, which essentially meant to move over to openid despite it having some UI glitches.
You can restore to the old version of course and disable autoupdates for the moment.
-
@nebulon I was looking through the currently open wekan issues that were not older than this year and I am not seeing something as an open issue for them related to OIDC.
Is there any currently open issue with the wekan project that would resolve the issues that are occurring?
-
@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 .
-
@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 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?
-
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
-
@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 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 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-certificatesI 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
-
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-certificatesso 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?
-
PS, this workflow with using
update-ca-certificatesI 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. -
@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 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?
