[nycphp-talk] un-escape db content using php or ADOdb functions
Hans Zaunere
bulk at zaunere.com
Wed May 2 13:39:58 EDT 2012
Hi,
> Hi,
> I've read your interesting article:
>
http://www.nyphp.org/phundamentals/5_Storing-Data-Submitted-Form-Displaying-
Database
Ahh, an oldie but a goodie :)
> I have a couple of questions about the function fix_magic_quotes:
> 1) Why do you disable magic_quotes_gpc and magic_quotes_sybase via
> ini_set? Fixing the content escaped by magic quotes should be enough
> in my opinion, am I wrong?
magic_* anything is a bad idea - it's an infamous mistake that PHP made.
Explicitly escape what you need, based on the destination the data is going
to.
> 2) As far as I know, stripslashes is affected by magic_quotes_sybase,
> s if magic_quotes_sybase is on, both addslashes and stripslashes work
> in a sybase-style way. For this reason I don't think you need to use
> str_replace.
For databases (MySQL in particular), you must always use the database
specific escaping. This means mysql_real_escape_string(). This is because
of character encoding.
> And finally a more general question: are you aware of any method for
> un-escaping content based on db-specific escape function? I mean
> something kuje stripslashes but specific so: the counterpart of
> addslashes is stripslashes, is there any counterpart for
> mysql_escape_string or for the adodb function qstr or the PDO quote
> function?
> I know that, in an ideal world, we don't need them but if an
> application has been build using a "escape everything" approach and
> you need to work with that, you need to unescape content when you
> don't use it in a query and stripslashes doesn't work if you switch
> from addslashes to something like adodb->qstr.
Yes, you should never need to "unescape" what you read from a database. And
the problem you're facing here, is exactly why you should use the MySQL
escaping functions, rather than generic magic_*, addslashes, etc.
If you've inherited an application that does this, then it could be painful.
If it were me, I'd first run a script/process to clean up the existing data
as best as possible, and get away from these bad escaping practices. Then
code the rest of the application correctly, using MySQL's real_escape()
function.
H
More information about the talk
mailing list