Ktoś wysyła Twój formularz z nieprawidłowym adresem e-mail. Formularz to przyjmuje. E-mail powitalny wraca jako niedostarczony. Ta osoba nigdy nie dostaje od Ciebie wiadomości. Ktoś inny wysyła formularz bez wymaganych pól. Formularz i tak przechodzi. Twój zespół ma niekompletne dane. Obie te porażki wynikają z braku lub błędnej walidacji.
Walidacja to sprawdzanie, czy dane z formularza są poprawne, zanim zostaną przyjęte. Odbywa się w dwóch miejscach: w przeglądarce i na serwerze. Oba mają znaczenie. Ten artykuł opisuje, jak działa walidacja, dlaczego potrzebujesz obu rodzajów i jakie są częste błędy.
Czym jest walidacja?
Walidacja sprawdza, czy dane w formularzu spełniają Twoje wymagania. Pola wymagane mają wartości. Pola e-mail zawierają znak @. Pola telefonu zawierają tylko cyfry. Przesyłane pliki mieszczą się w limicie rozmiaru.
Bez walidacji do Twojego systemu trafiają złe dane. Zaplecze się wysypuje. Usługa e-mail odrzuca wiadomości. Tracisz czas na porządkowanie brudnych danych.
Walidacja odbywa się w dwóch miejscach: po stronie klienta (w przeglądarce, przed wysłaniem) i po stronie serwera (na Twoim serwerze, po wysłaniu). Oba są potrzebne.
Walidacja po stronie klienta
Przeglądarka może sprawdzić dane z formularza przed ich wysłaniem. HTML ma wbudowane atrybuty walidacji. JavaScript też potrafi walidować.
Walidacja HTML
<input type="email" required> sprawdza, czy pole ma wartość i wygląda jak adres e-mail. Przeglądarka pokazuje komunikat o błędzie, gdy użytkownik próbuje wysłać nieprawidłowy formularz.
Atrybuty walidacji HTML to między innymi required, który wymusza wartość w polu, min/max dla liczb, które utrzymują wartości w zakresie, minlength/maxlength, które egzekwują liczbę znaków, pattern, który dopasowuje wyrażenia regularne, oraz type, który sprawdza sam typ pola. Na przykład type="email" sprawdza format, a type="number" odrzuca dane nienumeryczne.
Walidacja HTML działa od razu, bez JavaScriptu, a przeglądarka podaje dobre komunikaty o błędach i dopasowuje klawiaturę na telefonie do typu pola. Wady to ogólne, czasem niejasne komunikaty przeglądarki, brak możliwości ich dostosowania bez JavaScriptu oraz różne komunikaty w różnych przeglądarkach.
Walidacja JavaScript
Dla większej kontroli waliduj za pomocą JavaScriptu, używając function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } oraz form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. Walidacja JavaScript pozwala pisać własne reguły, pokazywać własne komunikaty o błędach i sprawdzać pola w trakcie pisania, czyli w czasie rzeczywistym. Wady to konieczność użycia JavaScriptu (niewiarygodny dla bezpieczeństwa), więcej kodu do utrzymania oraz ryzyko pokazania błędów, zanim użytkownik skończy pisać, jeśli walidujesz przy zdarzeniu input.
Walidacja po stronie serwera
Po wysłaniu formularza serwer sprawdza dane ponownie. Tu dzieje się prawdziwe bezpieczeństwo.
Nigdy nie ufaj walidacji po stronie klienta. Ktoś może wyłączyć JavaScript. Ktoś może przechwycić żądanie i zmienić dane. Ktoś może użyć curl lub innego narzędzia, by wysłać złe dane, w ogóle nie korzystając z Twojego formularza.
Walidacja po stronie serwera to jedyna ochrona, jaką masz. Nie jest opcjonalna.
Gdy serwer odbiera wysłany formularz, sprawdź, czy pola wymagane są obecne, zwaliduj format e-maila, telefonu i adresów URL, sprawdź, czy liczby mieszczą się w oczekiwanych zakresach, zweryfikuj, czy przesyłane pliki mają właściwy typ i rozmiar, upewnij się, że dane nie są zbyt długie, i zsanityzuj dane, by zapobiec atakom injection. Jeśli walidacja się nie powiedzie, wyślij odpowiedź z błędem, tak aby formularz nie został przetworzony, a użytkownik dowiedział się, co jest nie tak. Walidacja po stronie serwera jest wolniejsza, bo użytkownik musi czekać na odpowiedź, ale jest niezawodna i bezpieczna, więc rób ją zawsze.
Kiedy używać którego rodzaju walidacji
Walidacja po stronie klienta służy wygodzie użytkownika. Od razu mówi, że coś jest nie tak. Nie musi wysyłać formularza, by dowiedzieć się, że e-mail jest nieprawidłowy.
Walidacja po stronie serwera służy integralności danych i bezpieczeństwu. Gwarantuje, że złe dane nigdy nie trafią do Twojego systemu.
Używaj obu. Walidacja po stronie klienta dla szybkości i informacji zwrotnej. Walidacja po stronie serwera dla bezpieczeństwa.
Częste błędy w walidacji
Walidacja tylko po stronie klienta
Ktoś wyłącza JavaScript i Twoja walidacja znika. Ktoś używa curl, by wysłać POST ze złymi danymi, i Twoja walidacja w ogóle się nie uruchamia. W bazie danych lądują śmieci.
Zawsze waliduj na serwerze. Strona klienta to dodatek.
Zbyt ścisła walidacja
Walidacja e-maila jest tak ścisła, że prawdziwe adresy jej nie przechodzą. Walidacja telefonu przyjmuje tylko format amerykański i odrzuca numery zagraniczne. Pole imienia odrzuca myślniki, apostrofy i inne poprawne znaki.
Przetestuj walidację na prawdziwych danych. Poproś o test osoby z innych krajów. Ustaw reguły walidacji jak najbardziej liberalnie, wciąż wychwytując złe dane.
Brak jasnych komunikatów o błędach
„Nieprawidłowe dane." Co jest nieprawidłowe? Które pole? Co użytkownik ma zrobić?
Komunikaty o błędach muszą być konkretne: „E-mail musi mieć od 5 do 254 znaków." „Telefon musi mieć 10 cyfr." „Hasło musi zawierać co najmniej jedną cyfrę."
Pokaż błąd obok pola, które go wywołało. Nie chowaj błędów na liście zbiorczej, gdzie użytkownik musi ich szukać.
Walidacja danych wrażliwych po stronie klienta
Nie przepuszczaj numerów kart płatniczych ani haseł przez walidację po stronie klienta. Nie pokazuj ich w konsoli przeglądarki. Nie zapisuj ich w logach.
Waliduj dane wrażliwe tylko na serwerze, przez HTTPS.
Brak walidacji przesyłanych plików
Ktoś przesyła plik o rozmiarze 100 megabajtów. Na Twoim serwerze kończy się miejsce. Ktoś przesyła plik wykonywalny. Twój serwer łapie wirusa.
Waliduj typ i rozmiar pliku na serwerze. Sprawdź, czy plik naprawdę jest takim typem, za jaki się podaje. Nie ufaj samemu rozszerzeniu pliku ani typowi MIME.
Walidacja w czasie rzeczywistym a walidacja przy wysyłaniu
Walidacja w czasie rzeczywistym sprawdza każde pole w trakcie pisania. Użytkownik od razu widzi komunikat o błędzie, gdy wpisze coś źle. Może to poprawić od razu.
Wada: jeśli pokażesz błędy zbyt wcześnie, użytkownik się frustruje. Pokazuj błędy dopiero po opuszczeniu pola (zdarzenie blur), a nie w trakcie pisania.
Walidacja przy wysyłaniu sprawdza wszystko w momencie wysłania formularza. Użytkownik wypełnia cały formularz, a potem widzi wszystkie błędy naraz.
Wada: użytkownik musi wrócić i poprawić błędy po wysłaniu. To przerywa przepływ.
Najlepsza praktyka: waliduj przy blur (gdy użytkownik opuszcza pole), by dawać informację w czasie rzeczywistym. Waliduj przy wysyłaniu jako ostateczną kontrolę. Jeśli coś się nie uda, pokaż wszystkie błędy naraz.
Walidacja dla konkretnych typów pól
Walidacja adresu e-mail
Pełna walidacja adresu e-mail jest skomplikowana (RFC 5322 ma 60 stron), więc w większości przypadków sprawdź, czy wartość zawiera @ i domenę, używając const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. To wychwytuje większość nieprawidłowych adresów, a nie jest tak ścisłe, by odrzucać prawdziwe.
Walidacja numeru telefonu
Format telefonu różni się w zależności od kraju. Format amerykański to (123) 456-7890, brytyjski to +44 20 7946 0958, a w Niemczech używa się +49 30 123456. Przyjmuj format międzynarodowy, usuwaj znaki nienumeryczne na serwerze i przechowuj numer jako ciąg znaków, a nie liczbę, aby zachować początkowe zera w niektórych krajach.
Walidacja hasła
Dobre hasło jest długie (co najmniej 12 znaków) i trudne do odgadnięcia. Nie wymagaj znaków specjalnych ani mieszania wielkości liter, bo te zasady frustrują użytkowników i nie poprawiają bezpieczeństwa. Dobre wymagania to co najmniej 12 znaków i unikanie typowych wzorców (jak „123456" czy imię użytkownika). Użyj wskaźnika siły hasła, by pokazać użytkownikowi, jak mocne jest jego hasło.
Walidacja daty
Sprawdź, czy data leży w przyszłości lub przeszłości, zależnie od potrzeby. Formularz rejestracji na wydarzenie powinien odrzucać daty z przeszłości. Formularz z datą urodzenia powinien odrzucać daty z przyszłości.
Jak WEMASY obsługuje walidację formularzy
Formularze WEMASY mają wbudowaną walidację po stronie klienta (pola wymagane, format e-maila itd.), która daje natychmiastową informację zwrotną. Gdy formularze są wysyłane, serwery WEMASY ponownie walidują wszystkie dane przed przetworzeniem. Dzięki temu użytkownicy dostają szybką informację zwrotną, a Twoje dane są chronione.
Sprawdź funkcje walidacji w swoim pakiecie WEMASY.