Backend user management: remove plain-text password from invite, add reset password button

[zaxbux]

This PR removes the plain-text password in the initial invite email for backend admins. Sure, a password reset link in an unencrypted email is not much more secure than including the password, but it does help improve "cyber hygiene" by preventing that password from being stored in whatever systems see that email on the way to the user's inbox. It also allows the user to choose their own password immediately, instead of remembering to change it after signing in.

I also added a "Send Password Restore" button to the user update form, giving other admins the ability to send a password reset email for another user.

Tested:

• Creating new user without password sends email with reset link.
• Creating new user with password sends email with normal login link.
• Send password restore button sends a password reset email to the user.

[bennothommo]

@zaxbux thanks for the PR. We're prioritising finishing off 1.1.3 and releasing the website and marketplace. Once these are done, we'll be happy to consider implementing this.

We'll be in touch soon.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this is still being worked on, please respond and we will re-open this pull request.
If this pull request is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this is still being worked on, please respond and we will re-open this pull request.
If this pull request is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[bennothommo]

@zaxbux sorry for the delay in getting back to this. I've had a look through and this looks fantastic - well done. I've tested the email out and works as expected.

Could we perhaps move the restore button to be a text link underneath the Password fields so that it is contextual?

Also, not sure how possible this is, but I notice currently that it contains the user's ID in the password restore link. Would it be possible to remove this and just rely on the code, so we're not inadvertently revealing user IDs?

This is more of a nice-to-have change, but I'd also prefer if we could time limit the password restoration so that they have, say, 24 hours to restore their password. I'm not sure if this is already the case or not.

[LukeTowers]

I've got some ideas around improvements in this area so just hold off for now

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this is still being worked on, please respond and we will re-open this pull request.
If this pull request is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this is still being worked on, please respond and we will re-open this pull request.
If this pull request is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[multiwebinc]

Also, not sure how possible this is, but I notice currently that it contains the user's ID in the password restore link. Would it be possible to remove this and just rely on the code, so we're not inadvertently revealing user IDs?

Since the password is hashed with a random salt, you need some way of identifying which user the hash belongs to before being able to verify the hash. Two things come to mind to accomplish this:

1. Have a separate password recovery table and the ID sent to the user is the password recovery ID instead of the user id.
2. Add another column to the users table with a random string (maybe combined with uniqid() to guarantee uniqueness) stored in plain text. Both the random string and the temporary password are mailed to the user and the random string is used instead of the user ID to select the user.

[LukeTowers]

Ideally we handle this with 1. since that's the way Laravel handles it nowadays I believe.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in this pull request for the last 6 months.
If you intend to continue working on this pull request, please respond within 3 days.
If this pull request is critical for your business, please reach out to us at wintercms@luketowers.ca.