Jan Mikoláš
Slovník pojmů
Webový formulář
Formulář převádí úmysl uživatele na strukturovaný požadavek aplikace. Dobře navržený formulář je srozumitelný, funguje klávesnicí a nezaměňuje pohodlí klientské validace za ochranu dat na serveru.
Stručná definice
Sada ovládacích prvků pro zadání a bezpečné odeslání dat.
Základ tvoří element form s ovládacími prvky, například input, select, textarea a button. Každé pole má mít smysluplný název, hodnotu a viditelný popisek label. Po odeslání prohlížeč vytvoří HTTP požadavek podle atributů action a method; aplikace v něm získá data a rozhodne, zda je přijme, odmítne nebo vyžádá opravu.
Formulář není jen grafický panel ani pouze JavaScriptová komponenta. Nativní HTML poskytuje známé ovládání klávesnicí, automatické vyplňování a základní validaci. Tato vrstva zlepšuje uživatelský komfort, ale platnost, CSRF ochranu, identitu uživatele i oprávnění k akci musí vždy ověřit server.
Jaký problém řeší
Sbírá údaje a proměňuje je v jednoznačnou akci aplikace.
Formuláře se používají od vyhledávání po citlivé změny účtu. Jejich návrh ovlivňuje chybovost, bezpečnost i to, zda se uživatel dokáže vrátit k rozpracované práci.
- přihlášení, registrace, změna hesla a nastavení uživatelského účtu
- objednávka v e-shopu: kontakt, adresa, doprava, platba a potvrzení podmínek
- filtrování seznamu objednávek nebo produktů pomocí parametrů URL
- administrace produktů, skladových pohybů a oprávnění v interním systému
- nahrání přílohy, odeslání požadavku na podporu a potvrzení nevratné akce
Praktický příklad
Pole e-mailu s popiskem a chybou propojenou pro asistivní technologie
Popisek zůstává viditelný i po vyplnění, takže uživatel ví, jakou hodnotu pole očekává. Chyba je textová, má vlastní identifikátor a atribut aria-describedby ji propojí s daným vstupem. Atribut required poskytne nativní nápovědu, ale server musí e-mail zkontrolovat znovu a nemá uživateli vracet technické detaily.
U produkčního formuláře server navíc vloží CSRF token do skrytého pole. Není to tajný údaj určený do URL ani náhrada autorizace: chrání stateful browser požadavek před podvržením z cizího webu.
HTML
<form action="/checkout/contact" method="post">
<input type="hidden" name="_token" value="{csrf-token-ze-serveru}">
<label for="email">E-mail pro potvrzení objednávky</label>
<input id="email" name="email" type="email" required
aria-describedby="email-error">
<p id="email-error" role="alert">Zadejte e-mail ve správném tvaru.</p>
<button type="submit">Pokračovat k dopravě</button>
</form>Jak funguje
Od zadané hodnoty k potvrzené změně na serveru
Klient může okamžitě pomáhat s vyplněním, ale rozhodnutí o přijetí dat zůstává na serveru.
- Uživatel rozpozná účel pole Label, nápověda, vhodný typ vstupu a logické pořadí vysvětlí, jakou hodnotu formulář očekává. Placeholder může doplnit příklad, nikdy však nemá být jediným popiskem.
- Prohlížeč sestaví request Při odeslání přenese dvojice name a value. GET se hodí pro sdílené a bezpečné filtrování, POST obvykle pro změnu stavu nebo údaje, které nemají být součástí URL.
- Server ověří kontext Nejdřív kontroluje relaci či token, CSRF ochranu, oprávnění a očekávaný tenant. Hodnota z formuláře nikdy sama nedokazuje, kdo smí akci provést.
- Server validuje data Kontroluje typ, rozsah, povinné hodnoty, vztahy k jiným datům a business pravidla. Klientská kontrola se dá obejít nebo nemusí vůbec běžet.
- Aplikace vrátí výsledek Při úspěchu potvrdí další krok nebo přesměruje na bezpečnou URL. Při chybě zachová bezpečné hodnoty, označí problém u relevantního pole a neskrývá chybu jen barvou.
Důležité související pojmy
Každá vlastnost formuláře má odlišný účel.
Srozumitelný formulář odlišuje technické parametry requestu, vstupní nápovědu a ochranné kontroly.
Label a placeholder
Label pojmenovává ovládací prvek a zůstává k dispozici. Placeholder je krátká doplňková nápověda, která po psaní mizí a nemusí mít dostatečný kontrast.
GET a POST
GET zapisuje parametry do URL a hodí se pro vyhledávání či filtry. POST nese data v těle requestu a používá se pro změny, přesto sám o sobě neukrývá citlivé údaje před serverem.
Klientská a serverová validace
Prohlížeč může dříve upozornit na chybějící pole. Server však jako jediný ověřuje nedůvěryhodná data proti aktuálním pravidlům, souběhu a oprávnění.
Disabled a readonly
Readonly pole lze obvykle odeslat, disabled pole se běžně do formulářových dat nezahrne. Ani jeden atribut není bezpečnostní ochrana; request lze ručně vytvořit.
Idempotence a dvojité odeslání
U objednávky nebo platby je nutné počítat s dvojklikem, obnovou stránky a retry sítě. Tlačítko lze během odesílání vizuálně chránit, skutečnou duplicitu ale řeší serverový kontrakt.
Vztah k podobným pojmům
Formulář je rozhraní pro vstup, nikoli samostatná bezpečnostní hranice.
Stejný formulář může odeslat prohlížeč klasicky nebo JavaScriptem; pravidla pro data a oprávnění se nemění.
- Formulář a input
- Formulář sdružuje více ovládacích prvků a popisuje jejich odeslání. Input je jen jeden z možných typů vstupu; pro delší text se používá textarea, pro volbu select či radio.
- Formulář a AJAX
- AJAX je způsob, jak odeslat nebo načíst data asynchronně. Nativní form má fungovat jako základ, JavaScript může přidat rychlejší zpětnou vazbu.
- Validace a technická chyba
- Neplatný e-mail nebo chybějící povinné pole je očekávaná validační odpověď s opravou. Výpadek databáze je technická chyba, kterou je vhodné zalogovat a uživateli popsat bezpečně.
- CSRF a autorizace
- CSRF ověřuje původ stateful požadavku. Autorizace rozhoduje, zda daný uživatel smí změnit konkrétní objednávku nebo účet.
Výhody a omezení
Dobré formuláře snižují chyby, ale neodstraňují potřebu serverových pravidel.
Přínosy
- nativní HTML dává uživatelům a prohlížečům předvídatelné ovládání
- jasné popisky a chyby zkracují cestu k opravě hodnot
- progresivní vylepšení umožní funkční základ i bez JavaScriptu
- jednotný serverový tok zjednoduší kontrolu bezpečnosti a audit akce
Rizika a časté chyby
- placeholder jako jediný label nebo chyba zobrazená pouze červenou barvou
- spoléhání na HTML required či JavaScript jako na jedinou validaci
- GET pro citlivá data, tokeny nebo změnu business stavu
- prázdná chybová hláška bez vazby na pole a bez přesunu focusu k problému
- důvěra v disabled pole, MIME typ uploadu nebo hodnotu klientem poslaného tenant ID
Praktické použití
Objednávka má být proveditelná rychle, ale kontrolovaně.
V checkoutu je vhodné rozdělit rozsáhlejší data do srozumitelných kroků: kontakt, doručení, platba a kontrola objednávky. Každý krok musí mít jasný název, zachovat už zadané bezpečné hodnoty a po chybě vysvětlit, co je potřeba opravit. Souhrn ceny, měny a dopravy se nakonec znovu dopočítá na serveru, ne podle hodnot poslaných z prohlížeče.
U interní administrace může být užitečné odeslání na pozadí, automatické uložení konceptu nebo potvrzovací dialog. Tyto vrstvy nesmí odstranit možnost standardního odeslání, jasný stav akce ani ochranu před dvojitým uložením. Citlivá změna potřebuje serverovou autorizaci k danému objektu, i kdyby uživatel formulář viděl v rozhraní.
Na co myslet
Kontrolní seznam pro formulář, který neztrácí uživatele ani bezpečnost.
Test je potřeba provést v běžném prohlížeči, jen klávesnicí a také s neúspěšnou odpovědí serveru.
- propojit každý vstup s viditelným labelem a smysluplným názvem
- zobrazit chybu textem u konkrétního pole a označit ji pro asistivní technologie
- serverově validovat typ, rozsah, business pravidla, CSRF token i oprávnění
- neukládat tokeny, hesla a osobní údaje do query stringu nebo běžných logů
- testovat tabulátor, Enter, viditelný focus, zoom, mobilní šířku, dvojité odeslání a síťovou chybu
Časté otázky
Webový formulář v praxi
Nahradí placeholder formulářový popisek?
Ne. Placeholder po vyplnění mizí, může mít nízký kontrast a nepojmenovává pole spolehlivě. Použijte viditelný label a placeholder jen jako krátký příklad.
Kdy zvolit GET a kdy POST?
GET se hodí pro bezpečné, sdílené filtry a vyhledávání. POST je vhodný pro změny stavu. Citlivé údaje nepatří do URL ani při POST; server musí chránit transport přes HTTPS a správně pracovat s daty.
Stačí validace v JavaScriptu?
Ne. JavaScript zvyšuje pohodlí, ale lze jej vypnout nebo request odeslat jiným klientem. Server validuje vždy znovu a jedině on může bezpečně rozhodnout o zápisu.
Je disabled pole bezpečná ochrana?
Není. Disabled ovlivňuje prohlížečové ovládání a obvykle se ani neodešle. Útočník může vytvořit vlastní request, proto se oprávnění i povolené hodnoty kontrolují na serveru.
Jak pracuji s uživatelskými toky v praxi
Formuláře navrhuji jako součást bezpečné a srozumitelné cesty uživatele.
V e-commerce a interních systémech propojuji přístupné rozhraní s validací, autorizací a spolehlivým zpracováním změn na serveru.