• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
parse_smileys and HTML entities bug

#1
[eluser]dmorin[/eluser]
Please see http://ellislab.com/forums/viewthread/92415/ for previous discussion.

I store all user input in the database escaped using xss_clean and htmlentites. Then, when I echo out certain fields, I use the parse_smileys function to generate the image tags. The problem occurs when someone uses an htmlentity character directly before a closed parenthesis such as

Quote:(“TEST”)

which I then translate to

Quote:("TEST&quotWink

which the parse_smileys function then interprets the last two characters to be a wink.

It doesn’t appear that these forums are affected by this, so we have to conclude that they use a different parser. While some may argue that this is not a bug, I believe it is because fixing it requires changes to the parse_smileys core function.

#2
[eluser]Derek Allard[/eluser]
I would be one of those people who would argue that's not a bug. If you ran "Wink" through parse_smileys and didn't get a wink, then I'd think this was a bug.

#3
[eluser]dmorin[/eluser]
Not really sure what you mean Derek. Essentially, it seems you're saying that having ") in text being parsed as a smiley is the desired behavior of this helper since " needs to be translated to " in order to be on the page and this can't be done after parsing for smileys as the image tags would be converted.

If this is not a bug, can someone suggest an alternative to my approach that would result in smileys being parsed the same why they are in this forum?

#4
[eluser]Derek Allard[/eluser]
I'm not saying ") should be a smiley, but I am saying Wink should be a smiley. If you are storing it encoded, then that's what it sees.

#5
[eluser]dmorin[/eluser]
I agree with you. What I'm getting at is, for safety and valid html, any user input should be encoded before added to the html (I think most will agree with that). Since you can't encode text AFTER passing it through that function without ruining the img links, you must do it before. And passing in encoded text causes smileys in unintentional places.

Just so that everyone is on the same page, let's use an example. Say someone posts a comment:
Quote:Wink This is my comment ("just for fun")
How would you deal with this? What functions would you pass it through in what order to parse the smileys and echo it safely to the page? You can store it however you please.

If someone can come up with the right approach using the current parse_smileys function then I agree it's not a bug and I was just being an idiot.

#6
[eluser]dmorin[/eluser]
Can anyone come up to a solution for the previous post? It seems odd that it can't be done currently and yet it's not a bug...

#7
[eluser]sophistry[/eluser]
:-) 8-/ %-P in the referenced thread (first post here 8-)) http://ellislab.com/forums/viewthread/92415/ there is a test post that shows how this EE-based forum properly handles smileys in a case where the current smiley parser fails to meet "expected behaviour".

smiley like a wink Wink that doesn't have a space in front of it is turned into a smiley by the CI function but not the forums see... xWink

my suggestion was to add a space to the str_replace() function but dmorin pointed out it would then fail if the smiley were put as the first char of the string!

conclusion... EE forum uses a more advanced smiley parser and might be added to CI core to address entities problem.

WinkWinkWink

EDIT: you might name this bug the "ambiguously undelimited smiley parser bug"


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.