Edytujesz Proč vaše rozhraní mate uživatele, i když kód funguje

Druhou vrstvou je omezení práv databázového účtu. Aplikace by neměla přistupovat k databázi jako administrátor. Pro běžný provoz stačí práva pouze na potřebné tabulky a operace, bez možnosti měnit strukturu nebo číst systémové tabulky. Pokud útočník i přes chybu získá přístup, narazí na zeď a nezíská celý server. Samostatný účet pro každou aplikaci také usnadní dohledání incidentu.<br><br>Podpis, expirace a bezpečné ukládání První zásadní chybou je ignorování algoritmu. Útočník může změnit hlavičku na „none" nebo podstrčit jiný algoritmus. Vždy explicitně povolte pouze jeden očekávaný algoritmus a odmítněte vše ostatní. Druhou chybou je příliš dlouhá platnost tokenu. Access token by měl žít v řádu minut, maximálně hodin. Delší platnost řešte refresh tokenem, který lze revokovat. Refresh token ukládejte bezpečně – v prohlížeči do httpOnly cookie s atributy Secure a SameSite, nikdy do localStorage. localStorage je přístupný z JavaScriptu, takže při XSS útoku útočník token okamžitě získá.<br><br>SQL injection vzniká ve chvíli, kdy se do textu databázového dotazu vkládá vstup od uživatele přímým spojováním řetězců. Útočník pak místo očekávané hodnoty pošle fragment SQL, který změní význam celého dotazu. Nejde přitom jen o přihlašovací formuláře. Zranitelné bývají vyhledávací pole, filtry v administraci, řazení tabulek, stránkování i importy souborů. Stačí jedno místo, kde se hodnota z požadavku ocitne v dotazu bez oddělení od kódu.<br><br>Základní pravidlo zní: jedna obrazovka, jedna hlavní akce. Když dáte uživateli tři stejně výrazná tlačítka vedle sebe, nebude vědět, které je to správné. Vizuální hierarchie se nedělá barvami, ale velikostí, umístěním a kontrastem. Primární tlačítko ať je jen jedno a ať je jasně odlišené. Zbytek ať vypadá jako sekundární volba. Stejně tak formuláře: každé pole, které není nutné, zvyšuje šanci, že uživatel odejde. Ptejte se u každého inputu, co se stane, když ho smažete.<br><br>Testování mobilních aplikací se od testování webu liší víc, než se na první pohled zdá. Nejde jen o jinou velikost obrazovky. Aplikace běží na zařízení s omezeným výkonem, přerušovaným připojením, různými verzemi operačního systému a agresivní správou baterie. Pokud se tyto faktory ignorují, testovací scénáře projdou na vývojářském stroji, ale v reálném provozu aplikace padá nebo se chová nepředvídatelně.<br><br>Většina vývojářů řeší UI až ve chvíli, kdy je logika hotová. To je první a nejčastější chyba. Rozhraní není dekorace nad databází, je to místo, kde se rozhoduje, jestli aplikace vůbec půjde používat. Pokud začnete návrhem obrazovky až po napsání endpointů, budete předělávat obojí. Začněte naopak: nakreslete na papír, co uživatel uvidí, co musí vyplnit a co se stane po odeslání. Teprve pak pište kód.<br><br>Typická past je přebírání komponent bez pochopení kontextu. Hotová knihovna tlačítek nebo modalů vypadá skvěle v demu, ale v aplikaci najednou nesedí rozestupy, chybí focus pro klávesnici a na mobilu se rozbije. Než něco použijete, projděte si, jak se to chová při psaní, při chybě a při ovládání bez myši. Přístupnost není volitelná: kontrast textu, popisky u ikon, ovladatelnost tabulátorem. Pokud tlačítko nejde aktivovat klávesnicí, je to chyba, ne detail.<br><br>Funkce, která má přes 30 řádků, obvykle dělá víc věcí. Rozdělte ji. Každá funkce by měla mít jednu odpovědnost a ideálně vracet hodnotu, ne měnit okolní stav. Vyhněte se hlubokému vnořování if bloků – použijte guard clauses na začátku funkce. Místo if (podminka) { ... } else { ... } často stačí otočit podmínku a vrátit se včas. Tím se sníží počet úrovní odsazení a kód se čte shora dolů jako příběh.<br><br>JWT se skládá ze tří částí: hlavičky, datové části a podpisu. Hlavička určuje algoritmus, datová část nese takzvané claims – např. identitu uživatele, roli, čas expirace. Podpis zajišťuje integritu. Pokud použijete symetrický algoritmus (HS256), podepisujete i ověřujete stejným klíčem. Asymetrický (RS256) odděluje soukromý klíč pro podpis a veřejný pro ověření, což se hodí, když API ověřuje více služeb. Nikdy neposílejte citlivá data v datové části – JWT je pouze podepsaný, ne zašifrovaný. Kdokoli s tokenem vidí jeho obsah.<br><br>Stavy, na které se zapomíná Největší rozdíl mezi prototypem a použitelnou aplikací jsou stavové obrazy. Vývojář často řeší jen ten šťastný případ: data dorazila, vše se vykreslilo. Ale co prázdný seznam? Co načítání? Co chyba sítě? Co neplatný vstup? Každá z těchto situací potřebuje vlastní obrazovku nebo alespoň text. Prázdný stav nemá být bílá plocha, ale krátká věta a výzva k akci. Chybová hláška nemá být „Error 500", ale co se pokazilo a co má uživatel udělat dál. Načítání delší než zlomek sekundy potřebuje indikaci, jinak uživatel klikne znovu.