Easy addslashes() ?

[csn]

Right now I do:

if (!get_magic_quotes_gpc()) {
$var1 = addslashes($var1);
$var2 = addslashes($var2);
$var3 = addslashes($var3);
}

$sql = "UPDATE ... $var1 ... $var2 ... $var3 ...";

$result = query($sql);

I'd really like to put the get_magic_quotes_gpc() and addslashes() in the query function, instead of doing it beforehand for each and every query.

[toma42]

Why not set it globally for each script by putting this in your set_env.php file:

ini_set('magic_quotes_gpc', 1);

[csn]

'off' is the recommended setting. It's also considered bad coding practice to rely on it and not check for it. The code needs to work both for 'on' and 'off'. Also, if it is on, you'll need to add stripslashes() to all code that accesses cookies and other request vars, but that'd probably be easily placed in one function. Finally, it appears 'ini_set('magic_quotes_gpc', 1);' isn't allowed if safe_mode is enabled.

[Sxooter]

Originally posted by csn
Finally, it appears 'ini_set('magic_quotes_gpc', 1);' isn't allowed if safe_mode is enabled.

I understand the whole "don't let people change dangerous settings in safe mode" thing, but this one's kinda humorous, because it isn't letting you go from the less safe to the more safe setting.

Please note that while depending on something like magic_quotes is considered bad practice for writing portalbe SAFE code, it's not necessarily a bad thing when developing applications that will only ever be run in a controlled environment, i.e. a large corporate intranet with 20 PHP developers or something might well just say that all servers will be setup by group X, and the test before going online is one to make sure that settings Y though Z have been done, and one of those is magic quotes being on, then it's just a waste of time to bother checking each time. Just have the machine be setup to fail to server PHP if it gets turned off.

But I agree that for most projects, it's a good idea to check to see if it's on. For my use, I don't have it on because it got in the way of other applications in unfun ways, so I know it's not there and I have to escape it each time.

[csn]

I have to deal with the alphabet soup of various servers others use my scripts on ;P.

Couple ideas I have:

• Regexp replace the sql sent to query() somehow.

• Make a function like update($table, $vars, $where), then do:

  for ($i=0; $i <= count($vars); $i++) {
  if (is_string($vars[$i])) {
  $vars[$i] = addslashes($vars[$i]);
  }
  }

  // then assemble the query...

EDIT: Actually, $vars would need to be an associative array.

[toma42]

Originally posted by csn
'off' is the recommended setting. It's also considered bad coding practice to rely on it and not check for it. The code needs to work both for 'on' and 'off'. Also, if it is on, you'll need to add stripslashes() to all code that accesses cookies and other request vars, but that'd probably be easily placed in one function. Finally, it appears 'ini_set('magic_quotes_gpc', 1);' isn't allowed if safe_mode is enabled.

From php 4.3.1 php.ini-recommended
; - magic_quotes_gpc = Off [Performance]

So it's only for performance, not security. It is not concidered bad coding to rely on specific settings to be set globally for your application.

Maybe I'm blind, but the documentatoin does NOT list ini_set as a safemode disabled function:
http://us4.php.net/manual/en/features.safe-mode.functions.php

[toma42]

ah, ini_set is limited to the php.ini setting of safe_mode_allowed_env_vars

So it's configurable on a server by server basis.

Fact: If you want clean, easy to edit and maintain code, turn magic_quotes_gpc on and turn magic_quotes off.

[Sxooter]

Originally posted by toma42

Maybe I'm blind, but the documentatoin does NOT list ini_set as a safemode disabled function:
http://us4.php.net/manual/en/features.safe-mode.functions.php

Well, there's some discussion on that very subject a bit further down the annotated docs.

Funnily enough, they don't have set_time_limit() listed, which I KNOW from experience you can't change in safe mode.

[csn]

Originally posted by toma42
Fact: If you want clean, easy to edit and maintain code, turn magic_quotes_gpc on and turn magic_quotes off.

No, and your code will sure stink on servers where it's disabled. It only adds a few lines of code, so the cleanliness, editablility, and maintainability gains would be very trivial. Besides, many of the PHP developers wish they'd never introduced it and even talk about removing it in the future. And what is "magic_quotes"? magic_quotes_runtime? Even worse to enable and rely on.

[[deleted]]

There's a very simple reason why magic_quotes serves little purpose at all and why you should therefore just turn it off completely:

You only need the escaped-quotes etc when you use the string in a place where the content of the string can be mistaken for syntax. And that only happens when you use the string in a query or in some cases when you write data to a file.

If you don't need/want the slashes you must run stripslashes() to get rid of them.

If you compare the number of times that you need the escaped version to the number of times that you need the non-escaped version you'll find that you need the non-escaped version many, many times more.

So if you have magic_quotes on, you'll have to use stripslashes() all over the place, but if you have magic_quotes off then you'll only have to run addslashes() in a few places where you are about to write data into a query etc.

To return to the orginial question;

create a new function called 'myaddslashes()' or something like that, and make it look like:

function myaddslashes($psString)
{
if (USE_ADDSLASHES)
{
return addslashes($psString);
}
else
{
return $psString;
}
}

Now you can use that function instead of addslashes() and you can switch the whole addslashes thing on or off by setting the value of the constant USE_ADDSLASHES to TRUE or FALSE, and you can do that once for the whole script based on the check you posted earlier.

[toma42]

Vincent, I think the conversation was about magic_quotes_gpc and not magic_quotes.

I completly agree with you about magic_quotes but I find setting magic_quotes_gpc on makes my coding much, much easier. Any data I get from the client is either:

1. a session cookie - md5 that never has special chars
2. form data which is only used to populate a database table
3. form or post data to select a record. This is always a number so stripslashes is not necessary for it.

If the user wants to try to hack a page and change a number to a string like
?some_key=1 to ?some_key=1'ab (not verbatim, just a poor exampe), the sql would end up as

select * from table where some_key = 1\'ab;
and the query would fail.

magic_quotes_gpc is my friend 🙂

[[deleted]]

"Vincent, I think the conversation was about magic_quotes_gpc and not magic_quotes. "

There are only two, magic_quotes_runtime and magic_quotes_gpc.

Runtime escapes everything entering PHP including databases, gpc only escapes data from get/post/cookies.

GPC is turned of for performance reasons that are in line with what I said earlier: you "don't need it" more than you "do need it" and every time you don't need it, PHP has wasted some of your precious CPU cycles.

This is ofcourse a trivial point for small or private websites, but when things become a little more popular you'll soon notice the difference.

"select * from table where some_key = 1\'ab;
and the query would fail. "

Just like it would if you manually used addslashes().

I understand your argument, it's easier to just enable magic-quotes and forget all about addslashes().
There's an added bonus of not having to worry about forgetting addslashes() in some places, but that can be explained both as 'a safety measure' and as 'a lazy programmer' 🙂

In the end, your script should handle the data correctly, not matter what the settings for magic_quotes_xxx are.

The current default is to disable it so I think it's better to write your script so that it works with magic_quotes_gpc disabled.

The best solution I think is to do what I suggested; use a custom addslashes function. If magic_quotes_gpc is already enabled the overhead is minimal, and you can make your script auto-switch when required.

[toma42]

This is ofcourse a trivial point for small or private websites, but when things become a little more popular you'll soon notice the difference.

db.etree.org got 9M hits in Apr. and 10M in Mar. but keeps on ticking. I'll remain a big fan of magic_quotes_gpc myself 🙂

[Sxooter]

Originally posted by toma42
>> This is ofcourse a trivial point for small or private websites, but when things become a little more popular you'll soon notice the difference.

db.etree.org got 9M hits in Apr. and 10M in Mar. but keeps on ticking. I'll remain a big fan of magic_quotes_gpc myself 🙂

Yea, I'm willing to bet a poorly formed SQL query is about 1,000,000 times as big an issue to performance as magic_quotes_gpc is.

We use it on our intranet box, and the performance loss, if any, is absolutely lost in the noise of all the other things that are getting done in the server.

[[deleted]]

uff.... did everybody just switch off their brains today?

Hits are not important, only pageviews.
Wait till you get to 150k pageviews an hour, then you'll see what I mean.

And the fact that something else is slowing you down more is no argument for not optimizing the speed of something else.

But I see this is getting down to a simple "I like it so I'll use it anyway" thing, so I'm moving on to the next subject.

[Sxooter]

Originally posted by vincente
uff.... did everybody just switch off their brains today?

Hits are not important, only pageviews.
Wait till you get to 150k pageviews an hour, then you'll see what I mean.

And the fact that something else is slowing you down more is no argument for not optimizing the speed of something else.

But I see this is getting down to a simple "I like it so I'll use it anyway" thing, so I'm moving on to the next subject.

Vincente, have you actually benchmarked the difference? It's virtually unmeasurable. sorry, we usually agree, but now I think you're being pedantic. Everything about development is a trade off. If it wasn't we'd be coding assembly for everything, since that's ALWAYS the fastest.

My point is that the difference here is likely significantly less than the difference between persistant and non-persistant connects to a database. If your code takes 50 ms to run, and magic_quotes_gpc takes 5 us, then why WOULD you worry about the cost. I'm willing to bet that calling addslashes once is likely more expensive than having magic_quotes_gpc on, and at that point, YOU would lose on the performance argument, since at least one thing in every database page I access has to be addslashed. Keep in mind, magic_quote_gpc is running C code in apache space, and is VERY fast, like most things about the PHP interpretor.

I've got some free time and an idle server, I think I'll go test it...

[Sxooter]

benchmarks!

OK, here's a super simple brain dead benchmark:

with magic_quotes_gpc on, I'm running this file:

print ($var);

with magic_quotes_gpc off, I'm running this equivalent file:

print addslashes($var);

I call it like this:

ab -n 100 -c 5 http://myserver/test/test.html?var=stanley[/url]'

The \' is the escape for the shell, so it's actually running:

ab -n 100 -c 5 [url]http://css119.ihs.com/test/test.html?var=stanley[/url]'

for this test.

With magic_quotes_gpc off;

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.8 1 11
Processing: 9 21 11.9 21 98
Waiting: 0 20 12.4 20 98
Total: 9 22 12.6 22 106

Percentage of the requests served within a certain time (ms)
50% 22
66% 23
75% 24
80% 24
90% 28
95% 41
98% 60
99% 69
100% 106 (last request)

with magic quotes on:

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 2.2 0 11
Processing: 9 20 18.7 17 120
Waiting: 1 19 18.9 16 119
Total: 9 21 18.8 18 120

Percentage of the requests served within a certain time (ms)
50% 18
66% 20
75% 21
80% 22
90% 29
95% 48
98% 88
99% 114
100% 120 (last request)

Note that there was more variability in one run to the next of any one of these than there is here, I picked two responses that were about in the middle.

I tried the same basic test with 5 variables, and got the same results, the differences are negligable.

[csn]

While we're talking about performance, I guess quite a few people downgraded back to PHP 4.2 after they found PHP 4.3 to be considerably slower. Rasmus Lerdorf posted several benchmarks on the dev list - looked like a lot of it was due to additional file calls like stat. I think they're working on improving these issues in 4.3.1 and 4.3.2.

[Sxooter]

I had three or four scripts that when I went from PHP 3.x to 4.x I had to rewrite. The old versions pretty much read in a whole file, parsed it line by line, and the spit it back out. These were huge files, 10 to 100 megs in size. With 4 I ran out of memory, got horrible performance when I raised max memory, and had to make it operate on one line at a time (which I was doing before, but they were all in memory at the same time before.)

PHP 3 was way faster at creating big memory structures and tossing them around, but at most stuff it was way slower.

[csn]

I tried the same thing, with similar results. I gave up and switched to gawk for processing and SELECT FROM FILE / COPY FROM for inserting.