Am I the only one to experience failure to login into admin WebUI, using any user/account/auth method, notably “admin” user after the upgrade?
While I kept a Web browser session that was still logged in as auto-generated user “admin” for the global scope, I upgraded the controller to the new binary and performed the DB migration successfully.
After also upgrading the workers’ and remote clients’ binaries, I was able to access the admin WebUI again/still without having to authenticate, as apparently the credentials/tokens were still valid. After I had looked around the WebUI, I de-authenticated as admin in order to authenticate against some OIDC providers, which worked before the upgrade, but all failed now.
So I tried to fall back to the admin user which was still fine before I had de-authenticated. But now, it fails to login using the password method as well.
Interestingly, remote clients can still authenticate as admin and connect to targets using the token returned by the password method, well as perform any operations on the controller as admin from both local and remote CLIs. Which allows me to inspect the current configuration and to make changes.
Did anything change in the permissions/grants, etc. from 0.2.1 to 0.2.2 which could have this effect? How could I debug that besides inspecting users, accounts, roles, etc. (which look like OK for the admin user, as far as I can tell)? I seem to have seen some commits that were affecting u_auth and similar, or even CORS, but can’t remember if that was before 0.2.2.