Some people believe that mysql_real_escape_string() has some flaws and cannot protect your query even when properly used.
Bringing some fossilized articles as a proof.
So, the question is: is mysql[i]_real escape_string() totally unacceptable?
Or is it's still possible to use this function to create your own kind of prepared statements?
With proofcode, please.
Read up on the try: statement.
try:
# do something
except socket.error, e:
# A socket error
except IOError, e:
if e.errno == errno.EPIPE:
# EPIPE error
else:
# Other error
An important point that I think people here are missing is that with a database that supports parameterized queries, there is no 'escaping' to worry about. The database engine doesn't combine the bound variables into the SQL statement and then parse the whole thing; The bound variables are kept separate and never parsed as a generic SQL statement.
That's where the security and speed comes from. The database engine knows the placeholder contains data only, so it is never parsed as a full SQL statement. The speedup comes when you prepare a statement once and then execute it many times; the canonical example being inserting multiple records into the same table. In this case, the database engine needs to parse, optimize, etc. only once.
Now, one gotcha is with database abstraction libraries. They sometimes fake it by just inserting the bound variables into the SQL statement with the proper escaping. Still, that is better than doing it yourself.
Your server process has received a SIGPIPE writing to a socket. This usually happens when you write to a socket fully closed on the other (client) side. This might be happening when a client program doesn't wait till all the data from the server is received and simply closes a socket (using close function).
In a C program you would normally try setting to ignore SIGPIPE signal or setting a dummy signal handler for it. In this case a simple error will be returned when writing to a closed socket. In your case a python seems to throw an exception that can be handled as a premature disconnect of the client.
According the the page you referenced, the Active Record class uses mysql_ functions for string-escaping. That means it's still building SQL strings up in PHP-land instead of using parametrized APIs into the database. While it may be free of known defects right now, it is still a better idea to use an API that follows a more secure design.
From the MySQL’s C API function
mysql_real_escape_stringdescription:So don’t use
SET NAMES/SET CHARACTER SETbut PHP’smysql_set_charsetto change the encoding as that is the counterpart to MySQL’smysql_set_character_set(see source code of /ext/mysql/php_mysql.c).