Jak rozwaliłem Trzecią Zaufaną Stronę – odc. 1 – Formularz

„Że blog na WordPressie – bułka z masłem!” – pomyślałem jako przyszły admin Zaufanej Trzeciej Strony. Jednakże tysiące linijek kodu w PHP szybko zweryfikowały moje umiejętności i już wiem, że tak prosto z obsługą WP jednak nie jest. W serii „Jak rozwaliłem…” (oby jednoodcinkowej) będę opisywał moje błędy popełnione na produkcyjnej Zaufanej, które mogły poważnie wpłynąć na dostępność strony lub, jak w tym wypadku, na kontakt z Adamem Hantele.

W Zaufanej wierzymy, że liczy się transparentność, a Czytelnicy zasługują na wyjaśnienia. Za to ci bardziej techniczni Odwiedzający dodatkowo będą mogli się ze mnie pośmiać (albo zweryfikować konfiguracje swoich instancji WordPressa 😜).

Zarys teoretyczny (bez wyprowadzeń wzorów)

Usterka dotyczyła formularza kontaktowego Zaufanej Trzeciej Strony. Wszystkie zgłoszenia między 21 grudnia 2023 a 9 marca 2024 były przyjmowane przez nasz system, ale nie były przekazywane dalej na skrzynkę mailową Adama. A że nikt do systemu (tak naprawdę zakładki „Zgłoszenia”) nie zaglądał, formularze pozostawały bez odpowiedzi. Wszystko to zaczęło się od…

Migracja

…wielkiej migracji między starym a nowym serwerem Zaufanej. Wtedy też zauważyłem, że stara instancja wysyła maile przez lokalnie zainstalowanego Postfixa. To rozwiązanie mnie średnio zadowalało, gdyż:

1. IP serwera dedykowanego musiało być publicznie dostępne w DNS-ach, a przecież nie po to Cloudflare chroni nasz adres, żebyśmy jednym rekordem go ujawniali.
2. Gdyby z jakiegoś powodu nasz adres IP trafił na listę abuse, moglibyśmy mieć problemy z doręczalnością poczty.
3. Rzeczy takie jak poczta wolę outsourcować profesjonalistom – nie muszę się przez to obawiać ewentualnych dziur w pakietach Postfixa oraz zastanawiać, czy automatyczna aktualizacja paczki już się uruchomiła, czy może dopiero ruszy za chwilę.

Zarządziłem więc zmianę konfiguracji poczty i od grudnia 2023 roku za wysyłanie powiadomień z WordPressa Zaufanej odpowiada usługa AWS Simple Email Service.

Bolączka WP: pluginoza

Wbrew pozorom „goły” WordPress potrafi niewiele: nie ma żadnych ustawień dotyczących SMTP (można sobie je łaskawie nadpisać w plikach motywu w functions.php…), brakuje tagów OpenGraph do generowania ładnych embedów na Twitterach czy innych Discordach, a podgląd obrazków w formie przesuwalnej galerii nie istnieje (opcja „Rozwiń po kliknięciu” nie jest wystarczająca). Każdą z tych drobnych rzeczy należy tegować wtyczką bądź wtyczkami, a jedna jest gorsza od drugiej.

Mam wrażenie, że autorzy wtyczek walczą nawet nie o pieniądze autorów blogów, co po prostu z samymi autorami, aby ich życie było jeszcze smutniejsze niż dotychczas…

Instalujesz naszą wtyczkę, a chcesz jeszcze pięć innych? A może pokazać ci zresetowaną konfigurację w zakładce ustawień, mimo że de facto w bazie danych jest inaczej? A logi błędów? Paaaanie, zapłać pan albo kliknij super ukrytą zakładkę, to może wtedy.

Wtyczka Easy WP SMTP (oprócz utrudniania dostępu do logów, o czym za chwilę) w zasadzie działa OK. Przy jej początkowej konfiguracji zaznaczyłem kilka opcji, które przypadkiem naprawiały problem – nadpisywanie nagłówków FROM.

Takie ustawienia, choć prawidłowe i bezpieczne, przeszkadzały w łatwym odpowiadaniu na Wasze zgłoszenia. Przed migracją, gdy Adam otrzymywał kopię zgłoszenia na swojego maila, to adres do odpowiedzi znajdował się zawsze w polu FROM. W związku z tym, jeżeli pole FROM nie jest nadpisywane przez wtyczkę zgłoszeń (czyli wynosi np. [email protected]), to nie wiadomo, kto wysłał zgłoszenie i trzeba sięgać do logów we wtyczce.

Problem w tym, że przed migracją myk z ustawianiem fałszywego pola FROM by przeszedł – w końcu to my operowaliśmy Postfixem, więc można było tam ustawić prawie wszystko. Sytuacja się zmieniła, kiedy zaczęliśmy korzystać z usług zewnętrznych. SES (zresztą słusznie) wymaga weryfikacji domen, które mają się znajdować w polu FROM. Na tym właśnie poległem.

O swoim błędzie dowiedziałem się przypadkiem, kiedy w ramach akcji usuwania nadmiernej liczby wtyczek z Zaufanej zacząłem głębiej zaglądać w różne opcje. Easy WP SMTP ma kilka zakładek. W której z tych poniżej znajdują się logi?

Treść błędów wyglądała następująco:

Mailer: Other SMTP
SMTP Error: data not accepted.SMTP server error: DATA END command failed Detail: Message rejected: Email address is not verified. The following identities failed the check in region EU-NORTH-1: „[email]” , [email]
SMTP code: 554

Caller
Plugin: Ninja Forms
/var/www/html/wp-content/plugins/ninja-forms/includes/Actions/Email.php (line: 98)

Jak widać, SES nie pozwala na niezweryfikowane adresy w polu FROM. Tylko co mogło nam modyfikować to pole? Po chwili główkowania przypomniałem sobie feralną migrację i ustawianie SMTP. Ale zaraz, przecież formularz kontaktowy testowałem i wszystko działało! Kłopot w tym, że e-mailem testowym był adres, który już w AWS SES wcześniej zweryfikowałem. Widocznie wymyślenie fejkowego adresu do podania w testach formularza było dla mnie za trudne…

Stop! Młotu czas!

W tej samej zakładce „Debug events” znajduje się opcja, która powinna nas przed tym wszystkim ochronić. Informacja o błędzie wysyłana na maila administratora – tego nam było trzeba! Opcja jest nie dość, że domyślnie włączona, to jeszcze nie można jej wyłączyć. Hurra?

Niestety nie hurra, Pan Hantle żadnego maila o błędzie nie dostał, ale za to bezużyteczne statystyki tygodniowe wpadały cały czas.

Tory były złe i szyny, a podwozie to w ogóle

Ostatecznie wszystko udało się naprawić. Z panelu SES-a usunąłem swój adres mailowy jako zweryfikowany, gdyby znowu mi się zachciało robić testy ze swoimi danymi. Pola FROM ustawiłem na adresy Zaufanej, a pola REPLY-TO na adresy e-mail zgłaszających. Tak, pola nadawcy maila oraz ten wskazujący, do kogo wysłać odpowiedź, mogą być różne, ale to pewnie już wiedzieliście.

Mam nadzieję, że nie będę musiał pisać kolejnego Post Mortem. Chociaż Zaufana teraz to odrobinkę plac budowy – pewnie nowy wygląd już zauważyliście (jest cudowny), to sporo się dzieje „pod maską”. Myślę jednak, że z moim szczęściem już wkrótce przeczytacie kolejny odcinek „Jak rozwaliłem…”. Przynajmniej będzie zapewniony „kątęt” do czytania i analizy, tak jak Cloudflare słynący ze swojej transparentności w swoich write-upach.

A propos, dzień po mojej wpadce Cloudflare zdegradował wszystkich swoich płacących klientów do planu darmowego i walczył z tym kilkanaście godzin. Przypadek? Pewnie tak.