I’ve been working with the Login extra on a site which has repurposed the ResetPassword functionality for having a new user whose MODX>User has just been created by a snippet to immediate change their password.
The site is having issues with folks clicking the URL provided to them and not being being met with the ‘expired’ message.
Some testing seems to have confirmed this, but I just wanted to verify if anyone in the know can ratify it - does this mean that if the site cache happens to be emptied or otherwise expires (WITHIN the window between the password reset being ‘ordred’ and the link being visited) that means the user won’t able to change their password on that attempt and will need to go around again?
It looks like the value gets written to the default cache partition without an expiration time.
Maybe it would be a better idea to use a custom partition in this case:
//Writes the data to its own cache partition with an expiry time of 2 hours.
$options = array(
xPDO::OPT_CACHE_KEY => 'resetpassword',
);
$this->modx->cacheManager->set('login/resetpassword/'.md5($fields['id'].':'.$fields['username']),$password, 7200, $options);
Thank you - this worked beautifully and avoided the site’s clear-cache function.
For those playing at home, I updated the following files. Note that I updated the files in the package which means they’ll be overwritten at the next update of of the Login extra. (Buyer beware.)
core/components/login/controllers/web/ForgotPassword.php starting at line 234
Replaced
This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.