Bug #5256

htmlspecialchars() applied inconsistently and of little use

Added by Karsten Dambekalns over 5 years ago. Updated almost 5 years ago.

Status:Resolved Start date:2009-11-06
Priority:Should have Due date:
Assigned To:Karsten Dambekalns % Done:

100%
Category:Core
Target version:-
Has patch: Affected Flow version:

Description

Observations:
  • When a value assigned to Fluid is put into a template, it remains untouched (i.e. angle brackets stay as they are and so forth).
  • When a value is passed through a ViewHelper, it is by default run through HtmlSpecialCharsPostProcessor
    • This can be disabled only by using a setting that is not part of the public API and subject to change

So, the processing of values is not consistent. But there is more:

I would expect to be able to use the values assigned as-is, unprocessed. An example are the templates used in the FLOW3 kickstarter, where angle brackets are completely legal and must not be run through htmlspecialchars().

Therefore I propose the following:
  • remove the HtmlSpecialCharsPostProcessor (and possible the whole ObjectAccessorPostProcessorInterface and related code)
  • add a ViewHelper that can be used with inline syntax to apply escaping for HTML (e.g. like {value->f:escapeForHtml})

That way the user can decide how to make use of the values.

Related issues

related to TYPO3.Fluid - Feature #5257: Allow generic post-processing of template content Resolved 2009-11-06

History

#1 Updated by Bastian Waidelich over 5 years ago

  • Category set to Core
As a reminder:
  1. Object accessor nodes (e.g. {customer.name})should be processed by the ObjectAccessorPostProcessor too of course. If that's not the case, that's a bug
  2. The original plan was to make post processors configurable per template & package. But IMHO we should keep the HtmlSpecialCharsPostProcessor by default - at least for HTML templates. Otherwise there would be no easy way to protect yourself from XSS attacks

#2 Updated by Karsten Dambekalns over 5 years ago

Bastian Waidelich wrote:

  1. Object accessor nodes (e.g. {customer.name})should be processed by the ObjectAccessorPostProcessor too of course. If that's not the case, that's a bug

That was indeed a bug and has been fixed by Sebastian in r3461.

#3 Updated by Karsten Dambekalns over 5 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

The bug contained here has been fixed, the remaining stuff has it's own issue.

Also available in: Atom PDF