Page 1 of 1

can i use addslashes towrite

Posted: Tue Feb 24, 2004 7:04 am
by pelegk2
string's with (') for example to a data base using addslashes ?
so it will have
bal''bla

Posted: Tue Feb 24, 2004 8:15 am
by AVATAr
you have to.

Posted: Tue Feb 24, 2004 9:33 am
by pelegk2
but i dont see the slahes in the DB!

Posted: Tue Feb 24, 2004 11:20 am
by McGruff

Posted: Tue Feb 24, 2004 12:11 pm
by llanitedave
So, when would you call stripslashes()?

Posted: Tue Feb 24, 2004 12:14 pm
by AVATAr
before you display the data or you put it in a text box.

Posted: Tue Feb 24, 2004 2:16 pm
by llanitedave
That's what I had thought, and maybe I read wrong, but reading McGruff's link I read:
Never stripslashes!
That's the golden rule. You should never have to stripslashes. Ever.
Which doesn't make much sense to me.

Posted: Tue Feb 24, 2004 2:43 pm
by Draco_03
read all the document u ll understand why he say taht.,..you should stripslashes ONLY if magic quote is off

Posted: Tue Feb 24, 2004 2:56 pm
by ilovetoast
Alright, here's my explanation.

PHP has two directives, magic_quotes_runtime and magic_quotes_gpc, which affect the use of escaping backslashes in certain operations. The magic_quotes_gpc directive covers GPC operations (Get/Post/Cookie). The magic_quotes_runtime directive covers most functions that return values from databases or external files.

In olden times, these two directives were seen as a good thing, something to ease the work of the programmer. However, the wise have rightly come to the conclusion that magic quotes are not as good a thing as was once thought. Most new servers are now set with these directives set to FALSE, but many servers remain with the directives set to TRUE. Considering further that some developers code with the directives FALSE and some code with the directives TRUE, the situation can get even more complicated.

Basically, magic quotes are considered bad because they cause an uncontrollable modification to the data contained in a variable before your script has access to that data. This can cause a host of problems that include problems with matching SELECT queries and properly displaying information in the browser.

As an aside, on every machine you have control over from this day forwawrd, you should turn off both directives - permanently.

Consider this data as a string:
John's cat is dead.

In order to store this data into a database sucha s MySQL, the single quote (apostrophe) needs to be escaped with a backslash giving:
John''s cat is dead.

Both addslashes() and the magic_quotes_runtime directive can cause this. If the directive is true, the backslash is added automatically. If the directive is false, then addslashes must be used. Either one or the other must be used to store the data properly, but remember the backslash is not actually stored in the the db.

Problems occur when a coder writes in a magic_quotes_runtime=FALSE environ, and so uses addslashes() to give:
John''s cat is dead.
But then the coder deploys onto a magic_quotes_runtime=TRUE server causing the data to become:
John\\''s cat is dead.
Which when stored in the database is stored as
John''s cat is dead.

This could turn out OK if stripslashes() were used after retrieval. However, since the coder developed in a magic_quotes_runtime=FALSE environ there was no need for stripslashes(). So after retrieval the data is floating around in a script variable as:
John''s cat is dead.

As you can see, this turns into a big mess. All because of magic quotes and bad deployment practices.

The solution is two part. First and foremost is know thy runtime environment directives. If you can control them or at least specify them, then you can always turn off magic quotes.

The second part is just as important. You need to incorporate into your code a conditional that accounts for magic quotes. If there is ever a possibility to deploy onto a machine where magic quotes might be on (say if someone else uses your code) you have an obligation to help them out. That is where the use of addslashes() is conditioned on magic quotes being off.

For your use, if the magic quotes directives are correctly turned off in both your development and deployment environs then there is never any need to use stripslashes in this regard. Hence the golden rule of "Never stripslashes!"

peace

Posted: Tue Feb 24, 2004 3:21 pm
by Draco_03
EXACTLY...i couldn't of said better..
i m serious..i couldn't ..:)

Posted: Tue Feb 24, 2004 3:39 pm
by llanitedave
OK, one last time since I'm old and slow and need these things really drilled into me:

If I have a string $statement that reads:
Dave's "big bonus" was 25%!!
And I was to save that in the field 'statement1' of table 'table1', I'd first call $statement1 = addslashes(trim($statement1)).

If I was to put that field into another, say

Code: Select all

$sql = "UPDATE table2 SET table2.statement2 = table1.statement1";
I would have to addslashes() again for the transfer?
And if I were just going to display it on the page (assuming magic quotes are off) I would NOT use stripslashes()?

Posted: Tue Feb 24, 2004 3:48 pm
by Draco_03
The solution is two part. First and foremost is know thy runtime environment directives. If you can control them or at least specify them, then you can always turn off magic quotes.

The second part is just as important. You need to incorporate into your code a conditional that accounts for magic quotes. If there is ever a possibility to deploy onto a machine where magic quotes might be on (say if someone else uses your code) you have an obligation to help them out. That is where the use of addslashes() is conditioned on magic quotes being off.
And also the site Mcgruff suggested you had this function

Code: Select all

<?php

function myAddSlashes( $string ) {

  if (get_magic_quotes_gpc()==1) {
  
    return ( $string );
    
  } else {
  
    return ( addslashes ( $string ) );
    
  }
  
}

?>
$string = whatever you have..bob's car for exemple....