Details
Description
When managing a SolusVM service (admin or client), there is a tab to change the root password.
- Update the root password box to add a link/button to Generate Password
- This Generate Password button will open a modal to allow a password to be generated, as described in
CORE-552 - The password should be alphanumeric, i.e. lower-case and upper-case A-Z characters, and 0-9 characters
- The password length appears to support anywhere from 6 to 50 characters, but we'll go with a 25 character length
- After generating the password using the modal, it should update both the Password field and Confirm Password field and be saved accordingly upon submission
- This Generate Password button will open a modal to allow a password to be generated, as described in
When managing a SolusVM service, clients can reset the root password. Clients may choose a password that is rejected by SolusVM's API, or one that is very weak.
Change this option so that Blesta generates a new password automatically.
Currently clients click the "Change Password" button, then enter the new password twice and click "Change Password" button below that form. Instead of the "New Root Password" and "Confirm Root Password" fields, generate a new password here and display it instead.
New Root Password
PASSW0RD-GENERATED-HERE (Large text, possibly in a well)
Replace the second "Change Password" button with a check box that says:
[x] I have saved the above password
[ SAVE BUTTON ]
The checkbox must be checked before the password can be updated.
This will solve both of these problems. We can generate a secure password, one that will not be rejected by SolusVM's API.
I don't think anything needs to change on the admin side, we may wish admins to be able to set a specific password.
Issue Links
- is blocked by
-
CORE-552 Add support for a data attribute with input fields for auto-generating a password
- Closed
What are the SolusVM requirements for a root password? And why not make those requirements known when setting a new password and enforce them with rules?
This functionality looks to replace the current manual-creation of a password, which is a useful and flexible feature, with just a random password generator that creates a password in some way that is currently undefined. What would the password requirements be? Is it necessary for a client to check the checkbox to acknowledge they have saved the password when they can just reset the password any time they want if they forget it anyway?
A general password generator is described in
CORE-552that could be useful here too. An option to display the password next to the password field in plain-text could also be an option.