non-admin users don't get a password and juju gui --show-credentials doesn't work

[Richard Harding]

I've created a 2.1beta4 controller on maas and added a new user rharding to the controller. I've granted that user add-model access and that user has added a credential for the maas, and created a new model ricktest on it.

The register command given worked well to setup the controller entry, and the user could pass the credential in to get the model created just peachy. When register was run the user set a password. That password is not in the .local/share/juju/accounts.yaml file. The only contents are:

  guimaas:
    user: rharding
    last-known-access: add-model

When the user runs
  juju gui --show-credentials

There is no password output to the user.

  Opening the Juju GUI in your browser.
  If it does not open, open this URL:
  https://10.0.0.155:17070/gui/...
  Username: rharding
  Password:

I think that the UX should be able to show the user's password upon request as it does for the admin user.

[Andrew Wilkins (axwalk)]

That would require us to record the password, in plaintext, on the user's filesystem. We specifically avoid doing this.

Can we come up with an alternative solution that doesn't involve the user typing their password into the browser? They're already logged in via the CLI, so they shouldn't need to do that. IIANM, we used to generate a time-limited, single-use token to paste in. Can we bring that back?

[Richard Harding (rharding)]

I agree with the auto login token. We had that in juju-quickstart and I miss that from the cli when I'm already an authenticated user.

However, I'm curious that we're ok with the approach for the admin user, but we don't replicate it for the non-admin users. At the very least, if we're going to make all non-admin user accounts special in this way we should tweak the UX so that it's clear to the user. Have show-credential output a warning, remove the keys from the yaml output, or fill them in with something that hints there's a password but we've not stored in in any way. Something to smooth over the rough edges of the current experience.

[Andrew Wilkins (axwalk)]

Also agreed about the admin password. We should warn and prompt the user to change it.

In one dimension it's not as bad, because the password is randomly generated, as opposed to something the user has chosen. Hopefully users don't reuse passwords, but I expect they probably do; and storing those on the filesystem would be awful.

OTOH, it's the admin user :)
At one stage we were thinking we should force the user to set a password at bootstrap, which would cause the creation of a macaroon and have the password cleared from disk.

[Anastasia (anastasia-macmood)]

Once admin changes their password, they will be in the same boat as all other users as a duplicate bug to this one indicates. So the scenario is not limited to non-admin users only I'll rename the report.

I also agree that we do not want to store plaintext passwords and I like the idea of GUI using a token to login rather than user/password paradigm.

The question for Juju then is - should we have the 'show-password' options on the commands where users is expecting to see plaintext password?

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.