Fix password reset and set functionality

[getdatakick]

Handling customer passwords by thirtybees platform is not very good. At the moment, there are 3 flows (I know about), and all of them needs to be fixed

Reseting customer password in front office

Current flow

1. customer ask for password reset - enters her email address
2. customer receives email with password reset link
3. after clicking on reset link, customer is directed to page that sends new email with generated plain password
4. customer needs to go to email again, copy new password, and use it to log in
5. if customer wants to use their own password, she had to navigate to My Account > My personal information and change the password again

There are several issues with this flow. The main problem is the plain password -- this is very unprofessional and naive solution. Another minor issue is the need to check email twice.

Proposed solution

1. customer ask for password reset - enters her email address
2. customer receives email with password reset link
3. after clicking on reset link, customer is directed to page and asked to enter new password
4. after submitting the new password, password is changed, customer is automatically logged in, and confirmation email (without password) is sent to customer

Creating customer from back office

Current flow

When new customer is created from back office, employee must enter some password. There is no automated mechanism to let customer know about this new password. Employee must manually send it via email, in plain text.

Again, this is very unprofessional. Passwords are send in clear text via email, and employee knows the password. Employees also very often generate weak passwords, for example by using customer fist or last name, email address, etc...

Proposed solution

When new customer is created from back office, employee shouldn't be asked to provide password. Instead, new email with link to set password should be automatically sent to customer. This would re-use front-end resetting password functionality (see above)

Converting guest to customer

Current flow

1. employee clicks on Transform to customer account button
2. email is send to customer. This email does not contain plain password, instead it contains ****** placeholder
3. because customer doesn't know his password, she must go to store, and follow reset password flow to retrieve new password

ok... I think we can all agree this is just unbelievable. I mean, really?

Proposed solution

1. employee clicks on Transform to customer account button
2. customer receives email with link to set new password

[getdatakick]

Related discussion on forum: https://forum.thirtybees.com/topic/3340-customer-password-when-admin-created/

[Dh42]

This has been something I have put a bit of thought in over the years. I like your solution, but I would feel like I was not honest if I did not say how I feel.

The plain password is easy. Its output before its hashed into the database. I get that people do not like it, but I think their dislike is unfounded. The truth is once you lose control of your email address it does not matter how a password is reset, someone can reset it.

I had an argument with someone on a forum one time about the whole thing. Their idea was that the password is transferred to the user in the email and it could be intercepted. While that is possible, I don't think it is any more likely than someone intercepting the post from your computer to the website when you change your password.

That all being said, I like your solution in fixing it, that is pretty much the standard these days for password resets.

I would complicate the matter more though..... 99% of themes are not going to have this template and it will just break for people. This might be a good time to consider child themes. It would give us more flexibility if the theme was loaded as child->parent->default. That way the default template would always have these views and at least something would load. Since most themes are off of the default theme the classing and structure would likely work out of the box.

[getdatakick]

I would complicate the matter more though..... 99% of themes are not going to have this template and it will just break for people. This might be a good time to consider child themes. It would give us more flexibility if the theme was loaded as child->parent->default. That way the default template would always have these views and at least something would load. Since most themes are off of the default theme the classing and structure would likely work out of the box.

This is a fair point, we need some mechanism to display this new template

[therampagerado]

Can't we just use the old password recovery tpl and simply name it password recovery 2 with the reset form added? So the email should redirect to password-reset2 and it should be fairly easy to implement this if there's simply a changed form.

We can upload this template in the forum for themes that don't get updated for TB.

Sending passwords via email is lame and even computer lamers these days know that's very bad.