magic_quotes

Evening,

I am new to this list, so please if this email is "offensive" to anyone
I didn't know any better. Not here to start a war or similar.

I have a couple questions about magic_quotes and it's deletion in PHP 6.

I've been lazily following php.internals and read about register_globals
and magic_quotes (finally) being deleted from PHP.

I don't have any scripts that run with register_globals - not worried
about PHP 6 for that case.

But... magic_quotes.
If my understanding is correct magic quotes will give ', " and \ (for
ASCII characters, e.g. \n) a preceding backslash to escape it. I also
see that magic_quotes_gpc() is On by default. So all data in $_POST and
$_GET etc. has escaping backslashes.
If in a .htaccess I should set
php_flag magic_quotes_gpc Off

That would lead to $_POST data like Jingle's Bells to be passed as
Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data gets
written into a MySQL table to which I perform addslashes(). And on
retrieval stripslashes().
If I keep on doing that - and just start coding with magic_quotes_gpc
Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should they?

Kind Regards,
Johannes Lindenbaum

Johannes Lindenbaum wrote:
> Evening,
>
> I am new to this list, so please if this email is "offensive" to anyone
> I didn't know any better. Not here to start a war or similar.
>
> I have a couple questions about magic_quotes and it's deletion in PHP 6.
>
> I've been lazily following php.internals and read about register_globals
> and magic_quotes (finally) being deleted from PHP.
>
> I don't have any scripts that run with register_globals - not worried
> about PHP 6 for that case.
>
> But... magic_quotes.
> If my understanding is correct magic quotes will give ', " and \ (for
> ASCII characters, e.g. \n) a preceding backslash to escape it. I also
> see that magic_quotes_gpc() is On by default. So all data in $_POST and
> $_GET etc. has escaping backslashes.
> If in a .htaccess I should set
> php_flag magic_quotes_gpc Off
>
> That would lead to $_POST data like Jingle's Bells to be passed as
> Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data gets
> written into a MySQL table to which I perform addslashes(). And on
> retrieval stripslashes().
> If I keep on doing that - and just start coding with magic_quotes_gpc
> Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should they?

That part is correct.

You shouldn't need to use addslashes - use mysql_real_escape_string or
mysql_escape_string depending on your (current) php version - they are
both "locale aware" and will escape things for you depending on mysql
server (re: language setup).

Then just use htmlentities to display on the frontend rather than using
stripslashes.

Of course other db's have similar functions, check the manual.

--
Postgresql & php tutorials
http://www.designmagick.com/

On 11/30/06, Johannes Lindenbaum <johannes@jlindenbaum.de> wrote:
> And on retrieval stripslashes().

You shouldn't have to stripslashes your data coming from the DB.
Addslashes and friends exist to escape your data. It is not part of
your data. So when you INSERT "Jingle\'s Bells" when you retrieve it
you should have "Jingle's Bells" not "Jingle\'s Bells" because \ was
syntax to escape the single quote.

On Wed, November 29, 2006 11:55 pm, Johannes Lindenbaum wrote:
> But... magic_quotes.
> If my understanding is correct magic quotes will give ', " and \ (for
> ASCII characters, e.g. \n) a preceding backslash to escape it. I also
> see that magic_quotes_gpc() is On by default. So all data in $_POST
> and
> $_GET etc. has escaping backslashes.

Yes, but the problem is that *ALL* data in GET/POST has the escaping
backslashes as if it were ASCII data, and it may *NOT* be ASCII data.

It might be UTF-8.
It might be UTF-16.
It might be some charset you've never even heard of.

And guess what?

addslashes() on non-ASCII data, UTF-8 for example, is like a condom
with a hole in it.

> If in a .htaccess I should set
> php_flag magic_quotes_gpc Off
>
> That would lead to $_POST data like Jingle's Bells to be passed as
> Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data
> gets
> written into a MySQL table to which I perform addslashes().

Switch to:
http://php.net/mysql_real_escape_string

> And on
> retrieval stripslashes().

No, no, and no.

You do *NOT* use stripslashes() on the data coming OUT of MySQL.

Unless you've already screwed up and done BOTH addslashes() and
MagicQuotes, which in essence did addslashes() twice, so you added
bogus data to your database.

Jingle's Bells
+ [magic quotes] ===> Jingle\'s Bells
+ [addslashes] ===> Jingle\\\'s Bells
========================================
Corrupt data in MySQL: Jingle\'s Bells

The whole point of this escaping is to identify characters that MySQL
should store as data, rather than interpret as "non-data"

Jingle's Bells
+ [magic quotes *OR* addslashes *OR* mysql_real_escape_string]
=====> Jingle\'s Bells
================================================== ============
Correct data in MySQL: Jingle's Bells

Once you've done that correctly, what MySQL actually stores is the
data, not the escapes it needed to identify the data.

So if you find yourself using stripslashes() on your MySQL data to get
it "right", then, in reality, you've already screwed up and stored
non-data as data.

So go back and fix your script to NOT double-escape the input, then
fix your bad data in MySQL to NOT have non-data (\ escape character)
as part of your data.

This is going to be a major pain, I know, but you'll only make it
worse the longer you put it off.

It will be a whole lot easier if you can "freeze" the input routines
to not take anything in between the time you fix those and when you
fix the data within the database...

If not, you'll want to note EXACTLY which rows have corrupted extra
backslashes and which do not, so you can apply stripslashes() to only
the corrupt data.

> If I keep on doing that - and just start coding with magic_quotes_gpc
> Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should
> they?

You are correct that turning off magic_quotes_gpc is a good way to
prepare for PHP 6.

This has been rant #53, brought to you by the character "\"
:-) :-) :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Richard Lynch schrieb:
> On Wed, November 29, 2006 11:55 pm, Johannes Lindenbaum wrote:
>
>> But... magic_quotes.
>> If my understanding is correct magic quotes will give ', " and \ (for
>> ASCII characters, e.g. \n) a preceding backslash to escape it. I also
>> see that magic_quotes_gpc() is On by default. So all data in $_POST
>> and
>> $_GET etc. has escaping backslashes.
>>
>
> Yes, but the problem is that *ALL* data in GET/POST has the escaping
> backslashes as if it were ASCII data, and it may *NOT* be ASCII data.
>
> It might be UTF-8.
> It might be UTF-16.
> It might be some charset you've never even heard of.
>
> And guess what?
>
> addslashes() on non-ASCII data, UTF-8 for example, is like a condom
> with a hole in it.
>
>
>> If in a .htaccess I should set
>> php_flag magic_quotes_gpc Off
>>
>> That would lead to $_POST data like Jingle's Bells to be passed as
>> Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data
>> gets
>> written into a MySQL table to which I perform addslashes().
>>
>
> Switch to:
> http://php.net/mysql_real_escape_string
>
>
>> And on
>> retrieval stripslashes().
>>
>
> No, no, and no.
>
> You do *NOT* use stripslashes() on the data coming OUT of MySQL.
>
> Unless you've already screwed up and done BOTH addslashes() and
> MagicQuotes, which in essence did addslashes() twice, so you added
> bogus data to your database.
>
> Jingle's Bells
> + [magic quotes] ===> Jingle\'s Bells
> + [addslashes] ===> Jingle\\\'s Bells
> ========================================
> Corrupt data in MySQL: Jingle\'s Bells
>
> The whole point of this escaping is to identify characters that MySQL
> should store as data, rather than interpret as "non-data"
>
> Jingle's Bells
> + [magic quotes *OR* addslashes *OR* mysql_real_escape_string]
> =====> Jingle\'s Bells
> ================================================== ============
> Correct data in MySQL: Jingle's Bells
>
> Once you've done that correctly, what MySQL actually stores is the
> data, not the escapes it needed to identify the data.
>
> So if you find yourself using stripslashes() on your MySQL data to get
> it "right", then, in reality, you've already screwed up and stored
> non-data as data.
>
> So go back and fix your script to NOT double-escape the input, then
> fix your bad data in MySQL to NOT have non-data (\ escape character)
> as part of your data.
>
> This is going to be a major pain, I know, but you'll only make it
> worse the longer you put it off.
>
> It will be a whole lot easier if you can "freeze" the input routines
> to not take anything in between the time you fix those and when you
> fix the data within the database...
>
> If not, you'll want to note EXACTLY which rows have corrupted extra
> backslashes and which do not, so you can apply stripslashes() to only
> the corrupt data.
>
>
>> If I keep on doing that - and just start coding with magic_quotes_gpc
>> Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should
>> they?
>>
>
> You are correct that turning off magic_quotes_gpc is a good way to
> prepare for PHP 6.
>
> This has been rant #53, brought to you by the character "\"
> :-) :-) :-)
>
>
Thank you very much all of you - I know what I'm doing with my weekend.
I think I was disillusioned by the fact that I had a couple Queries
screw up because they were of the format (example):
INSERT INTO table (text) VALUES( '".$_POST['data']."');
where $_POST['data'] was filled with something similar to Jingle's Bells
(a single quote), thus screwing up the query, because it was trying to
do VALUES( 'Jingle's Bells');
So by pure ignorance I just added addslashes infront of my queries.
I've come a long way since then, and I'll probably just end up writing a
smartQuoting function for my MySQL class that will use
mysql_real_escape_string() on INSERTS so I have the correct data in my
table. :)

Thanks again!