niedziałający formularz wypisu

Niedziałający formularz wypisu uniemożliwia realizację prawa odbiorcy do wycofania zgody, co rodzi ryzyko prawne.

Jak działa formularz wypisu w aplikacji internetowej

Formularz wypisu jest elementem interfejsu strony internetowej, który przekazuje do aplikacji żądanie usunięcia adresu z określonej listy komunikacyjnej. Technicznie może to być zwykły formularz HTML wysyłany metodą POST, formularz obsługiwany przez skrypt JavaScript albo połączenie obu mechanizmów. Po wpisaniu adresu e-mail i zatwierdzeniu danych przeglądarka wysyła żądanie HTTP do wskazanego adresu końcowego, czyli endpointu aplikacji. Serwer powinien odebrać parametry, sprawdzić ich poprawność i wykonać zaplanowaną operację w bazie danych albo w systemie obsługującym wysyłkę wiadomości.

Niedziałanie formularza nie musi oznaczać jednej konkretnej usterki. Problem może występować w warstwie widoku, kodzie JavaScript, konfiguracji serwera WWW, routingu aplikacji, mechanizmie obsługi formularzy, połączeniu z bazą danych albo zewnętrznym systemie mailingowym. Objawem może być brak reakcji przycisku, odświeżenie strony bez komunikatu, błąd HTTP, nieskończone ładowanie, komunikat o nieprawidłowym adresie mimo poprawnych danych albo pozorne przyjęcie formularza bez wykonania operacji po stronie serwera.

Objawy widoczne w przeglądarce i konsoli

Pierwszym etapem sprawdzenia jest obserwacja zachowania strony w aktualnej przeglądarce. Warto zwrócić uwagę, czy przycisk zatwierdzenia jest aktywny, czy po jego użyciu zmienia się adres strony oraz czy pojawia się komunikat potwierdzający albo informacja o błędzie. Jeżeli formularz reaguje tylko po wyłączeniu blokowania skryptów, przyczyną może być błąd JavaScript, niezaładowany plik skryptu, konflikt między bibliotekami albo niezgodność kodu z wersją przeglądarki.

Do dokładniejszej diagnostyki służą narzędzia deweloperskie przeglądarki. W zakładce Console można sprawdzić błędy wykonania skryptu, na przykład odwołanie do nieistniejącego elementu strony lub wyjątek przerwania obsługi zdarzenia submit. Zakładka Network pokazuje, czy po zatwierdzeniu powstaje żądanie HTTP, jaki ma adres, metodę i kod odpowiedzi. Kod 2xx zwykle oznacza poprawne przyjęcie żądania na poziomie HTTP, ale nie potwierdza jeszcze prawidłowego wykonania operacji biznesowej. Kody 4xx wskazują najczęściej na problem z żądaniem, autoryzacją lub adresem zasobu, a kody 5xx na błąd po stronie serwera.

Formularz może też być blokowany przez rozszerzenie przeglądarki, filtr antyśledzący, ochronę antyspamową albo politykę bezpieczeństwa treści Content Security Policy. Błąd CORS może uniemożliwić skryptowi wysłanie żądania do innej domeny, jeśli serwer nie zezwala na takie połączenie. Z kolei niezgodność adresu strony z certyfikatem TLS może powodować ostrzeżenie lub zablokowanie połączenia jeszcze przed przesłaniem danych.

Ścieżka danych od pola formularza do serwera

Analiza powinna objąć cały przepływ danych, a nie tylko wygląd strony. W kodzie HTML należy sprawdzić, czy pola mają prawidłowe atrybuty name, czy formularz ma ustawiony właściwy adres action oraz czy metoda wysyłki odpowiada temu, czego oczekuje aplikacja. Jeżeli JavaScript przechwytuje zdarzenie wysyłki, trzeba ustalić, czy wywołuje preventDefault() celowo i czy następnie rzeczywiście wykonuje żądanie do serwera. Błąd w nazwie parametru może sprawić, że serwer otrzyma puste dane mimo poprawnego wypełnienia pola.

Po stronie serwera należy zweryfikować routing endpointu, walidację adresu, obsługę tokenów zabezpieczających oraz odpowiedź zwracaną przeglądarce. Nieprawidłowo wygenerowany token CSRF może powodować odrzucenie żądania, gdy aplikacja wymaga takiego zabezpieczenia dla operacji zmieniających stan. Podobny efekt występuje przy wygasłej sesji, nieaktualnym formularzu zapisanym w pamięci podręcznej albo różnicy między domeną z formularza a domeną obsługującą żądanie. W logach aplikacji warto porównać czas wysłania formularza z wpisami dotyczącymi walidacji, błędów połączenia i odpowiedzi endpointu.

Jeżeli endpoint odpowiada poprawnie, ale rekord nie zmienia się w bazie danych lub systemie mailingowym, problem leży dalej w przepływie. Możliwa jest błędna transakcja, brak uprawnień konta aplikacyjnego, niezgodność identyfikatora listy, odrzucenie adresu przez usługę zewnętrzną albo zapisanie operacji w kolejce, której proces nie działa. Sam komunikat wyświetlony użytkownikowi nie powinien być traktowany jako dowód wykonania operacji. Potwierdzenie musi wynikać z poprawnej odpowiedzi aplikacji i sprawdzenia stanu po stronie systemu, który przechowuje listę adresów.

Sprawdzenie na laptopie lub komputerze PC

Na pojedynczym komputerze można porównać działanie formularza w innej przeglądarce, w trybie prywatnym oraz przy wyłączonych rozszerzeniach, zachowując ostrożność przy zmianie ustawień bezpieczeństwa. Należy sprawdzić datę i godzinę systemową, stan połączenia z internetem, rozwiązywanie nazwy domenowej oraz możliwość otwarcia innych stron tej samej witryny. Jeżeli problem występuje wyłącznie na jednym urządzeniu, warto wyczyścić pamięć podręczną dla danej witryny, odświeżyć zasoby i sprawdzić, czy lokalny program ochronny nie blokuje skryptu lub żądania.

Gdy ten sam błąd pojawia się na kilku komputerach i w różnych sieciach, większe znaczenie ma warstwa serwerowa albo kod strony niż lokalna konfiguracja laptopa. Diagnostyka może wtedy polegać na zapisaniu kodu odpowiedzi, adresu żądania, komunikatów z konsoli i czasu wystąpienia problemu. Takie informacje ułatwiają odtworzenie błędu oraz odróżnienie awarii przeglądarki od nieprawidłowego działania aplikacji internetowej. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z systemem, przeglądarką, połączeniem sieciowym oraz oprogramowaniem używanym do obsługi stron internetowych.