Skip Navigation

[Remonté au deuxième échelon] Password Reset Process

This support ticket is created Il y a 5 années et 3 mois. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Aucun de nos assistants n'est disponible aujourd'hui sur le forum Jeu d'outils. Veuillez créer un ticket, et nous nous le traiterons dès notre prochaine connexion. Merci de votre compréhension.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

Marqué : 

Ce sujet contient 7 réponses, a 2 voix.

Dernière mise à jour par Waqar Il y a 5 années et 3 mois.

Assisté par: Waqar.

Auteur
Publications
#1320397

I'm currently working on a few security enhancements. I've applied a hook to the CRED user forms I'm using for registration to ensure users' passwords meet certain criteria so that's all working nicely. The problem comes with the password reset process. Using the WP process (requesting a link etc), a user can reset their password to 1234 if they want to! I've tried using the validate_password_reset hook but that's having no effect.

Is there any reason at all against replacing the password reset process and using an edit version of a User form instead that would contain the user_pass field to allow the password to be updated (and therefore apply the same hook to enforce a strong password)?? I appreciate the user wouldn't be sent a link but they would, of course, have to be logged in to use the form (so the user is verified already).

Thanks

#1320837

Hi Julie,

Thank you for contacting us and I'd be happy to assist.

A regular Toolset user edit form can't be used as a replacement of a "forgot password & password reset forms" since the goal of these forms is to allow users to change or reset their password, in an event they've forgotten or lost the existing one.

In that case, if I'm a user who no longer remembers the existing password, I'll have no way to log in and use the Toolset's user edit form to generate a new password. I'll have to contact you (the website's admin) to manually reset my password, which I'm sure is not what you'll want.

In my tests, "validate_password_reset" hook works as expected to add custom validation rules when using WordPress' default password reset form.
( ref: https://wordpress.stackexchange.com/a/159883 )

On your website, if you're using a custom "Password Reset" page with "[wpv-reset-password-form]" shortcode ( ref: https://toolset.com/documentation/user-guides/views-shortcodes/#vf-428516 ), you can replace it with WordPress' default password reset form and this validation hook should do the trick.

To replace the Toolset's password reset form with a WordPress' default one, please make sure that if and wherever you're using the "[wpv-forgot-password-form]" shortcode ( ref: https://toolset.com/documentation/user-guides/views-shortcodes/#vf-428134 ), you shouldn't include "reset_password_url" attribute that generates the password reset link sent in the email, that redirects to any custom "Password Reset" page.

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

#1320923

Hi Waqar

Thank you for your reply.

I agree a user edit form couldn't be used to reset the password if it had been forgotten but what if the user wanted to change their password and were logged in?

For the situation where the User has forgotten their password, the stackexchange post you've linked to is the one I've worked with but using the toolset shortcode. How do I replace this with the WordPress default password reset form?

Bit puzzled by this:-

please make sure that if and wherever you're using the "[wpv-forgot-password-form]" shortcode , you shouldn't include "reset_password_url" attribute that generates the password reset link sent in the email, that redirects to any custom "Password Reset" page

What's the problem with including reset_password_url?

#1321209

Hi Julie,

Thanks for writing back.

> I agree a user edit form couldn't be used to reset the password if it had been forgotten but what if the user wanted to change their password and were logged in?

- Yes, for updating the password after logging in, users can use a Toolset user edit form as explained in the documentation:
https://toolset.com/documentation/user-guides/using-editing-forms-to-edit-your-profile/

Of course, you'll have to make sure that the custom password validation hook that you have attached to the user registration form, is also attached to this new edit form too.

> For the situation where the User has forgotten their password, the stackexchange post you've linked to is the one I've worked with but using the toolset shortcode. How do I replace this with the WordPress default password reset form?

- I apologize if my message resulted in confusion and I'll be happy to clarify this point.

1. By default, WordPress' lost password form is available at:
yourwebsite.com/wp-login.php?action=lostpassword
( screenshot: lien caché )

2. The link to reset the password that we get in the email leads to WordPress' default password reset form, at:
yourwebsite.com/wp-login.php?action=rp&key={................}&login={username}
( screenshot:lien caché )

Please note how these default forms are showing outside the theme's environment that is applied for the front-end.

3. If you'd like to show the lost password form and password reset form, within your website's front-end themed environment, you can create individual regular pages for them and then use "wpv-forgot-password-form" and "wpv-reset-password-form" shortcodes on them, respectively.

https://toolset.com/documentation/user-guides/views-shortcodes/#wpv-forgot-password-form
https://toolset.com/documentation/user-guides/views-shortcodes/#wpv-reset-password-form

Examples:

a). "Forgot Password" page:
yourwebsite.com/forgot-password/
Shortcode: [wpv-forgot-password-form]
Result screenshot: lien caché

b). "Reset Password" page:
yourwebsite.com/reset-password/
Shortcode: [wpv-reset-password-form]
Result screenshot: lien caché

4. You'll note that if you'll put a request to generate a new password, through the forgot password Toolset form at yourwebsite.com/forgot-password/, it will still generate a new password reset link in the email that will take to the default WordPress password reset form.
( as explained in point 2 )

5. If you'd like your users to get a link to generate a new password in the email that takes them to the custom reset password page ( as explained in point 3b - yourwebsite.com/reset-password/ ), then you'll need to include "reset_password_url" in your [wpv-forgot-password-form] shortcode at "Forgot Password" page:


[wpv-forgot-password-form reset_password_url="yourwebsite.com/reset-password/"]

As a result, now when a user will put a request to generate a new password through the form at yourwebsite.com/forgot-password/ the link in the email will look like this:
yourwebsite.com/reset-password/?action=rp&key={................}&login={username}

Now here is the catch. The function attached to the hook "validate_password_reset" works on the default WordPress reset password form ( point 2 ), but not on the custom Toolset password reset form ( point 3b ).

To summarize, if you'll not use a custom password reset form ( point 3b ), then the only way for users to request a new password would be through the default WordPress password reset form ( point 2 ), where custom validation function will be working.
( in other words, you should be skipping the step from point 5 )

Hope this explanation will help and let me know if any point is still not clear.

regards,
Waqar

#1321841

Hi Waqar

Thank you for your comprehensive explanation; I understand it much better now and appreciate the time you've taken in doing so.

We use Toolset for a variety of reasons. One of the main ones is that our users can work entirely on the frontend and have no need to access wp-admin. This means we can achieve a consistent "look" across the whole site and help keep our sites secure. So, in using the Toolset shortcodes for the reset password process, we maintain this position and not send our users suddenly to a WP page they've never seen before and that doesn't match the rest of the site (bar customisation of course). This gets a huge thumbs up from me. However, in using the shortcodes, I don't think it's unreasonable to expect that they are simply allowing us to use our own custom pages and that nothing else has changed. But this isn't the case. The WP reset form forces the user to create a strong password, the Toolset shortcode doesn't. (Yes the User can check the weak password box on the WP form but this is easily removed). I wonder just how many Toolset users are even aware that the strong password requirement is missing when the Toolset shortcode is used?? That's really worrying; such a situation doesn't just compromise the User who was able to reset to a weak password, it potentially compromises ALL users on the site and the site itself.

Since Toolset is built on WordPress fundamentals, I'm of the opinion that nothing should be 'dropped' in the process and that the password reset shortcode needs to be re-visited & urgently.

#1322071

Hi Julie,

Glad my message helped and appreciate you shared your feedback.

I agree that a builtin feature that ensures strong passwords for Toolset forms would be a very useful addition for the community and I'll request you to please submit a feature request for this at:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

For now, if you'd like to keep using Toolset's password reset form for consistent user experience, one option is to use script-based, password validation to it. You'll find a number of script examples and guides on the topic online, similar to:
lien caché

I hope this helps.

regards,
Waqar

#1322769

Hi Waqar

Thank you for your workaround suggestion - I'll have a look at it.

In my opinion, feature requests relate to functionality that is "nice to have". I don't believe this issue classes as a "nice to have" - it classes as a "must have". The shortcode doesn't follow WordPress fundamentals and is therefore flawed. It needs escalating.

#1324119

Hi Julie,

Thanks for writing back.

I've shared these findings with the concerned team for further review and will keep you updated through this ticket.

regards,
Waqar