Vlákno názorů k článku
Java na webovém serveru: autorizace a autentizace II

Proti tomuto nastavování beans bych také něco měl:
* Nerozlišuje to GET a POST.
* Nekontroluje to proti definici formuláře, takže je někdy možné podstrčit i něco navíc.

Druhý bod si lze představit třeba na editaci uživatelského profilu. Jakmile do uživatele přidáme nějaká oprávnění (dobře, na ty jsou spíš role) nebo informace typu VIP/non-VIP, může je uživatel se změnou profilu měnit také.

Právě proto se hodí nějaká knihovna pro formuláře a svázat to s ní.

Na rozdílu GET/POST moc nesejde – podvrhnout se dá jedno i druhé, obojí pochází od uživatele a nemáme je pod kontrolou – je potřeba k nim přistupovat stejně nedůvěřivě (stejně jako ke cookie, http refererům a dalším informacím přicházejícím od klienta).

To nastavování pomocí property="*" je dost šikovné, člověk nemusí otrocky vypisovat všechny vlastnosti. Většinou se použije pro nastavení vlastnosti JavaBeany (v tomto případě registraceUzivatele), která obsahuje jen ty metody (settery jen pro ty GET/POST parametry, které jsou přípustné), které nás zajímají a které z HTTP požadavku chceme vydolovat – pak z toho máme proměnné uvnitř javovské třídy, se kterými se pracuje daleko lépe než v JSP – minimalizujeme programování v JSP (které se má starat jen generování HTML a předávání uživatelských vstupů – logiky by v něm mělo být co nejméně) a přesouváme ho do Javy.

„Jakmile do uživatele přidáme nějaká oprávnění…“

To je pravda, ale tohle zabezpečení je potřeba řešit v nižších vrstvách aplikace – nespoléhat se na to, že jsme (nebo nějaká knihovna) v JSP nastavili objektu jen ty vlastnosti, které jsme měli. Ty kontroly (které v současnosti zatím nejsou potřeba) by se měly provádět co nejníž (v EJB) – protože jednou třeba přidáme alternativní prezentační vrstvu (např. verzi stránek pro mobilní zařízení) a tam kontroly zapomeneme dát (nebo nezapomeneme, ale znamená to duplikaci logiky).

Robustnější by bylo, neposílat instanci třídy Uzivatel, ale založit si na to zvláštní třídu PozadavekNaRegistraci, která by obsahovala jen ty vlastnosti, které jsou v registračním formuláři (v současnosti by obsahovala to, co obsahuje Uzivatel). Je to takové balancování – snažím se ukázat, co všechno Java nabízí, ale zároveň nezahltit čtenáře tunou kódu. Schválně to takhle přepíšu, ale běda jak mi někdo vynadá :-) a řekne „hej kámo, ta tvoje aplikace umí akorát uložit záznam do databáze a pak ho načíst – a potřebuješ na to milion tříd a dvě vrstvy.“ :-) Zatímco on by si vzal třeba PHP a v jednom skriptu v něm nasekal GET/POST parametry rovnou do SELECTů/INSERTů a poslal do DB. A měl radost z toho, jako pěknou aplikaci napsal. To samozřejmě v Javě jde taky (viz 3. díl – JSP SQL značky). Člověk se prostě nikdy nezavděčí všem (zvlášť když dělá otevřený software a ještě o tom píše :-)

Neříkám, že GET/POST je důležitý bezpečnostní rozdíl (za určitých podmínek teda ano), ale už z principu to není dobré mixovat.

Formulářové knihovny jsou asi až ve frameworcích, že? Ta třída PozadavekNaRe­gistraci je sice možná, ale… …ale i tady je určitá duplikace – jednou je seznam povolených ve formuláři a jednou ve třídě PozadavekNaRe­gistraci. Nějaká formulářová knihovna takovéto data binding přece umožňuje, nebo ne?