Avoiding htmlspecialchars()

[MarkDHamill]

EPV flags the use of htmlspecialchars() in my Smartfeed extension as an error.

Error: Using htmlspecialchars on line 974 in /controller/feed.php

Is there a workaround? I think in the past the extension review team gave it a waiver. Since I am outputting XML in my extension, it's kind of hard not to use. Example:

Code: Select all

						$link = htmlspecialchars($board_url . 'ucp.' . $this->phpEx . '?i=pm&mode=view&f=0&p=' . $row['msg_id']);

[Paul]

That epv gives an message doesn't mean it will get denied. It will just warn us that we need to look at something and make a decision based on that.

[AbaddonOrmuz]

You could use the wrapper utf8_htmlspecialchars() to fix that warning.

https://github.com/phpbb/phpbb/blob/3.2 ... 1344-L1350

[MarkDHamill]

You could use the wrapper utf8_htmlspecialchars() to fix that warning.

https://github.com/phpbb/phpbb/blob/3.2 ... 1344-L1350

Thanks. This looks like a reasonable solution. It still gives one error in the function, but that's an improvement on many.

[Paul]

No, please don't and just ignore the epv warning. It won't be denied for it.

[mrgoldy]

Out of curiousity, what needs to be escaped in the URL in the first place?
There is the base domain name (with potential subfolders), okay, but they should already be valid.
Then you have the regular link and add a message id, which sounds like it is an integer.

[MarkDHamill]

Mostly it's URLs where the & must be change to &amp; for key/value pairs. When the feed is validated, it won't pass validation unless these are changed. Much of the content is placed inside of CDATA sections which gives an escape from the rules. The feed title also needs entities replaced.

[3Di]

Code: Select all

$link = $board_url . 'ucp.' . $this->phpEx . '?i=pm&mode=view&f=0&p=' . $row['msg_id'];
$link = htmlentities($link , ENT_QUOTES, 'UTF-8');

[MarkDHamill]

I assume this does not trigger EPV errors.

[3Di]

You can try, if it does just ignore those errors as Paul said. EPV can be used online to check your default branch, did you know?
I think htmlentities() is the right function to be used here, for your use case.

[MarkDHamill]

I have downloaded EPV and checked it locally. I haven't tried it with this change. It would seem strange if it were allowed and htmlspecialchars were not, since I don't see much difference between them.

[3Di]

I don't see much difference between them.

I honestly do.

htmlentities — Convert all applicable characters to HTML entities

htmlspecialchars — Convert special characters to HTML entities

Performed translations

Character Replacement
& (ampersand) &
" (double quote) ", unless ENT_NOQUOTES is set
' (single quote) ' (for ENT_HTML401) or ' (for ENT_XML1, ENT_XHTML or ENT_HTML5), but only when ENT_QUOTES is set
< (less than) &lt;
> (greater than) &gt;

I have downloaded EPV and checked it locally. I haven't tried it with this change.

Sorry but I don't see a reason to be arguing about something if it hasn't been tested first.

[MarkDHamill]

I wasn't arguing, I just didn't have a chance to test it out. htmlentities() does not trigger an EPV error and doesn't appear on initial testing to cause any issues with feed validation. Presumably htmlspecialchars() was flagged by EPV for a reason. Maybe htmlentities() should have been too. Not sure what the criteria is for being included as a flag by EPV.

[3Di]

I was meant to say "discuss" which according to my dictionary means the same thing, in the present context, as per
"why discuss some thing not yet tried?" Sure thing I am not a native speaker as you know.



Anyway, the EPV questions are for someone else to answer.

[Paul]

I assume this does not trigger EPV errors.

Like said before, it is not directly a bad thing if epv triggers something. You should just keep using htmlspecialchars if that does what you require.

The reason htmlspecialchars is checked is that you don't want have it called on that from the request class, as htmlspecialchars is already called in there. Any other usage of htmlspecialchars are fine.