Closed (works as designed)
Project:
Drupal core
Version:
7.14
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Jun 2012 at 16:35 UTC
Updated:
17 Oct 2012 at 21:51 UTC
There are a few issues about special characters getting double encoded and it boils down to the check_plain allowing it by default in the htmlspecialchars. Setting the fourth parameter (double_encode) to FALSE will fix these issues. From http://us2.php.net/htmlspecialchars
When double_encode is turned off PHP will not encode existing html entities, the default is to convert everything.
.
Is there a reason the fourth parameter isn't set to FALSE?
Thanks
Comments
Comment #1
damien tournoud commentedIt's better to fix the cause then to add unpredictable workarounds. This
double_encodeis a hack we should keep as away from as possible.Comment #2
kamkejj commentedSetting htmlspecialchars 4th parameter in check_plain() isn't a hack. See http://us2.php.net/htmlspecialchars.
Run this:
Why is this the intended way to work.
Comment #3
damien tournoud commentedControlling the type of text you manipulate is critical, if you fail to properly know everywhere if a piece of text is HTML or plaintext, you expose yourself to all kind of security and non-security issues. The
double_encodeparameter is a hack that muddies the difference between HTML and plaintext. It is very much not welcome.Comment #4
ice5nake commented@Damien Tournoud, While you may be correct I think I have to disagree with your assessment. Can you explain or reference why having the double encode flag set to false would be a security problem?
I'd argue that once text has html entities in it it is no longer plaintext.
Why would you want to double encode something? The PHP docs do not mention a security implication with this flag as they do with some other flags.
Comment #5
ice5nake commentedI'd also argue that check_plain should be idempotent and with double encode set to false it would be.
Comment #6
damien tournoud commented@ice5nake: if your plain-text input is
&you *want* your HTML output to be&. For example, let's create a node called:The
$double_encodeparameters ofhtmlspecialchars()is not about idempotence, it's about black-magic. While I agree that an encoding scheme that is idempotent would be better, this is no solution.