Názory k článku
Java na webovém serveru: autorizace a autentizace II

Chtěl bych protestovat proti tokenu v URL. Pokud bude na té stránce nějaký odkaz ven, musíme si dávat bacha na ně, protože mohou token získat z refereru. V tomto případě to asi vadit nebude, protože token se po použití stává asi ihned k ničemu, ale přesto si myslím, že to není dobré takto učit.

V případě jednorázového tokenu to problém není, klidně v URL být může. Je dobré napsat, že když jednorázový není, je potřeba ho předávat přes POST, ne GET, ale tady si člověk může vybrat (což se hodí např. pokud bychom požadovali potvrzení e-mailem – odkaz odkaz s GET parametrem vložíme i do textového mailu, pro POST bychom museli posílat e-mail v HTML a s formulářem, což je dost omezující).

Zajímavý argument, nicméně bych ho radši viděl přímo ve článku.

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?

Článek dobrý a autorovi posílám pochvalu za celou sérii.

V tomto dílu mě ale zarazila definice tabulek pro uzivatel_role – referencovat „prezdivka“ místo primárního klíče mi trochu skřípe, zvláště, když nevidím ani žádné zjevné výhody. Je to kvůli nějakému omezení, třeba v rámci definice JDBCRealm?

Ano, je to tím JDBCRealmem – on by se jinak uživatel musel přihlašovat svým ID, což by se mu jistě nelíbilo. Vidím to na napsání vlastního přihlašovacího modulu (nejen z tohoto důvodu), ale to se do tohoto dílu nevešlo – ve zdrojácích se ale dříve nebo později objeví, takže o něj nepřijdete :-)

Děkuji za zajímavý článek. Dodám svůj názor na jeden detail. Osobně se domnívám, že tabulka Role je nesmyslná. Myslím, že je lepší seznam rolí uložit do aplikace, přímo do kódu nebo nastavení webu. Pokud se totiž změní požadavek na role, je asi vždy nutné změnit kód aplikace. Pak mám v databázi zbytečnou tabulku do které kladu zbytečné dotazy.

Mějte se hezky

Ona tam trochu navíc je – autentizace by fungovala i bez ní, dotazy se do ní nekladou – je tam hlavně pro kontrolu – referenční integrita nám zajistí, že v tabulce uzivatel_role se neobjeví žádná neexistující role (nešla by ani vložit, musí být nejdřív v číselníkové tabulce). Tohle by šlo i bez tabulky, třeba pomocí Check Constraints, ale to bychom pak při přidání role museli dělat DDL – takhle stačí DML (přidat záznam do tabulky).

Musím ale přiznat, že datový model uživatelů/rolí není úplně podle mých představ – musel se dost přizpůsobit tomu, co předpokládá  JDBCRealm.

Vypadá to hezky, ale zajímá mě, jak to bývá implementované na různých Java hostinzích.

Application-level nastavení bude asi v tom WAR souboru, ale nastavení toho realmu je už nastavení serveru.

Dovolují mi toto běžné Java hostingy taky nastavit ?

Díky za bezva rady ohledně realmu. Měl bych jeden dotaz, je možné nastavit realm z databáze tak, že v databázi mám pouze jednu tabulku „uzivatel“, který má atribut role? Nějak se mi to bohužel nedaří.