Walidacja danych - klient vs serwer

O czym jest ta prezentacja?

Walidacja na dwóch frontach

Walidacja danych to proces sprawdzania, czy dane wprowadzone przez użytkownika spełniają określone wymagania. W aplikacjach webowych mamy dwie warstwy walidacji: po stronie klienta (HTML/JavaScript) i po stronie serwera (PHP). Klient poprawia UX - użytkownik od razu widzi błędy. Serwer chroni dane - bo walidację klienta można ominąć. W tej prezentacji wyjaśnisz, dlaczego obie warstwy są potrzebne, pokażesz praktyczne przykłady i udowodnisz, że “JS poprawia UX, PHP chroni dane”.

Kluczowe pytania do odpowiedzi

Co to jest walidacja? - Definicja i cel walidacji danych
Jak to działa? - Mechanizmy walidacji HTML5, JavaScript i PHP
Kiedy używać której warstwy? - Tabela: co walidować gdzie
Na co uważać? - Dlaczego walidacja JS nie wystarcza
Jak robić dobrze? - Best practices i komunikaty błędów

Zakres merytoryczny

Elementy obowiązkowe

Walidacja HTML5 (atrybuty)
- required - pole wymagane
- pattern - wyrażenie regularne
- type="email", type="number" - typy pól
- minlength, maxlength, min, max - ograniczenia
Walidacja JavaScript
- Sprawdzanie przed wysłaniem formularza
- Dynamiczne komunikaty błędów
- Walidacja w czasie rzeczywistym (on blur, on input)
Walidacja PHP (serwer)
- filter_var() - walidacja email, URL, liczb
- Sprawdzanie długości, zakresu, dozwolonych wartości
- Zawsze ostateczna linia obrony
Dlaczego JS można ominąć
- DevTools - edycja HTML
- curl/Postman - requesty bez przeglądarki
- Wyłączony JavaScript w przeglądarce
Komunikaty błędów jako UX
- Jasne, zrozumiałe komunikaty
- Wskazanie co poprawić
- Nie zdradzanie informacji atakującym

Wymagane elementy wizualne

Schemat przepływu

Formularz → Walidacja JS (UX) → Request → Walidacja PHP (bezpieczeństwo) → Odpowiedź

Tabela porównawcza

Co walidować gdzie: klient (format, obecność) vs serwer (wszystko + logika biznesowa)

Warianty realizacji

Zawartość:

Wyjaśnij różnicę między walidacją klienta a serwera
Pokaż 1 przykład HTML (np. required, pattern)
Pokaż 1 przykład PHP (filter_var lub sprawdzenie długości)
Pokaż 1 schemat przepływu danych

Forma: 10 slajdów, 10 minut prezentacji

Ocena: 3.0

Struktura prezentacji

Slajd tytułowy - Tytuł, autorzy, data
Agenda - Plan prezentacji
Problem - Co się dzieje bez walidacji? (zepsute dane, ataki)
Definicja walidacji - Czym jest i po co ją stosujemy
Walidacja HTML5 - Atrybuty required, pattern, type
Walidacja JavaScript - Dynamiczne sprawdzanie
Walidacja PHP - filter_var(), sprawdzenia ręczne
Schemat przepływu - Klient → Serwer → Odpowiedź
Dlaczego JS nie wystarcza - Demo/przykład obejścia
Komunikaty błędów - Dobre praktyki UX
Checklista walidacji - Co sprawdzać dla każdego pola
Podsumowanie i źródła

Scenariusze i przykłady

Scenariusz 1: Request bez przeglądarki

Programista zabezpieczył formularz tylko walidacją JavaScript. Atakujący używa curl:

curl -X POST https://example.com/api/register \
  -d "email=not-an-email&age=-5"

Serwer bez walidacji PHP zapisuje “not-an-email” jako email i “-5” jako wiek. Dane w bazie są zepsute.

Scenariusz 2: Edycja HTML w DevTools

Użytkownik otwiera DevTools, usuwa atrybut maxlength="100" z pola textarea i wysyła komentarz o długości 10 000 znaków. Bez walidacji PHP serwer go zapisuje, co może “zepsuć” layout strony lub plik JSON.

Scenariusz 3: Walidacja dozwolonych wartości

Pole “status” w formularzu ma dropdown z opcjami: “aktywny”, “nieaktywny”. Ktoś edytuje HTML i dodaje opcję “admin”. Bez walidacji PHP (sprawdzenie czy wartość jest w dozwolonej liście) - błąd logiki aplikacji.

Mini case study (dla wariantu C)

Przypadek: Formularz rezerwacji

W projekcie semestralnym mamy formularz rezerwacji z polami:

Data - walidacja JS: nie wcześniej niż dziś; walidacja PHP: format YYYY-MM-DD + sprawdzenie dostępności
Liczba gości - walidacja HTML: min=1 max=10; walidacja PHP: is_numeric() + zakres 1-10
Email - walidacja HTML5: type=“email”; walidacja PHP: filter_var($email, FILTER_VALIDATE_EMAIL)

Każde pole ma walidację na obu warstwach. Dzięki temu użytkownik ma szybki feedback (JS), a serwer jest bezpieczny (PHP).

Wskazówki do wystąpienia

Jedno zdanie kluczowe

“JavaScript poprawia UX, PHP chroni dane” - powtórz to kilka razy w prezentacji.

Pokaż tabelkę

Wizualna tabela “co walidować gdzie” zostaje w pamięci lepiej niż tekst.

Krótkie przykłady

Kod powinien mieć 5-10 linii max. Duże bloki kodu zniechęcają.

Demo obejścia

Jeśli możesz - pokaż na żywo jak edytować HTML w DevTools. To robi wrażenie.

Najczęstsze błędy

Błąd	Jak unikać?
Twierdzenie, że walidacja JS wystarcza	Zawsze podkreślaj: serwer musi walidować
Zbyt skomplikowane wyrażenia regularne	Pokaż proste przykłady, regex wyjaśnij ogólnie
Brak przykładów komunikatów błędów	Przygotuj slajd z dobrymi i złymi komunikatami
Czytanie że slajdów	Znaj materiał, mów własnymi słowami
Pominięcie walidacji dozwolonych wartości	To częsty błąd w realnych aplikacjach - pokaż go

Zasoby

MDN: Client-side form validation Kompletny przewodnik po walidacji HTML5 i JavaScript.

PHP: filter_var() Dokumentacja funkcji do walidacji email, URL, liczb i więcej.

PHP: Filter Functions Lista wszystkich filtrów walidacyjnych i sanityzacyjnych w PHP.

OWASP: Input Validation Cheat Sheet Profesjonalne praktyki walidacji danych wejściowych.

Do dzieła!

Prezentacja to umiejętność zawodowa!

Walidacja danych to temat, który pojawia się w KAŻDYM projekcie webowym. Zrozumienie różnicy między walidacją klienta a serwera to podstawa pracy programisty.

Wykorzystajcie lekcje - przygotujcie przykłady z własnego projektu semestralnego!

Współpraca to klucz - podzielcie się: jedna osoba zajmuje się stroną klienta (HTML/JS), druga stroną serwera (PHP).

Pamiętajcie: Nigdy nie ufaj danym od użytkownika. Waliduj na serwerze. Zawsze.