MySQL() Function Deprecation in PHP 5.4

[righteousfail]

I was kind of worried at first thinking about transitioning, but when I looked into what Mysqli was actually about I realized the actual changes to the query code would be relatively small:

http://www.php.net/manual/en/mysqli....-interface.php

[myrianna]

I might as well go through it now... not that hard or time consuming with find+replace xd. Just got to remember to do it this way with future stuff

[judda]

This is where abstracting away the actual database object helps a fair bit. If you had abstracted it, then this change would be in 1 file instead of trickled through multiple.

~judda

[Hituro]

Looks like they are only deprecating mysql_list_dbs() at this point in 5.4.x

http://docs.php.net/manual/en/migrat...deprecated.php

[SpotOnTech]

Working on a few sites lately I've ran into multiple $_GET and $_POST that are in free air and not escaped in any way, shape or form. I think it would have been nice if the mysql() functions would have thrown an automatic fatal error if they're not escaped. I think PDO will be nice, but it's sure hard when you have a site that's fully coded using all mysql and there is no function library or master includes in place.

[Avalanche]

Thankfully, SQL stays pretty much the same. It's just the names of the functions you really have to worry about.

[judda]

Working on a few sites lately I've ran into multiple $_GET and $_POST that are in free air and not escaped in any way, shape or form. I think it would have been nice if the mysql() functions would have thrown an automatic fatal error if they're not escaped. I think PDO will be nice, but it's sure hard when you have a site that's fully coded using all mysql and there is no function library or master includes in place.

You do realize that that is not physically possible for these functions to do this. How do they know that you are not trying to "DELETE FROM users WHERE userid = '1' OR 1=1--"? How is the function to know that? Yes, you can because you are able to look at the context of the code and make an informed decision however, the database is just doing exactly what it is being told.

TBH, people should never include the user's input directly into a query. They should be using query parameters. This avoid the need to escape the strings all together.

~judda

[SpotOnTech]

You do realize that that is not physically possible for these functions to do this. How do they know that you are not trying to "DELETE FROM users WHERE userid = '1' OR 1=1--"? How is the function to know that? Yes, you can because you are able to look at the context of the code and make an informed decision however, the database is just doing exactly what it is being told.

TBH, people should never include the user's input directly into a query. They should be using query parameters. This avoid the need to escape the strings all together.

~judda

The Zend engine can already parse out bad data (mysql_real_escape_string anyone?). Why can't mysql() do it anyway? If a user is trying to DELETE * FROM dbtable then they deserve to have bad things happen. That's what DROP is for.

[judda]

The Zend engine can already parse out bad data (mysql_real_escape_string anyone?). Why can't mysql() do it anyway? If a user is trying to DELETE * FROM dbtable then they deserve to have bad things happen. That's what DROP is for.

DROP is for dropping tables ... not emptying them. They are two completely different things.

What functions / objects in the Zend framework do you use for that. I would like to read up on it (because I don't believe it works that way).

~judda

[SpotOnTech]

Zend's framework info: http://www.ibm.com/developerworks/op.../os-php-zend1/

Also, a good article on mysql_real_escape_string vs. addslashes: http://shiflett.org/blog/2006/jan/ad...-escape-string