oidc: shaky login form when loading the app

[nebulade]

If only OpenID connect is configured for login, the initial app load to login shows first the regular login form (username/password) then removes it and places the OpenID button.

Video to better explain:

It seems like the meteor client state or so takes a bit to be loaded, while in the meantime probably the various login views and options should be hidden and only then shown?

Happy to attempt a fix, if someone can point me in the right direction there :)

[xet7]

@nebulade

• What webbrowser version you use?
• What operating system version you use?
• How much RAM does your device have?

[nebulade]

This happens both on latest firefox and chrome and I'm using my laptop for that 16Gb ram on Archlinux.

If I am throttling the network via the browser dev tools, then I can see this for longer. As far as I can observe, once enough assets are loaded, it shows always the normal login form, then later when a websocket is created, it switches the UI over once this message has arrived:

{"msg":"result","id":"11","result":{"ldap":false,"oauth2":true,"cas":false}}

Maybe any login UI should be hidden until that point to only show components which are actually configured? As mentioned I am not so familar with meteor, just guessing, but other frameworks have concepts of ng/v-cloak to avoid flickering until the client side is ready https://vuejs.org/api/built-in-directives.html#v-cloak

[xet7]

@nebulade

Do you mean something like OnRendered? Maybe somewhere here:

• https://github.com/wekan/wekan/blob/master/client/components/main/layouts.js#L80

Or spinner loader not shown for correct amount of time?

• https://github.com/wekan/wekan/blob/master/client/components/main/layouts.jade#L46

Building WeKan: https://github.com/wekan/wekan/wiki/Emoji

[nebulade]

So after much digging around the code, which is quite confusing at first with meteor, I am not exactly sure how that username/password form gets injected at all, nor any of the additional ones which are enabled at https://github.com/wekan/wekan/blob/13979389cabc3be9d49d5ff67a7bea32849b89bb/client/components/settings/connectionMethod.js#L4C16-L4C41

Seems like some magic I am not aware of. But also it seems even if I hardcode the password property to false there, the UI first renders it and then removes it. So I think this is all happening during page/application load and this password form is just some default somewhere until settings are fetched.

Then I tried to look into this isLoading but here it seems this is actually for the login form submission state, during the authentication attempt, this seems to be correct if that is the use-case for isLoading.

I guess this leaves the question for me, how to have all UI bits first hidden and then once the settings are fully fetched, the options which are enabled, should get selectively shown. From https://github.com/wekan/wekan/blob/master/client/components/main/layouts.js#L50 it seems the logic is reversed, first show some and then selectively hide.

[xet7]

@nebulade

Seems like some magic I am not aware of.

My non-magic version of of WeKan does not yet have enough features to replace Magic Meteor Kitchen Sink WeKan.

https://github.com/wekan/php/blob/main/page/sign-in1.php

https://github.com/wekan/php/blob/main/page/sign-in2.php

[nebulade]

oh so you are rewriting wekan in php? So there is no real use of patching up the meteor version?

[xet7]

@nebulade

oh so you are rewriting wekan in php?

I have tiny prototypes in many different programming languages. It depends do I get something working.

So there is no real use of patching up the meteor version?

Helping to patch up meteor version would be very welcome.

But if everyone just says all that code is magic, maybe rewriting with Basic and SQL would be better.

[nebulade]

Well I understand. Currently, I am trying to figure out where exactly those login form elements come from and how to hide them by default, and then selectively show them once the settings have been fetched. If you have any pointers to where those are coming from, similar to the links into your php version, that would be quite helpful.

Specifically it seems setting the default for the element with .at-pwd-form class to be hidden and then reverse the logic at https://github.com/wekan/wekan/blob/master/client/components/main/layouts.js#L50 would in my understanding help much, but I somehow miss the point where that element .at-pw-form is coming from or specified.

[mfilser]

Magic here is just a feature in Meteor and in general called: reactive programming

[nebulade]

After much grepping through meteor code, it appears to me this behavior to always build the password login components can't be tweaked up-front. So the proposed change will resort to overwriting display via css selector of the at-pw-form class.