Hii there,
I’m trying to create a way for users to reset the password using a link mailed to them.
The link looks like this:
https://localhost:8080/reset-password/lametoken
where lametoken is randomly generated and stored in the database before sending the mail.
I have created a route like this:
$routes->connect('/reset-password/*',['controller' => 'Users', 'action' => 'reset_password', 'reset-password'])
->setPass(['token']);
But now I need to redirect the user to the same link again in case of an error.
I’m trying to do this like this:
return $this->redirect(['controller'=>'Users','action'=>'reset_password','reset-password',$token]);
This, however, leads to the url becoming this:
http://localhost:8080/reset-password/lametoken?token=reset-password
How can I make it so that this ?token=reset-password get’s removed?
Solution: do not use redirects…
when you dont have token on pattern , why you are sending token with
->setPass(['token']);
review your routes , problem is there
for more info https://book.cakephp.org/3.0/en/development/routing.html
I’ve found this bit to be helpful indeed, thanks
Here are my 2 cents and please, take it with a grain of salt. When it comes to security issues I rather make sure the code comes near OR ZERO errors.
What I do in this cases is to create the token, encode that token, send the encoded token to the client via email, if the encoded token matches the DB change the password. I think the encoding part is the critical one, cause when it comes to compare the one that the sis creates should be strictly match to the the one that the user gets. That is why is so important to SALT your app in your app file and use SHA1 or SHA265 for encoding your token.
You are not out of the parc by using the routes in this case because you don’t want to divulge what is your method called, so what I do is to route the method to another name more clever than reset-password !
Let me know if this help and happy coding !!
Well, security shouldn’t be a huge issue in this case.
It might not look like it, but this is actually the second step in resetting the password (after the user clicks a link in their mail “I” send them).
What the app does is when you request to reset your password (via the forgot-password page), it generates a token that is 64-characters long (tho we might decrease this to 32-characters down the road) and slaps that in the database after which it sends the reset link to the user.
When the user clicks that link, it goes to the reset-password page where they can enter their new password (and a confirmation) after which they submit the form.
On submission, the app will check whether the token is found in the database and to which user it belongs (and changes that user’s password if a match has been found).
This token is valid for 1-hour after it has been put into the database.
Mean, this does pretty much the same except this system doesn’t use time and resources to encrypt the token.
The 1-hour limit is to make it practically impossible to brute-force when looking at the huge token size (I’m still working on implementing a captcha as well).