facebook LinkedIN LinkedIN - follow
IT security , IT Security

Slabá místa nové generace web technologií

Důsledky přesunutí uživatelského rozhraní aplikací do prohlížeče



ProfinitV poslední době jsme svědky bouřlivého vývoje webových technologií a dalo by se říci, že jsme na prahu technologické generační výměny. V předchozích generacích jsme se v Java světě posouvali k vyšší efektivitě vývoje od servletové specifikace přes JSP, MVC, komponentové frameworky a další technologické skoky až do stavu, kdy se další rozvoj musí zaměřit na prohlížeč, pokud má přinést nějaký významný posun. Tato změna zaměření však znamená, že není možné použít mnoho z dosavadních vyzkoušených konceptů pro čistě serverový vývoj a ne ve všech oblastech se zatím daří najít dostatečné náhrady.


V aktuální generaci web technologií se (pro větší projekty) ustálila následující třívrstvá architektura:

  • Generování a obsluha uživatelského rozhraní
  • Byznys služby (služby operující s abstraktním modelem domény problému bez technických podrobností)
  • Technické služby (služby operující na úrovni technického modelu aplikace - databáze, web služby atd.)

Všechny tyto vrstvy byly umístěny jako jeden balík na serveru a prohlížeč byl pouze pasivní zobrazovač. Cílem nové generace web technologií je daleko bohatší uživatelské rozhraní a zvýšení responzivity, která by se měla blížit desktopovým aplikacím, a proto se celá první vrstva přesouvá do prohlížeče. V následujících kapitolách si rozebereme několik konkrétních důsledků, které tato změna má.

Bezpečnost

Za oblast bezpečnosti zmiňme alespoň jednu zásadní změnu. Uživatelské rozhraní dříve sloužilo jako bezpečná vstupní brána do aplikace, protože jeho komponenty dovolily uživateli přistupovat k vrstvě byznys služeb pouze takovým způsobem, jakým určil programátor. Knihovny komponent se pak zaměřovaly na to, aby jejich komponenty nedovolovaly jakékoli potenciálně nebezpečné použití i v případě nezkušených nebo chybujících programátorů.

Po přesunu uživatelského rozhraní do prohlížeče, kde je kód spouštěn mimo kontrolované prostředí serveru, jsou všechny byznys služby přístupné zcela veřejně a pro tuto situaci zatím nebyla ustálena taková koncepce, která by dovolovala bezpečnost vyčlenit do samostatného, nezávislého modulu jako v případě komponent uživatelského rozhraní. Při naivní přímočaré architektuře se tedy vracíme do stavu, kdy o bezpečnosti opět rozhoduje kvalita a pečlivost jednotlivých programátorů.

Ukažme si to na jednoduchém příkladu. Mějme byznys službu pro získání informací o účtu klienta (např. zůstatku) v internetovém bankovnictví. Ve stávající architektuře není v této službě potřeba kontrolovat, zda má aktuální uživatel právo vidět informace o daném konkrétním účtu, protože programátor nebude tuto službu volat pro libovolný účet, ale jen pro ty, které má k dispozici v kontextu aktuálního uživatele.

Pokud je však taková služba volána přímo z prohlížeče, je nutné počítat s tím, že případný útočník může zkoušet volat službu pro libovolný účet, a je proto nutné při každém jejím volání vyhodnotit disponentský model pro daného uživatele a určit, zda má na informace právo. To je složitý úkon, na který může programátor zapomenout nebo jej udělat nesprávně.

Z naší zkušenosti se nám pro enterprise řešení výše uvedený scénářů zatím osvědčil jen projekt Spring Security. Ačkoli je Spring Security de facto standardem již současné generace web aplikací, využívají se většinou pouze jeho základy. Pro výše popsané scénáře je ale nutné použít i jeho pokročilé vlastnosti, například techniku „access control lists“ nebo „method level security“, takže s úplně hladkým přechodem není možné počítat ani v tomto případě.

Segmentace programových artefaktů a jejich závislosti

Mění se také základní jednotka dat odesílaných do prohlížeče, což původně u web aplikací znamená jedna stránka. Ačkoli se toto dávkování poslední dobou trochu rozostřilo, zůstalo až do současnosti víceméně platné a v praxi se osvědčilo. V nové generaci web aplikací se však do prohlížeče neodesílá pouze výsledný dokument k zobrazení, ale i programový kód celé jedné vrstvy aplikace a strategie, jak jej rozdělit, zatím není zcela ustálená. Může být kdekoli mezi extrémy:

  • Nerozdělovat vůbec - veškerý kód aplikace se načte před jejím spuštěním. To je od určité velikosti aplikace neudržitelné.
  • Rozdělovat stejně jako dříve - kód je rozdělen po jednotlivých stránkách/formulářích. Tímto se připravujeme o jednu z velkých výhod nové architektury - responzivity aplikací, které nemusí čekat na dotažení další stránky po každé akci uživatele.

Velikost aplikací bude navíc narůstat ve dvou dimenzích - v rozsahu funkčnosti a ve velikosti používaných knihoven. V současnosti tento problém není nijak vážný, ale je potřeba ho brát v potaz před tím, než na novou generaci web technologií přejdou velké enterprise informační systémy, které mají v současnosti stovky až tisíce formulářů a používají knihovny, které i v binární podobě mají celkovou velikost ve stovkách megabajtů.

O tom, že minimalizovat a rozdělit klientskou aplikaci na více částí není triviální činnost, je možné se přesvědčit u Google projektu GWT, který se tímto tématem zabýval jako jeden z prvních a dosud zůstává poměrně osamocen. To může být dáno tím, že jiné projekty v této otázce spoléhají na řešení připravované příslušnou standardizační komisí. Toto řešení ale ještě není oficiální a i po jeho schválení bude nějakou dobu trvat, než se objeví kvalitní implementace.

Integrace

Předchozí kapitola je projevem obecného problému s přehnaným optimismem - nová generace technologií se často zdá jednodušší a lepší ne proto, že problémy řeší lépe, ale proto, že je ve svých začátcích neřeší vůbec. Díky tomu můžeme očekávat problémy v další oblasti, jejíž podhodnocení se projeví až v pozdějších fázích projektu, případně při údržbě – v integraci. Pod tímto označením si můžeme představit rovnou dva odlišné významy:

  • Používání více různých knihoven (nebo jejich verzí) v rámci jedné aplikace
  • Používání více různých serverů v rámci jedné aplikace

První bod se opět v současnosti nemusí jevit jako problém, protože reálně je většina aplikací postavena monoliticky na některé základní knihovně bez dalších závislostí (jQuery, Angular, Sencha...) a ta aplikaci poskytuje jednotné běhové prostředí pro události, služby, navigaci, sdílené zdroje atd.

Stejně jako v předchozí kapitole se to ale může změnit ve chvíli, kdy se takto začnou vyvíjet projekty natolik velké, že budou dodávány po částech různými dodavateli v různých časových etapách. Je pravděpodobné, že koexistence a kooperace takto rozsáhlých subdodávek bude muset využívat nástrojů poskytovaných prohlížečem, které k takto důležitému úkolu, nejsou stavěny.

Zatímco předchozí problém není oficiálně adresován ve standardizačních dokumentech a na našich projektech je řešen podle firemních best practices přímo architektem nebo designérem, druhý z integračních problémů je už nyní řešen komerčně produkty typu Mule nebo Apiary. Není tedy potřeba jako v předchozím případě vyvíjet řešení na koleně, ale je třeba myslet na začlenění příslušných produktů do celkového řešení včas.

Organizace

Nesmíme podceňovat ani netechnické aspekty vývoje. Nová generace web technologií velmi prosazuje flexibilitu a povyšuje jí na základní architektonický princip rozdělením funkčnosti do zcela nezávislých bloků zvaných microservices. Je třeba si však uvědomit, že toto je řešení pouze technických otázek tolik vzývané agility, která ale musí mít oporu i v celkové organizaci vývoje.

Jako výstrahu je opět možné vzít si konkrétní příklad z předchozí technologické generace, kde podobnou míru flexibility slibovaly např. Java portály typu Liferay, kde každá jedna funkčnost může být dodávána jako samostatná aplikace. Flexibilita tak není omezována technickými překážkami, ale ukázalo se, že hlavní výzvou není technické řešení, ale schopnost organizovat roztříštěný vývoj tak, aby celkový produkt byl v každém okamžiku konzistentní a jednotlivé změny na sebe nemusely čekat do synchronizovaných (tedy neagilních) release.

Jinými slovy je třeba mít na paměti, že ačkoli je nová generace web technologií z pohledu uživatele jednoznačně krokem vpřed, není to mýtická „silver bullet“, která by vyřešila technické problémy generace současné (a už vůbec ne ty netechnické), možná spíše naopak, přidává výzvy nové.

František Řezáč František Řezáč
Autor článku je konzultantem společnosti Profinit. Na problematiku web frontendů pro finanční instituce se profesně zaměřuje již více než 6 let. Přes 10 let se zabývá moderními trendy v softwarovém inženýrství a jejich implementací v prostředí enterprise informačních systémů.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.