Menu
Community /Pin to ProfileBookmark
@NogDogNov 13.2013 — #I think you have your logic reversed in your if clause, since preg_match() will return 1 if the pattern matches. It does beg the question, though: why do you want to limit users to only those characters, when current security best practices are for strong passwords to contain letters, numbers, and "special" characters? I would just test for minimum/maximum length requirements, and let the users use whatever passwords they want within those restrictions. @NogDogNov 13.2013 — #
Using mysql_real_escape_string() for any character strings being entered into the DB takes care of all SQL injection issues, regardless of what the user submitted. To that end, the code in there messing around with htmlentities is unnecessary and effectively cancels itself out anyway. So instead of this...
...just do...
...and SQL injection is not an issue, while you've removed unneeded extra processing. ?
The only time you should need to use htmlentities() is when outputting text to the browser -- it is not a database sanitizing function.@NogDogNov 13.2013 — #
What you can do is generate a pseudo-random string, such as with uniquid(). You store that in an additional column in the users table, along with another timestamp column with the current date/time in it (NOW()). In the link you send in the email, you include that random string as one of the URL parameters (presumably along with the user ID as another field). Then when the link is clicked, you check to see if the user id and random token match, and that the timestamp is not older than whatever you decide the maximum time should be between when it is generated and when the user must "use it or lose it." If all those criteria are met, you display the new password form, which you would include that random token in as a hidden field, so you can do the same check again when they actually enter the form.
preg_match problem need solution?
I have problem with my preg_match function it seems it always returns true no matter what’s in the input form? it suppose to just return true when the value has junkies in it.
this is part of the code, the echo in thisCheckerNum always display 1, even when $_POST[‘number2’] has nothing in it… , and because of that it will always go to “die(“Error: passwordOld contains invalid characters!”);”, I need to know why..
[code=php]function thisCheckerNum($str)
{
$var = preg_match(‘/^[a-zA-Z0-9]*$/’, $str);
echo $var;
return $var;
}
if (isset($_POST[‘number1’]) && isset($_POST[‘number2’])) {
$passwordOld = $_POST[‘number2’];
$passwordOld2 = $_POST[‘number3’];
$passwordNew = $_POST[‘number4’];
$passwordNew2 = $_POST[‘number5’];
$sql = “SELECT * FROM users WHERE email=’$email’ AND password=’$passwordOld'”;
$query = mysql_query($sql);
/* filter vals*/
$passwordOld = mysql_real_escape_string(html_entity_decode(htmlentities($passwordOld)));
$passwordOld2 = mysql_real_escape_string(html_entity_decode(htmlentities($passwordOld2)));
$passwordNew = mysql_real_escape_string(html_entity_decode(htmlentities($passwordNew)));
$passwordNew2 = mysql_real_escape_string(html_entity_decode(htmlentities($passwordNew2)));
/*
This counts how many records match our query
*/
echo $email.”<br >”.$passwordOld.”<br >”.$passwordOld2.”<br >”.$passwordNew.”<br >”.$passwordNew2.”<br >”;
//Die if account contains non-alphanumeric characters
if(thisCheckerNum($passwordOld) == 1)
{
die(“Error: passwordOld contains invalid characters!”);
}
Sign in
to post a comment6 Comments(s) ↴
0
@NogDogNov 13.2013 — #0
@NogDogNov 13.2013 — #...
I done a little research people claim some characters might be harmful to database? that's why it should rule out those? I don't know for sure but if it's a security issue may be I should just follow the main line? I don't know about that, too.[/QUOTE]
Using mysql_real_escape_string() for any character strings being entered into the DB takes care of all SQL injection issues, regardless of what the user submitted. To that end, the code in there messing around with htmlentities is unnecessary and effectively cancels itself out anyway. So instead of this...
[code=php]
$passwordOld = mysql_real_escape_string(html_entity_decode(htmlentities($passwordOld)));
[/code]...just do...
[code=php]
$passwordOld = mysql_real_escape_string($passwordOld);
[/code]...and SQL injection is not an issue, while you've removed unneeded extra processing. ?
The only time you should need to use htmlentities() is when outputting text to the browser -- it is not a database sanitizing function.
0
@NogDogNov 13.2013 — #I have another question though, I'm make a shopping site from ground and I'm pretty much learning it from ground up..
so forgive me that my lack of fundamental knowing of the ecommerce world, if user wanted to change their account password,
would it be appropriate or most importantly- secure, that my site send an email back to their email with link in it, that when they open it, it takes them to a page that ask them to input new password directly to database? My main concern is that the page will input the new password regardless of what the original password is,
but I think what strongly back this idea is that the link in theory is only accessible if the clicker can open that email account in the first place? So it should be secure right? Should I use this method?[/QUOTE]
What you can do is generate a pseudo-random string, such as with uniquid(). You store that in an additional column in the users table, along with another timestamp column with the current date/time in it (NOW()). In the link you send in the email, you include that random string as one of the URL parameters (presumably along with the user ID as another field). Then when the link is clicked, you check to see if the user id and random token match, and that the timestamp is not older than whatever you decide the maximum time should be between when it is generated and when the user must "use it or lose it." If all those criteria are met, you display the new password form, which you would include that random token in as a hidden field, so you can do the same check again when they actually enter the form.