Review all uses of htmlspecialchars and zen_db_output #270
Comments
drbyte
added
the
[Status] up-for-grabs / PR welcome
…issue zencart#270 and begin substituting foreach for while loops.
zen_output_string_protected($1) Issue zencart#270. No review done for htmlspecialchars that do not force protected mode by setting the fourth parameter to true. All other htmlspecialchars usage has not been reviewed.
|
Why does admin: zen_output_string_protected use htmlspecials($string, ENT_COMPAT, CHARSET, FALSE) and catalog side instead use htmlspecials($string, ENT_COMPAT, CHARSET, TRUE) (last factor being to only single encode on the admin and double encode on the store side?) Is this part of what has to be modified/corrected in order to simplify across the two systems? A majority of admin calls directly to htmlspecials seem to use TRUE like on the catalog side, but then calls to zen_output_string_protected on the admin side are not automatically "double-encoded". |
|
I dunno, but you can follow the "rules" that I documented here to make sure that you don't get double-encoding where you don't want it. FWIW, I've stopped using the |
|
I was thinking of that or similar as I was going through it and trying to see what "consistent use" existed for both sides as to why one is one way and the other not and what it would take to align the two... (Afterall it would be great if all/most functions were one type/style right? Rather than multiple examples of code that accomplishes the "same thing"?) Seems like the way to go would be the catalog side as that has been the more important side to address, so the question becomes what would it take on the admin side actually to not use the currently defined zen_output_string_protected and instead have it work like the catalog side? Of course thought this was going to be easier to fix/address than it turned into, but now just trying to see if there is a way to map it forward to use one or the other. |
…issue zencart#270 and begin substituting foreach for while loops.
zen_output_string_protected($1) Issue zencart#270. No review done for htmlspecialchars that do not force protected mode by setting the fourth parameter to true. All other htmlspecialchars usage has not been reviewed.
…ation of encoding (clearly use the default setting), this will help in future modifications to address issue zencart#270 to streamline the use of htmlspecialchars.
Expanding the data for zen_db_output uses on the admin side in preparation to 1) remove all usage of zen_db_output, 2) redefine zen_output_string_protected so that it functions on the admin side the same as on the store side. Requires substituting function into an equivalent standard function.
|
It seems like the only files left that still do zen_db_output are: admin/reviews.php |
drbyte
added
in progress
and removed
[Status] up-for-grabs / PR welcome
I'm pretty sure that all remaining references to
zen_db_output()should actually be usingzen_output_string_protected()for consistency.... and maybe then temporarily move
zen_db_output()to the compatibility functions file and redefine it to be a call tozen_output_string_protected(), for retirement in a future version.Further, I think a review of all direct calls to
htmlspecialchars()should be done to replace them withzen_output_string_protected()also ... unless there's a specific reason not to.Credits to @lat9 http://www.zen-cart.com/showthread.php?215798
The text was updated successfully, but these errors were encountered: