wwt3_encryption dla TYPO3

Dlaczego ukrywanie adresów e-mail nadal jest obowiązkowe dla każdej publicznej strony

Każda strona firmowa, każda strona uczelni i każdy portal urzędowy publikuje adresy e-mail: osoby kontaktowe w stopce, osoby kontaktowe w zespołach, kontakty prasowe w newsroomach, dział prawny w polityce prywatności. Bez ochrony boty-harvester zbierają te adresy w ciągu kilku dni po publikacji i sprzedają je spamerom. wwt3_encryption to klasyczne rozszerzenie TYPO3 dla tego problemu i szyfruje adresy e-mail po stronie serwera, dzięki czemu boty przy parsowaniu HTML widzą tylko bezużyteczny kod, podczas gdy prawdziwi użytkownicy mogą kliknąć na poprawny adres. Rozszerzenie kierowane jest do operatorów, którzy z powodów prawnych muszą prominentnie pokazywać dane kontaktowe, ale nie chcą godzić się na wynikający z tego potop spamu.

Typowe scenariusze zastosowania

Kancelaria prawnicza z 60 partnerami i associate’ami publikuje wszystkie profile prawników wraz z bezpośrednimi adresami e-mail, bo kodeks etyki zawodowej wymaga osiągalnych danych kontaktowych. Bez ukrywania wszystkie 60 adresów w ciągu tygodni otrzymuje maile phishingowe, reklamy i częściowo ukierunkowane ataki. wwt3_encryption renderuje adresy tak, że kod źródłowy nie zawiera czytelnego stringu z @, podczas gdy przeglądarka u użytkownika wyświetla poprawny adres linku mailto.

Drugim scenariuszem jest uczelnia, która pielęgnuje strony wydziałów z kontaktami katedr. Każda katedra ma stronę internetową z danymi telefonicznymi i e-mailowymi, które są pielęgnowane redakcyjnie przez zarządzanie treścią TYPO3. Redaktorzy wpisują adresy jako normalny tekst w elementy RichText lub pola kontaktowe, bez konieczności zajmowania się ukrywaniem. wwt3_encryption automatycznie wpina się w proces renderowania i chroni wszystkie linki mailto bez dodatkowej pracy redakcyjnej.

Trzecim przypadkiem są administracje publiczne ze stopką, formularzami kontaktowymi i listami wydziałów merytorycznych. Wymaganie jest tu często jeszcze surowsze, bo istnieje obowiązek dostępności cyfrowej: chroniony adres musi być poprawnie odczytywany przez screen-readery, a kliknięcie musi otwierać klienta pocztowego, dokładnie jak przy nieukrywanym adresie. Kombinacja dekodowania JavaScript i semantycznie czystych atrybutów href to jedyny sposób, aby spełnić oba wymagania.

Architektura techniczna: post-processing w renderowaniu TYPO3

wwt3_encryption wpina się w proces renderowania TYPO3, zazwyczaj przez hook Content-Post-Processor lub userfunc TypoScript. Po złożeniu wyjścia HTML przez Page-Renderer rozszerzenie przechodzi przez gotowy markup, znajduje wszystkie linki mailto i wszystkie proste adresy e-mail w tekście za pomocą regex i zastępuje je ukrytymi wariantami. Ukrywanie może odbywać się przez różne metody: kodowanie ROT13 celu linku z dekodowaniem JavaScript, kodowanie Base64, fragmentację znakową z pseudo-elementami CSS lub kombinację.

Zaletą wariantu post-processingowego jest to, że działa bez zmian w elementach treści czy szablonach. Redaktorzy pracują dalej ze zwykłymi linkami mailto w RichText, a rozszerzenie automatycznie przejmuje zabezpieczenie. Konfiguracja rozszerzenia odbywa się przez stałe TypoScript, które wybierają między różnymi metodami ukrywania i pozwalają definiować wyjątki dla określonych stron lub obszarów treści.

Częste problemy i rozwiązania

Pierwszym problemem jest dostępność cyfrowa. Czysto JavaScriptowe rozwiązania zawodzą u użytkowników z wyłączonym JavaScript, a niektóre screen-readery mają problemy z fragmentacją znaków opartą na CSS. Pragmatyczne podejście łączy łatwo łamalne ukrywanie kliencie z dodatkowym semantycznym aria-label na linku, dzięki czemu screen-readery poprawnie odczytują adres, podczas gdy harvester zawodzi na syntaktycznej odmienności. Absolutne bezpieczeństwo przy publicznie dostępnych adresach nie jest osiągalne, ale już umiarkowane przeszkody mierzalnie redukują obciążenie spamem.

Drugim problemem są warstwy cache’owania. Gdy ukrywanie post-processingowe jest wykonywane przed Page-Cache, cache dostarcza ukryte dane i wszystko działa. Jeśli jest za cache, każda cache’owana strona przy każdym zapytaniu jest ponownie przepuszczana przez post-processor, co znacząco obciąża wydajność. Prawidłowa kolejność w łańcuchu renderowania TypoScript jest zatem krytyczna i powinna być sprawdzana przy każdej większej zmianie zachowania cache’owania.

Trzeci temat dotyczy treści dynamicznych. Adresy e-mail, które są doładowywane przez AJAX lub pochodzą z zewnętrznych API, nie przechodzą przez renderer TYPO3 i tym samym nie przez wwt3_encryption. Takie miejsca muszą być chronione oddzielnie, albo przez dostarczanie przez samo API ukrytych wariantów, albo przez klienckie JavaScript, które obrabia doładowaną treść.

Migracja i kompatybilność wersji

wwt3_encryption ma jak wiele starszych rozszerzeń TYPO3 niespójną historię wersji: dla v9 i v10 istniały utrzymywane wydania, dla v11 i v12 istnieją forki społeczności, których aktywność jest różna. Kto migruje na TYPO3 v13, powinien przed upgrade sprawdzić, czy własny fork jeszcze działa, czy zmiana na alternatywną metodę ukrywania staje się konieczna.

Sam rdzeń TYPO3 przynosi proste ukrywanie e-maili, które jest aktywowane przez config.spamProtectEmailAddresses w TypoScript i stosuje ROT13 w rdzeniowym rendererze. Dla prostych konfiguracji ten wariant core wystarcza i czyni własne rozszerzenie zbędnym. Kto potrzebuje silniejszego lub bardziej elastycznego ukrywania, na przykład z kilkoma równoległymi metodami lub wyjątkami per element treści, sięga po rozszerzenie takie jak wwt3_encryption. Gosign ocenia w każdym pojedynczym przypadku, czy funkcja core wystarcza, czy dedykowane rozszerzenie ma sens, i w razie potrzeby wspiera też przebudowę na własną, smukłą implementację post-processingową, która dopasowuje się bezpośrednio do danego projektu.

Skuteczność każdego ukrywania e-maili spada z czasem, bo techniki harvesterów się rozwijają. ROT13 jest dziś uważany za prawie bezużyteczny przeciwko wyspecjalizowanym botom, podczas gdy fragmentacja znakowa z CSS lub trickami Unicode nadal buduje umiarkowane przeszkody. Naprawdę solidna obrona to zatem kombinacja: ukrywanie w wyjściu HTML, uzupełnione o dobry filtr spamowy po stronie odbiorcy i najlepiej opcję kontaktu przez formularz zamiast bezpośrednio publikowanego adresu. Kto musi spełnić wymagania prawne, nie uniknie publikacji, ale powinien zaoferować formularz kontaktowy jako podstawową drogę, a adres pokazywać tylko drugorzędnie.

Dla operatorów TYPO3 v13 zaleca się dodatkowo regularne sprawdzanie pipeline’u Content-Rendering pod kątem Breaking Changes w core. Niektóre punkty hooków, które były dostępne we wcześniejszych wersjach do post-processingu, zostały w v13 deprecated lub zastąpione przez zdarzenia PSR-14. Rozszerzenia, które nadal polegają na starych hookach, działają po upgrade technicznie, ale nie obrabiają już treści. Krótkie sprawdzenie wpisów logu po upgrade pokazuje takie ciche awarie wcześnie i zapobiega temu, aby przez tygodnie niezauważenie były dostarczane nieukryte adresy.