Bug #89910
closed
spamProtectEmailAddresses doesn't work as expected with value "ascii"
0%
Description
In the documentation, it's written that when you set :
config.spamProtectEmailAddresses = ascii
every character of the “mailto:” address will be translated to a Unicode HTML notation like this :
<a href="mailto:a@b.c">xxx(at)xxx.com</a>
But when I set this parameter, email links are not encrypted :
<a href="mailto:l.devedeux@terresinovia.fr">l.devedeux(at)terresinovia.fr</a>
If I set another value, for example :
config.spamProtectEmailAddresses = -2
it works as expected : encryption + JS.
Updated by Tizian Schmidlin over 4 years ago
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
Updated by Florian Rival over 4 years ago
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
Updated by Georg Ringer about 4 years ago
- Related to Feature #90044: Remove spamProtectEmailAddresses with option "ascii" added
Updated by Benni Mack over 2 years ago
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.
Updated by Oliver Hader over 2 years ago
- Related to Story #94904: Is spamProtectEmailAddresses still worth keeping around? added
Updated by Oliver Hader over 2 years ago
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...
Updated by Benni Mack about 2 years ago
- Status changed from New to Closed
Closing this issue, we removed ascii due to insufficient functionality in terms of spam protection https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-90044-ConfigspamProtectEmailAddressesWithOptionAsciiRemoved.html