tags:

views:

74

answers:

2

Someone help me:

$query = "INSERT INTO tbl_users(user, password, password_def, userid, level
          , regdate, lastdate, email) VALUES('$username', sha1('$password')
          , sha1('$password'), '$userid', '0', NOW(), NOW(), '$email');";

$userid is a ramdon md5 id.

It gives me this error:

posttokenError: Account not created You have an error in your SQL syntax; 
    check the manual that corresponds to your MySQL server version for the right
    syntax to use near '\'esck21\', sha1(\'password\'), sha1(\'password\'), 
    \'14bd25cbe111c2975232b33ee8c2' at line 1

I think I'm gonna have a heart attack. Thanks.

+1  A: 

You need to backtick (`) the password field:

$query = "INSERT INTO `tbl_users` (`user`, `password`, `password_def`, `userid`
              , `level`, `regdate`, `lastdate`, `email`) 
          VALUES('$username', 'sha1($password)', 'sha1($password)', '$userid'
              , '0', NOW(), NOW(), '$email');";

You should always backtick your fields, tables and databases.

One more thing: pay attention to SQL Injections, use mysql_real_escape_string().


After some discussion I'm conviced your problem lies with your quoting usage, check zombat answer.

Alix Axel
that didn't work.
CSSJediEsck21
@CSSJediEsck21: It might have been the `sha1()` function, should be `'sha1($pass)'` instead of `sha1('$pass')`. I've updated it. Try again.
Alix Axel
@Alix, re: the semi-colon: Whoops, guess nothing. Never seen the semi-colon included before, unless it's directly in an sql file. Learned something new
munch
@Alix: SHA1() is a mysql function. It shouldn't be enclosed in quotes.
fireeyedboy
Backticking is only necessary when the database, table or column name uses MySQL **keywords**
OMG Ponies
@fireeyedboy: AFAIK `sha1()` is a PHP function, `SHA1()` is a MySQL one. I've never seen functions in MySQL in lowercase, not sure if they are case-sensitive or not.
Alix Axel
PS.: mysql is pretty forgiving about not backticking keywords. As a precaution it doesn't hurt though.
fireeyedboy
To my knowledge MySQL functions are case insensitive. But your right that sha1 is also a PHP function.
fireeyedboy
@fireeyedboy: He used the MySQL `NOW()` function in uppercase, so that makes it really hard to guess which function he's trying to use.
Alix Axel
@Alix: I see what you are saying, but enquoting it still wouldn't have made a difference then, because PHP wouldn't parse the function anyway.
fireeyedboy
+2  A: 

Judging by the error message, it looks like you might be calling some kind of escaping function on the entire query, such as addslashes($query) or mysql_real_escape_string($query). This will escape every quote in the query, when really what you want to do is only escape the quotes that are inside your variables.

If this is the case, then you want to be doing something like this instead:

$query = "INSERT INTO tbl_users(user, password, password_def, userid, level,
regdate,lastdate, email) VALUES('".mysql_real_escape_string($username)."',
sha1('".mysql_real_escape_string($password)."'), 
sha1('".mysql_real_escape_string($password)."'), 
'".mysql_real_escape_string($userid)."', '0', 
NOW(), NOW(), '".mysql_real_escape_string($email)."')";

That will properly escape your data without erroneously escaping the rest of the query. Once you've done this, do not run $query as a whole string through other forms of escaping.

zombat
+1 I believe this is the right answer.
fireeyedboy
Shouldn't the `password` field be backticked?
Alix Axel
I don't know why this answer is downvoted. The error message clearly shows backslashes where they shouldn't be, resulting in unquoted values being inserted where a string value is expected and the unquoted value is an interpreted as an invalid columnname (I believe)
fireeyedboy
@Alix: `password` is not a MySQL reserved word (see http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html), so it is a valid identifier. It is the name of a function, but unless it is used with function syntax (ie. `PASSWORD()` with brackets), MySQL parses it the same as any other identifier.
zombat
@zombat: That wasn't true for MySQL 4, not sure about MySQL 5 though.
Alix Axel
I didn't downvote, but if SHA1 is a PHP function - shouldn't it be inside the `mysql_real_escape_string()`?
OMG Ponies
@OMG Ponies - `SHA1()` is also a MySQL function. See http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_sha1. If it was me, I'd probably do it in PHP to put the CPU load on the front end instead of in the database, but I didn't want to muck with the original query for the answer.
zombat
@zombat: I've tested the password field in MySQL 5, you're right.
Alix Axel
@Alix - yeah, I have faith in the MySQL reserved words list. Also, I know I personally used "password" as a field name long before I learned about backticks. :D Of course, using backticks is always a good idea!
zombat
I was using: $query = $this->_db->real_escape_string($query);now, there are a lot of warnings: Warning: mysql_real_escape_string() [function.mysql-real-escape-string]: Access denied for user 'SYSTEM'@'localhost' (using password: NO) and a error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\r\nregdate,lastdate, email) VALUES(\'\',\r\nsha1(\'\'), \r\nsha1(\'\'), \r\n\'\' at line 1
CSSJediEsck21
It's working now, I forgot to remove $query = $this->_db->real_escape_string($query);
CSSJediEsck21
@zombat: I would rather put the payload on mysql, as mysql is probably faster. Furthermore, if you let MySQL do the hashing (on insert, as well as on comparing when selecting) you will always be sure your code is portable. If another middleware application (e.g. not PHP) wants to query the database you will be garantueed the hashing is always MySQL's implementation. Plus, you keep the responsibilities close to the actual data source. Much of this is also true for DATETIME calculations (which coincidently are far more superior than PHP date functions IMHO).
fireeyedboy
Since I got curious about this mysql SHA1() vs PHP sha1(), I found this article that recommends a subquery when you are selecting records with mysql SHA1(). That makes sense, but it feels a bit hackish though. Here's the article: http://saviourc.wordpress.com/2009/09/26/sha1-speed-differences-php-vs-mysql-part-2/
fireeyedboy
@fireeyedboy - true, MySQL's implementation of the same functions would be faster than PHPs, but it's a lot easier to add front-end application servers to bear the load than it is to add database servers. :)
zombat
@fireeyedboy - wow, interesting article. I would consider that a bug in MySQL's optimizer if considers the `SHA1()` function non-deterministic for a hard value and runs it on every record! The sub-select makes for an interesting work-around.
zombat
@zombat: I guess you got a point there. And about Mysql being faster: well, that's what I thought initially, but turns out to be not so cristal clear as I would have thought, as per the article I linked to.
fireeyedboy