How good or bad is the SQL filtering?

[anderson_catchme]

I have a SQL statement which is difficult to use PDO on, it might not even be possible to do.

So I'm filtering it like this:

$search = $_GET['search'];
$search = preg_replace("/[^A-Za-z0-9]/", " ", $search);
$search = $mysqli->real_escape_string($search);

Will this result in an acceptable level of security?

[ginerjm]

How can a statement be 'difficult to use PDO on'?  Whatever do you mean?

[anderson_catchme]

How can a statement be 'difficult to use PDO on'?  Whatever do you mean?

 

It's a dynamic query for one, so id need to dynamically generate the question marks somehow. I just prefer strongly to filter this one, honestly. I also find PDO harder to debug.

[Jacques1]

None of this is a valid reason for giving up a robust solution in favor of some homegrown “filtering” stuff.

 

In fact, this makes absolutely no sense whatsoever. Where are the quotes? Why on earth would you replace non-alphanumerics with spaces? What is the mysqli_real_escape_string() supposed to do when you've already removed all of its target characters?

[ginerjm]

How can you say that pdo is harder to debug?  One doesn't debug the interface.  One debugs the query statement which is the same regardless of whether you use mysqli or pdo or mssql.

[Jacques1]

Prepared statements are indeed harder to debug, because there's no complete query at any point. The best you can get is a bunch of information about the parameters via PDOStatement::debugDumpParams(), but this doesn't even print the corresponding values.

[anderson_catchme]

I can't use PDO here guys, because of limitation of MYSQL. Not every query supports PDO: Info here:

 

http://stackoverflow.com/questions/13682355/pdo-and-mysql-fulltext-searches

[CroNiX]

That article you linked to says, in an edit, that it was fixed in more recent versions of mysql for AGAINST() pattern.