Can't Login to Admin WebUI after Upgrade from 0.2.1 to 0.2.2 anymore

Boundary
1

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.
Thank you.

2

I had the same exact problem and spent 4 hours debugging it yesterday.
I could login via CLI but the WebUI would always give me an Authorization Error when using the same exact credentials.

My guess is either CORS isn’t working or I had mine setup improperly.

Haven’t had the time yet to look deeper into it, but disabling CORS in the Boundary Config let me login to the Web UI.

1 Like
3

@ronaldburns Thanks for the heads-up, and for your pointer! First, I was hesitant to ask, as unsure if it was just me. So will take a closer look at CORS and related commits.

4

@ronaldburns Indeed, after disabling CORS temporarily in the controller(s), authentications succeed again! Thus will have to devise a proper CORS setup now.

#API & UI Listener runs on :9200
listener “tcp” {
purpose = “api”
…
cors_enabled = false # = true by default
}

1 Like
5

Hi there and thanks for raising this issue. It seems that this is caused by an incomplete CORS configuration. By default, CORS is enabled but only serve://boundary is included in cors_allowed_origins. This allows the desktop client to connect, but not admin UI.

There are a few options to resolve this issue:

  • Enable all CORS origins: cors_allowed_origins = ["*"]
  • Explicitly enable just the origin used to access the admin UI in the browser
  • Disable CORS: cors_enabled = false. With CORS disabled, the admin UI will work, but the desktop client will not be able to connect.
2 Likes