Duplicate use of htmlspecialchars() in rss.php

[plathine]

The function htmlspecialchars() is used in config.save.php to convert special characters to HTML entities. This function is also called in rss.php and the config values will be converted again.
Due to this I get an "&" for a simple "&" ("&" -> "&" -> &") in the RSS feed.

[matteo]

Hi,

The function htmlspecialchars() is used in config.save.php to convert special characters to HTML entities. This function is also called in rss.php and the config values will be converted again.
Due to this I get an "&" for a simple "&" ("&" -> "&" -> &") in the RSS feed.

That's correct 'cause the record content needs to be HTML safe and the XML representing the RSS feed needs to be safe against XML entities.
Could you explain us a scenario in which this should be an issue?

Thanks in advance,
Matteo

[plathine]

I'm using an ampersand in my FAQ title.
I think the values (e.g. $PMF_CONF["title"]) of the config.php should only be converted on reading and not on saving.

[matteo]

Hi,

I'm using an ampersand in my FAQ title.
I think the values (e.g. $PMF_CONF["title"]) of the config.php should only be converted on reading and not on saving.

ok, I'll take a look at the code in these days to confirm and fix this bug.
I'd read too fast and I've read config.save.php as record.save.php: that's the reason of my previous post.

Thanks for bringing the issue to our attention,
Matteo

[matteo]

Hi,
the bug has been fixed both in 1.6.7-dev and 2.0.0-beta-dev.

Ciao,
Matteo

[plathine]

Great reponse time!

Thanks a lot!

[plathine]

Well, I took a look at the CVS snapshot. That's fine so far, but I think you must ensure that every reading access on $PMF_CONF[] values (if necessary) is enclosed in a htmlspecialchars() call.

Another approach could be the following: Use a better (you own) htmlspecialchars() implementation in the rss.php files which takes care for existing HTML entities and does not convert them twice (like "&" to "&").

[matteo]

Hi,
your second sentence is a way of doing the job: to tell the truth yesterday night that was the first fix I did. Later I decided to be more data oriented, that is to say: to preserve data and to give the viewer the responsability of doing the required encoding. My next step will be to check that whenever $PMF_CONF will be printed out, there the right encoding will take place i.e.: XML safe, HTML safe, JS safe, string safe. That is to say: I'm sure the bug is fixed and RSS feeds will work as required (that's the reason why I posted here the progress as a feedback for you) but the task is not closed yet 'cause it should be possible that new minor issues have been introduced .

Ciao,
Matteo

PS: if you have any patch for solving issues you can propose them by email them to one of the Dev Team Member (in this case, matteo@phpmyfaq.de). We'll look at each of them and eventually use them for a straight commit into CVS.

[matteo]

Hi,
I've just closed the task of reviewing any encoding issue about $PMF_CONF both in 1.6.7-dev and 2.0.0-beta-dev: I've done several tests for the two branches but any other test or feedback will be appreciated.

Ciao,
Matteo