Dashboard: Login form compatibility with password managers

Created on 4 Dec 2017 · 15Comments · Source: kubernetes/dashboard

After upgrading to dashboard 1.8.0 and making it available at https://dashboard.example.com/, I've decided to save a few tokens into my password manager to then quickly authenticate in the UI with different privileges. However, I've noticed that the dashboard's login form is incomparable with the password managers I tried (1password and LastPass). Usually password managers work fine with any website without any effort from its developers, so it seems like there's something trivial missing in the angular-controlled login form. I'd like to open this issue to start a discussion.

Environment

Dashboard version: 1.8.0
Kubernetes version:
Operating system: macos Firefox / Chrome with 1password and LastPass extensions

Steps to reproduce

Make the dashboard available at https://dashboard.example.com/

_scenario 1_

Open the dashboard and see the login screen
Paste a token into the form and click "sign in"

_scenario 2_

Open your password manager browser extension and manually add a new password entry for https://dashboard.example.com/ (I tried 1password and LastPass).
Open the k8s dashboard and see the login screen
Click on the password manager's icon, select the existing entry with the just-created token and click on it to paste the data into the form.

Observed result

_scenario 1:_ the password manager does not suggest to save the token as a new password entry

_scenario 2:_ the token (which is saved as password) does not get pasted into the _token_ form field

Expected result

_scenario 1:_ the password manager suggests to save the token as a new password entry

_scenario 2:_ the token gets pasted into the _token_ form field of the login form and "sign in" is automatically pressed

Comments

Password managers like 1password and LastPass are widely used both by individuals and teams. They are recommended in quite a few security articles, so it is likely that their prevalence will grow in the forthcoming months. Keeping k8s tokens in a password manager seems like a right thing to do, because this way cluster admins can share access with their colleagues quite easily while keeping things secure and transparent.

It'd be great to have the dashboard login form compatible with the password managers, which probably just means that its elements should get a few extra HTML attributes. If anyone has any experience with making password managers happy, please share your thoughts!

Source

kachkaev

All 15 comments

Thanks for reporting this issue. We will take a look on it.

maciaszczykm on 4 Dec 2017

👍1

Great feature request. Simple, yet very helpful. We already have an idea why it is not working and should be easy to fix.

floreks on 4 Dec 2017

🎉1

I've had some time to test it and with our current design and custom login page having full support for password manager extensions might not be possible. #2642 will enable partial support for them as after successful sign in last pass have asked me to save "credentials". It will not autocomplete the field for you nor show additional button on input field to just click and choose stored credentials. It is required to either right click and choose it from menu or use extension menu to trigger autocompletion.

I have found that unfortunately last pass plugin support for input field is triggered by certain key words used as placeholder for input field and login button. We would have to use Password description instead of Enter token for token field and rename our Sign in button to Login. This is not very nice. I guess it should work just by setting the field type and maybe id or name tag on field.

We will leave partial support for now. Maybe it will be improved by them at some point.

floreks on 5 Dec 2017

Thanks for investigating the issue @floreks! Perhaps this hint from LastPass can help too? https://lastpass.com/support.php?cmd=showfaq&id=3385

kachkaev on 5 Dec 2017

I have seen it during investigating. It doesn't help as it is their "perfect" example. All the fields with id, name, value, everything that is a keyword they are looking for. For custom login forms with different text it just does not work correctly.

floreks on 5 Dec 2017

👍1

After #2642 has been merged, I installed the dev release and the experience became better! Now entering the token for the first time and pressing "Sign In" triggers a password manager's prompt to save a new item. So _scenario 1_ can be considered as resolved. Reusing a saved password is also possible with a minor hiccup - you have to click on the radio button first, because "token" is not a default login option.

What if we make "token" selected by default? In this case password managers will be able fill in the input in one less click, but the kubeconfig scenario UX will not get worse. At the moment the kubeconfig radiobutton is initially on, but you still need to make one extra click before you upload a file. If "token" option is default, clicking on kubeconfig can trigger the window right away - still the same one click.

One extra benefit of making "token" a default option is that the input field can be made focused when the form shows. Users will be able to command v into a new tab without any extra clicks (e.g. when they want to paste a token from kubectl or an email).

WDYT?

kachkaev on 6 Dec 2017

One more minor bit: I don't think that an asterisk for marking mandatory fields is necessary in the form. There's only one value to enter and it's an obvious thing. Asterisks normally come with a comment saying _fields marked with * are mandatory_. Without this remark they are just clutter.

Shame that I don't know angular and so can't submit a PR with all this.

kachkaev on 6 Dec 2017

👍1

We can change ordering. It is not a problem. Anyway this should be handled by adding autofocus to the input field so it will actually be focused when page first loads.

As for the * sign it is how angular material works. Adding required tag to input field triggers whole validation logic and adds this sign to every field. We don't want to change default behavior here.

floreks on 6 Dec 2017

Looks like you can remove the asterisk while keeping the behaviour by adding md-no-asterisk to the input. This will be just a cosmetic change that makes the form a bit cleaner. IMO asterisks only make sense when a form contains a _mix_ of required and optional fields. In any case, this is a very minor thing.

kachkaev on 6 Dec 2017

👍1

Perhaps keeping the order of the radio buttons is fine, because this way the "token" option is closer to a corresponding input field, which is good from the proximity principle. Just making the second radiobutton selected by default is OK.

If choosing "kubeconfig" opens a file dialog box right away, nearly no one will have to click on "Choose kubeconfig file" input. This will be only necessary if you've cancelled a dialog and want to trigger it again.

Alternatively, the design can be changed so that both input fields are always visible (each under its radio button). This will make the form a bit taller, but less "magical", thus the relationships between the elements will be more obvious. This will let users click on a token input or a file picker at any time and see the radio button re-checked accordingly.

kachkaev on 6 Dec 2017

Thanks for removing the asterisk in #2666 @floreks, the form looks a bit cleaner now!

Password manager support has improved significantly despite that it's still not ideal. However, it's great that it is now possible to login in just three actions (instead of many more as it used to be):