TYPO3 Core

Hello Florian,

did you check the source code with the element browser or did you open the take a look at the source code directly? Oftentimes the element browser tries to help by replacing such characters with human readables which then leads to misinterpretation of what is really going on.

In any case, ascii should not be used (see #90044) for details.

Why did you want to use the "ascii" option in the first place?

Regards
Tizian

Hi Tizian,

To answer your question, I use the "ascii" option because it's the default option and it doesn't need JS to work and whenever I develop a site I tried to remove all unnecessary code.

But I looked the issue https://forge.typo3.org/issues/90044 and agree with this so I won't use this option anymore.

Thx for your help
Florian

My findings. Due to the introduction of htmlSanitize, the ascii encoded string gets reverted in $cObj->parseFunc() at the very end of the function (see lines 3412 - 3414). If I disable this functionality, then config.spamProtectEmailAddresses = ascii works again.

The original report (2 years ago) is not related to typo3/html-sanitizer at all, since it did not exist at that time.

ASCII-entity-encoding is not considered a protection - any browser is going to resolve those &#...; literals to their corresponding plain text representation. Other aspects concerning spamProtectEmailAddress have been tackled in #94904

In order to separate spamProtectEmailAddress from sanitizing user submitted content, typo3/html-sanitizer would have to be invoked early in parseFunc, after that internal substitutions like spamProtectEmailAddress would happen. I've tried that, however parseFunc and HtmlParser is a big mess (sorry, but it's like that) since it's blindly HTML encoding & decoding data - see abandoned change-set https://review.typo3.org/c/Packages/TYPO3.CMS/+/70716

From my POV this very ticket can be closed...