Mystery

[Anon]

I know that for escaping backslashes when using " or ' in strings I must use the stripslashes().

But some times when I pass my variables to an HTML hidden tag and the string is containing ' (eg. Shakespeare's) parts of the string is not hiding, it gets printed on the screen.

Anybody that have a good grasp on the subject and can explain?

regards Thomas

[marcel]

here is no mystery 🙂)

if you want to pass "Shakespeare's"
the $var will be "Shakespeare\'"

so, you you have something like:
< INPUT VALUE="Shakespeare\'" NAME...
after second SUBMIT the $var will be
"Shakespeare\\'"
so you have to call stripSlashes() twice...
(the best way is to call stripSlashes()
in both pages - the last and the page with hidden input)

in anycase, you should call stripSlashes only whe magic_quotes_gpc are ON (depends about php.ini)

so the code should look like:
if (get_magic_quotes_gpc())
$var = stripSlashes($var);

[Anon]

You have to convert ', " and others special characters in your text into HTML entities (&quot; etc.)
use the htmlspecialchars (string)

[van__]

Look at the string and look at how you write your tags.

if you are using a single quote (') to contain your HTML tag attributes, then yes... "shakespeare's" will end the tag attribute right then and there.

In my own productions I have some of these guidelines that I enforce that are directly related to your problem:

1) PHPs' Magic Quotes will always be turned off as a default.

Why?

This is because I don't trust external processes like that. I opted to write my own version of magic quotes that automatically addscslashes but leaves it to me to "unbless" the data, this is far more versatile, since I have complete control over what characters get slashed and which ones don't. Additionally, it will refuse to set data that contains things such as a backtick (`) thereby further securing my code. Plus it will never try to guess when it should be unslashing. If text needs to be unslashed. I just call an "unbless" and those fields are stripped of slashes at that time.

2) ALL HTML tag attribute that are string types will be double quoted (") and all intiger type attributes (ie "height=20") will not be quoted at all.

Why?

This is because a double quote is very rare in user input and if displayed in a text input value attribute WILL blow your tag.
But, it is easy to just quote out your double quotes before printing to the page if you will be treating a text input as a text area.

The only area that a user would commonly enter in a double quote is in a &lt;textarea&gt; that is conveniently contained between element tags rather than holding the text as a value attribute, this was made that way as to allow for complex CDATA assignments, since we never know what will be typed in and wouldn't want to blow the tag and we wont bother to regex that but rather just cslash it and throw it in a TEXT type field in the database.

3) User input fields will be pattern matched for any offending characters and incorrect attributes where ever applicable.

Why?

Since nouns such as company names such as "lil' Diner" may contain a single quote but will never contain a double quote,

we can safely use a common text input and pattern match for ^{[a-z0-9\'-&\s@]{1,}$} to detect any character matches NOT in the regex and automatically prompt the user for correct input while not displaying the dangerous input we recieved (and thus, not have a broken tag on our page).

Just these 3 practices alone make a big difference in ease of production.
Because if you think about it, proper data handling will safeguard your tags from ever being broken as well as insuring that the data captured atleast matches an expression that best represents the type of information we are collecting.