ID: 12668
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: PCRE related
Operating System: FreeBSD 4.0
PHP Version: 4.0.6
New Comment:
I use the phplib template functions and apparently that library uses
the preg_replace routines as well. Whenever I try to put slash-quote
data through this template library it gets stipslashes it seems.
The problem boils down to:
preg_replace("/key/", '\' \\\' \\\\\'', "replacekeyvalue");
which should yield:
replace' \' \\'value
but yields
replace' \' \'value
This used to work properly in 4.0.4, but now it seems I have to
preparse user input, replace \' and \\ with something else, run
preg_replace and repatch the \' and \\ values. This is unworkable!
I'd vote for a configuration variable to fix this. Something in line
with magic_quotes_gpc and magic_quotes_sybase. Perhaps
magic_quotes_pcre?
Previous Comments:
------------------------------------------------------------------------
[2001-08-31 11:12:50] [EMAIL PROTECTED]
I could change it so that only " and \ are slashed. From what I
remember about some of the complaints before addslashes behavior was
implemented, people had security concerns about using some external
vars as parts of eval strings. If the vars contained some quotes, some
unexpected or dangerous code could be evaluated..
------------------------------------------------------------------------
[2001-08-09 14:07:14] [EMAIL PROTECTED]
Ah - I see - so what I'm seeing is actually a symptom of the basic
issue that addslashes() is not a perfect reciprocal to putting
addslashes-affected characters inside a string - i.e.:
<?php
// double-quoted strings
echo "\""; // produces "
echo "\\"; // produces \
// but
echo "\'"; // produces \'
// single-quoted strings
echo '\''; // produces '
echo '\\'; // produces \
// but
echo '\"'; // produces \"
?>
whereas in mysql:
select "\""; # produces "
select "\\"; # produces \
select "\'"; # produces '
and perl is yet again different (with strings in single-quotes
anyway):
print "\""; # produces "
print "\\"; # produces \
print "\'"; # produces '
print '\''; # produces '
print '\\'; # produces \\
print '\"'; # produces "
I suppose backward compatibility would prevent this core behavior from
being changed at this stage - it's just kinda screwy that both
single-quoting and double-quoting of strings is a bit of a compromise
in terms of slashed characters.
Perhaps instead of sending preg_replace carry-forward values through
the entire addslashes routine, only " and \ could be returned as
slashed, and users could stick with using double-quotes for strings
within the (eval'd) replace string... that would prevent people from
having to use a hack get it to work as expected.
Thanks,
Chuck
------------------------------------------------------------------------
[2001-08-09 09:19:18] [EMAIL PROTECTED]
of course I meant addslashes()
------------------------------------------------------------------------
[2001-08-09 09:18:47] [EMAIL PROTECTED]
how about creating either two different functions, or another
attribute to preg_replace, that you can set true/false to run
that add_slashes or not?
------------------------------------------------------------------------
[2001-08-09 09:03:31] [EMAIL PROTECTED]
This is because preg_replace() runs addslashes() internally on the
captured subpatterns before substrituting them into the replacement
string. It didn't used to but a few people complained that it was
really hard to pass $n to a function because of single and double-quote
conflicts. To be frank, I'm not sure how to solve this problem
adequately, one group of people want the addslashes() run, the other
one doesn't.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/12668
--
Edit this bug report at http://bugs.php.net/?id=12668&edit=1
