Perhaps he forgot an order by clause? But it's impossible to know when there's no information about what is wrong and why it's wrong.
jfleck25;11032533 wrote:
$lastname = stripslashes($lastname);
$lastname = strip_tags($lastname);
$lastname = str_replace("`", "", $lastname);
$lastname = mysql_real_escape_string($lastname);
You should learn what these functions do, when to use them and why. Throwing them all in there is most likely undesireable. Btw, I'm not claiming that this has anything to do with whatever you feel is wrong with your script.
The basic principle when it comes to validating user input is to check if it's ok, and if it is not - tell the user so and let them correct it. Let's say a user enter a username: boy/george-odowd (yes it should be an apostrophe but whatever)
Your system just tells him, account created. The created account was however boygeorge-odowd. Then he tries to log in and gets a "no such member". Well, unless you actually do the exact same transformation at login. Which means his login would work, until such a time comes when someone decides that you should allow in account names. And suddenly you no longer strip it from his, and his login is transformed to boygeorge-odowd.
On to the functions used.
stripslashes - returns a string with "stuff" removed. What "stuff" is, actually depends on your php ini settings. In the olden days of PHP 4, magic_quotes_gpc (mainly) and magic_quotes_sybase were used to automatically and silently transform strings by escaping them in ways to possibly make them safe for db insertion. Do note the word possibly. As for the why, this is conjecture: Since this automatic quoting is bad, while users sometimes weren't allowed to change php ini settings (crap hosts I guess) they needed a way to undo the damage done by magic_quotes_ gpc/sybase - enter stripslashes. But the correct thing to do would still be to turn off either of those two directives. They also have been off by default since PHP 5 - several years. And it wouldn't surprise me if those directives no longer exist in 5.5. Sure enough - A trip to the php manual
This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
In short - turn off magic_quotes_whichever. Do not use this function. And at the very least, first check if magic_quotes_gpc is on [man]get_magic_quotes_gpc[/man] before you stripslashes.
striptags- "In my name <abc>this dissappears</abc> while the rest remains". Once again, if you do not allow tags in names (you probably don't), inform the user that they allowed characters are "whatever you explicitly allow" and make them enter something which is.
str_replace (to remove `) - Once again, this transformation is bad since you strip something out. Either leave it as is or inform the user that he used disallowed characters. Or escape it - with the proper function for the proper reasons - see below
mysql_real_escape_string - Using this function here almost makes sense. It only does so at this very specific point in the program since you're preparing data for insertion into a mysql database. The reason it only almost makes sense is that you should no longer be using any mysql function, but rather their mysqli counterparts, in this case mysqli_real_escape_string.
This function may escape ab possibly by inserting a backslash before turning it into a`b. Do note I'm uncertain of exactly what is escaped and how but it doesn't really matter. The point is that this function requires a connection to the database in order to know how to escape stuff since the way characters are interpreted depends on your database and its settings. But the point is, that when you retrieve this data item later on, it will be exactly the same as when you put it in, ab. Which is a big difference from turning ab into ab and then returning ab.
Example: Let's say you allow <, > and / in your strings and a user enter "My name is <em>Neo</em>". When you insert this into the database, you will have to use mysqli_real_escape_string(). Not because the string contains anything dangerous for your database this time, but because it may. Thus you escape it to be entered into the db with the proper function for this purpose.
Later on you retrieve the string to display it as plain text. Since it's plain text, you do no escaping all.
Then you want to display it as HTML - which means you should do no escaping at all.
Then you want to display the text as part of an HTML document and you need to escape < and > - this time using htmlspecialchars which turns them into < and > respectively.
Escaping is context sensitive. But only ever escape for the particular purpose at hand. If you do not wish to allow certain input, you should check for this instead. For example
# ^ at the beginning of a character class negates it
# character class a-zA-Z'- which negated means any character that is not a to z, A to Z, apostrophe (') or dash (-)
$matches = preg_match("#[^a-zA-Z'-]#", $input));
if ($matches === false)
# error of some kind
elseif ($matches)
{
# feedback to user about what input is ok.
}
else
{
# input ok
}
On a side note, I'd recommend turning on ANSI_QUOTES and sticking to following the SQL standard when quoting identifiers, which is using ". backtick is only used with mysql.
