API, application programming interface ˇci ˇcesky aplikaˇcn´ı programov´e rozhran´ı, je v kontextu webov´ych sluˇzeb takov´e rozhran´ı, kter´e je pˇr´ıstupn´e po webu, nejˇcastˇeji pak prostˇrednictv´ım protokolu HTTP. Jeho smyslem je jasnˇe definovat strukturu zdroj˚u, kter´e dan´y server implementuj´ıc´ı toto rozhran´ı poskytuje a kter´e tak pro-gram´ator m˚uˇze vyuˇz´ıt. V´yhodou pak samozˇrejmˇe je, ˇze program´atora nezaj´ım´a konkr´etn´ı implementace na stranˇe serveru, kter´y rozhran´ı implementuje. Jeho objek-tem z´ajmu z˚ust´av´a pouze rozhran´ı jako takov´e a jeho specifikace. Vzhledem k tomu, ˇze aplikaˇcn´ı server je navrhov´an jako poskytovatel webov´ych sluˇzeb, pak i on bude implementovat API urˇcit´ych specifikovan´ych sluˇzeb a funkcionalit s pouˇzit´ım stylu REST.
5.3.1 N´ astroje a jazyky specifikace
Pro definici navrhovan´eho API je moˇzn´e vyuˇz´ıt v´ıcero volnˇe dostupn´ych n´astroj˚u a jazyk˚u, se kter´ymi tyto n´astroje pracuj´ı. Patˇr´ı mezi nˇe:
• API Blueprint (viz [16]),
• Swagger (viz [17]),
• RAML (viz [18]).
Prvnˇe uveden´y jazyk je hostovateln´y ve sluˇzbˇe Apiary.com. Pomoc´ı n´ı lze online vytv´aˇret a sd´ılet vyv´ıjen´a API. Druh´y a tˇret´ı jazyk jsou zaloˇzeny na form´atu YAML, coˇz je form´at pro serializaci strukturovan´ych dat. Takto zapsan´y k´od je ˇciteln´y d´ıky pomˇernˇe pˇr´ısn´ym poˇzadavk˚um na jeho form´atov´an´ı. Pro oba tyto jazyky jsou dostupn´e i webov´e editory, kter´e m˚uˇze uˇzivatel hostovat i lok´alnˇe, a prostˇrednictv´ım kter´ych m˚uˇze vyv´ıjet sv´e specifikace. Zaj´ımavou moˇznost´ı je pak u vˇsech n´astroj˚u uveden´ych jazyk˚u tzv. mocking service, ˇcesky simulovan´a sluˇzba. Pˇri jej´ı aktivaci jsou dan´e editory schopny spustit server, kter´y simuluje pr´avˇe vyv´ıjen´e rozhran´ı.
V´yvoj´aˇr tak m´a dalˇs´ı moˇznost, jak si ovˇeˇrit svoje navrhovan´e API.
5.3.2 Reprezentace zdroj˚ u
Pro ´uˇcely specifikace API aplikaˇcn´ıho serveru byl zvolen jazyk RAML. Vzhledem k tomu, ˇze API mus´ı b´yt pˇr´ıstupn´e minim´alnˇe po lok´aln´ı s´ıti, je potˇreba definovat strukturu URL. Jako vhodn´y a obecnˇe doporuˇcovan´y form´at je uv´adˇen n´asleduj´ıc´ı:
https://api/v1/requested/resource?params
M´ısto slova api m˚uˇze b´yt uvedena IP adresa ˇci FQDN serveru. Za lom´ıtkem pak n´asleduje ´udaj o pouˇzit´e verzi. V tomto pˇr´ıpadˇe v1. Za dalˇs´ım lom´ıtkem se pak nach´az´ı cesta zdroje s potˇrebn´ymi parametry.
Jako form´at pˇren´aˇsen´ych dat (pro poˇzadavky i pro odpovˇedi) je moˇzn´e zvolit z v´ıcero nab´ızen´ych, mezi kter´e se ˇrad´ı napˇr. XML, JSON, ˇci prost´y text. S ohledem na skuteˇcnost, jak´e aplikace s n´ım budou pracovat, byl vybr´an form´at JSON. Ten je platformovˇe nez´avisl´y, s moˇznost´ı z´apisu objekt˚u, pol´ı a samozˇrejmˇe i prost´ych hodnot.
Meta objekt
Kaˇzd´a odpovˇed’ by ide´alnˇe mˇela obsahovat URL, ze kter´e je dan´y zdroj pˇr´ıstupn´y.
Nebo-li pˇresnˇe tu URL, kter´a byla v poˇzadavku pˇred´ana serveru, podle kter´e pak server poˇzadavek zpracoval a vr´atil odpovˇed’. Tato URL tedy jednoznaˇcnˇe identi-fikuje zdroj. Toho lze dos´ahnout za pouˇzit´ı r˚uzn´ych technik. Zde pouˇzitou je pˇrid´an´ı meta objektu do odpovˇedi, kter´y pak obsahuje atribut href. Do nˇej se URL zdroje vkl´ad´a. Tento objekt je zn´azornˇen na n´asleduj´ıc´ı uk´azce 5.1.
Uk´azka 5.1: Meta odkaz
Odpovˇed’ typu z´aznam odpov´ıd´a sv´ym obsahem a z´apisem jednomu konkr´etn´ımu zdroji specifikovan´emu pomoc´ı jeho jedineˇcn´e URL. Kromˇe samotn´ych dat zdroje
obsahuje t´eˇz meta objekt, jak je pops´ano v´yˇse. Na uk´azce 5.2 je uvedena odpovˇed’
aplikaˇcn´ıho serveru pˇri z´ısk´an´ı konkr´etn´ıho schematu s´ıtˇe identifikovan´eho pomoc´ı jeho identifik´atoru s hodnotou 1.
Jak jiˇz n´azev napov´ıd´a, tak odpovˇed’ typu kolekce z´aznam˚u obsahuje v´ıce jed-notliv´ych z´aznam˚u. Ty jsou pˇren´aˇseny v objektu items. Kromˇe pˇren´aˇsen´ych z´aznam˚u obsahuje t´eˇz meta objekt, a dalˇs´ı objekty potˇrebn´e pro str´ankov´an´ı. Tˇemi jsou first, previous, next, last. Obsahem kaˇzd´eho z tˇechto objekt˚u je zase meta objekt, ale jiˇz s konkr´etn´ımi parametry URL pro proveden´ı str´ankov´an´ı. Strukturu odpovˇedi typu kolekce z´aznam˚u zachycuje uk´azka 5.3. Poˇzadavek, pˇredch´azej´ıc´ı t´eto zde uveden´e odpovˇedi, poˇzadoval seznam schemat. Vzhledem k implicitnˇe zapnut´emu str´ankov´an´ı se omezil pouze na jeho prvn´ı str´anku. O technice str´ankov´an´ı bl´ıˇze pojedn´av´a odstavec tomu vˇenovan´y v kapitole 5.3.4.
5.3.3 Princip HATEOAS
HATEOAS, nebo-li Hypermedia as the Engine of Application State ˇci ˇcesky hy-perm´edia jako aplikaˇcn´ı stav, je jeden ze z´akladn´ıch princip˚u REST architektury.
Jeho princip spoˇc´ıv´a v tom, ˇze aplikace komunikuje s aplikaˇcn´ım serverem skrze dy-namicky poskytovan´e m´edium. Aplikace nepotˇrebuje m´ıt ˇz´adn´e pˇredchoz´ı znalosti o tom, jak komunikovat s libovolnou ˇc´ast´ı aplikaˇcn´ıho serveru. T´ım je dosaˇzena jist´a univerz´alnost, protoˇze t´ımto zp˚usobem lze dynamicky rozˇsiˇrovat funkcionalitu.
Tento princip je patrn´y na uk´azce 5.3. Poˇzadavek byl proveden na URL:
https://api/v1/schemes/?pageNumber=1
To v pˇrekladu znamen´a, ˇze poˇzadavek se dotazoval na seznam schemat. Vzhle-dem k zapnut´emu str´ankov´an´ı si vyˇz´adal pouze prvn´ı str´anku (tuˇcnˇe zv´yraznˇeno).
Odpovˇed’ z uk´azky 5.3 na tento poˇzadavek obsahuje odkaz na dalˇs´ı str´anku (v tomto pˇr´ıpadˇe str´anku ˇc. 2), coˇz je pˇresnˇe d´ıky principu HATEOAS. T´ım je dosaˇzeno toho, ˇze odpovˇed’ na poˇzadavek obsahuje de facto pˇr´ıkazy, co m´a klient udˇelat, aby z´ıskal jinou str´anku. Obecnˇe je tedy c´ılem v odpovˇedi popisovat kromˇe dat jako takov´ych i operace, kter´e s nimi m˚uˇze uˇzivatel prov´adˇet.
Uk´azka 5.3: Kolekce z´aznam˚u
Vyhled´av´an´ı je technika filtrov´an´ı zdroj˚u podle zadan´ych parametr˚u. Kaˇzd´y iden-tifikovan´y zdroj m´a specifikov´ano, zda-li lze pro nˇej vyhled´av´an´ı pouˇz´ıt a pˇr´ıpadnˇe na jak´e jeho atributy. Vyhled´av´an´ı je vhodn´e pouˇz´ıt pouze ve spojen´ı s odpovˇed´ı typu kolekce. N´asleduj´ıc´ı URL ukazuje zp˚usob z´apisu parametr˚u pro vyhled´av´an´ı.
V tomto pˇr´ıpadˇe se poˇzadavek dotazuje na takov´a schemata, kter´a maj´ı atribut verze (version) v hodnotˇe 1 a z´amek (lock) v hodnotˇe 0.
https://api/v1/schemes?q=(version=1;lock=0) Razen´ıˇ
Za pomoci ˇrazen´ı je moˇzn´e danou sadu vyhledan´ych v´ysledk˚u seˇradit podle zadan´ych atribut˚u. ˇRazen´ı je pouˇziteln´e pouze ve spojen´ı s odpovˇed´ı typu kolekce. N´asleduj´ıc´ı URL ukazuje zp˚usob z´apisu parametr˚u pro ˇrazen´ı. V tomto pˇr´ıpadˇe se poˇzadavek dotazuje na vˇsechna existuj´ıc´ı schemata s´ıt´ı. Tuto kolekci pak seˇrad´ı podle verze (version) vzestupnˇe a podle z´amku (lock) sestupnˇe. Smˇery ˇrazen´ı (vzestupnˇe, sestupnˇe) lze vynechat, a pot´e se implicitnˇe pouˇzije vzestupn´y smˇer.
https://api/v1/schemes?s=(version:asc,lock:desc) Rozˇs´ıˇren´ı pohledu
Rozˇs´ıˇren´ı pohledu je jedin´a technika z uveden´ych, kterou m´a smysl pouˇz´ıt ve spo-jen´ı jak s odpovˇed´ı typu z´aznam tak i s kolekc´ı z´aznam˚u. Jeho smyslem je rozˇs´ıˇrit, nebo-li expandovat, dan´y objekt, pokud ten je rozˇsiˇriteln´y. To se m˚uˇze st´at napˇr.
u datab´azov´eho dotazu skrze v´ıce entit, nebo v pˇr´ıpadˇe specifick´eho n´avrhu API a z´avislost´ı mezi jednotliv´ymi zdroji. Je vˇsak nutn´e toto peˇclivˇe zv´aˇzit, protoˇze ˇspatn´e pouˇzit´ı t´eto techniky by zbyteˇcnˇe zatˇeˇzovalo zpracov´an´ı poˇzadavk˚u napˇr.
jejich ne´umˇernou a zbyteˇcnou hloubkou rozˇs´ıˇren´ı. N´asleduj´ıc´ı URL demonstruje
poˇzadavek dotazuj´ıc´ı se na seznam vˇsech schemat. Jednotliv´e poloˇzky v objektu items pak budou rozˇs´ıˇreny o jejich vlastn´ı obsah. Standardnˇe by totiˇz tento objekt obsahoval pouze meta objekty odkazuj´ıc´ı na konkr´etn´ı schema.
https://api/v1/schemes?e=(scheme) Str´ankov´an´ı
Smyslem str´ankov´an´ı je omezen´ı mnoˇziny pˇren´aˇsen´ych dat v odpovˇedi tak, aby p˚uvodce poˇzadavku nebyl zahlcen jejich velk´ym objemem. Proto se po aplikov´an´ı vyhled´avac´ıch a ˇrad´ıc´ıch krit´eri´ı nalezen´y v´ysledek rozdˇel´ı do str´anek s poˇzadovanou velikost´ı. V odpovˇedi je pak navr´acena pouze konkr´etn´ı poˇzadovan´a str´anka. Tuto techniku je vhodn´e pouˇz´ıt pouze ve spojen´ı s odpovˇed´ı typu kolekce. N´asleduj´ıc´ı URL demonstruje zp˚usob v´ybˇeru str´anky pomoc´ı parametru pageNumber a jej´ı velikosti pomoc´ı pageSize.
https://api/v1/schemes?pageSize=25&pageNumber=1
5.3.5 Identifikovan´ e zdroje
Pro funkcionalitu platformy byly identifikov´any n´asleduj´ıc´ı zdroje nejvyˇsˇs´ı ´urovnˇe:
schema (scheme), uzlov´y bod (node), ´usek (section), mapov´y bod (map point), objekt (object), opr´avnˇen´ı (permission), ´uloha (task), vykonavatel (executor) a uˇzivatel (user). Jejich pˇresn´e uspoˇr´ad´an´ı, pouˇzit´e techniky, form´aty odpovˇed´ı atd.
jsou pˇredmˇetem proveden´e specifikace a jsou pops´any pˇr´ısluˇsn´ym RAML souborem vˇcetnˇe uk´azkov´ych odpovˇed´ı form´atovan´ych pomoc´ı JSON.
5.4 Implementace
5.4.1 V´ ybˇ er frameworku
Za pˇredpokladu, ˇze jako programovac´ı jazyk je vybr´an PHP, tak pro danou im-plementaci je moˇzn´e zvolit z nespoˇctu r˚uzn´ych webov´ych framework˚u. Mezi ˇcasto pouˇz´ıvan´e lze zaˇradit napˇr. Zend, Symphony, Nette ˇci CakePHP. Mezi v´yhody pouˇzit´ı jak´ehokoli frameworku lze uv´est mnoˇzstv´ı pˇripraven´ych komponent, tech-nologi´ı, postup˚u ˇci komunitu vˇenuj´ıc´ı se tomu dan´emu frameworku.
Na poli dostupn´ych PHP framework˚u se vˇsak vyskytuje jeden, kter´y je kon-cipov´an odliˇsnˇe od pˇredchoz´ıch. T´ımto frameworkem je Phalcon (viz [19]). Pˇrestoˇze se jedn´a o pomˇernˇe mlad´y framework, jehoˇz poˇc´atky sahaj´ı teprve do roku 2012, tak jeho ˇs´ıˇri a moˇznosti lze porovn´avat s pˇredeˇsl´ymi. Stˇeˇzejn´ım rozd´ılem je zp˚usob jeho pouˇzitelnosti, resp. distribuovatelnosti. Zat´ımco bˇeˇzn´e frameworky se distribuuj´ı jako samostatn´e PHP projekty, kter´e interpret jazyka PHP mus´ı za bˇehu interpreto-vat, tak Phalcon je distribuov´an jako pˇr´ım´e rozˇs´ıˇren´ı PHP a pˇripojuje se tak jiˇz pˇri sam´em startu interpreta PHP. Interpret tak n´aslednˇe interpretuje pouze vytvoˇrenou aplikaci a framework, jako takov´y, jiˇz nikoli. S t´ım tak´e souvis´ı skuteˇcnost, ˇze Phal-con je internˇe kompilov´an do jazyka C. Tato kompilace z nˇej vytvoˇr´ı rozˇs´ıˇren´ı pro
PHP, kter´e pak lze k interpretu PHP pˇripojit. A pr´avˇe jeho existence je d˚uvodem, proˇc byl pro ´uˇcely tvorby aplikaˇcn´ıho serveru vybr´an.
5.4.2 Architektura
Aplikaˇcn´ı server je zaloˇzen na architektuˇre MVC, coˇz je softwarov´a architektura oddˇeluj´ıc´ı datov´y model, uˇzivatelsk´e rozhran´ı a ˇr´ıd´ıc´ı logiku. V tomto okamˇziku je nutn´e uv´est, ˇze veˇsker´e odpovˇedi serveru jsou realizov´any pomoc´ı textov´eho v´ystupu form´atovan´eho prostˇrednictv´ım JSON. To znamen´a, ˇze uˇzivatelsk´e rozhran´ı figu-ruje pouze do ´urovnˇe form´atov´an´ı v´ystupu, pˇriˇcemˇz v´ystupem je prakticky strojov´y form´at dat a nikoli GUI. To je ale pˇresnˇe ta funkcionalita, kter´a je od aplikaˇcn´ıho serveru v kontextu platformy oˇcek´av´ana.
Kaˇzd´y zdroj, kter´y byl identifikov´an v kapitole 5.3.5, zde vytv´aˇr´ı vlastn´ı kon-trol´er (controller). Ten je zodpovˇedn´y za veˇskerou ˇr´ıd´ıc´ı logiku pro jednotliv´e zdroje v nˇem implementovan´e. Vˇsechny takto vznikl´e kontrol´ery maj´ı spoleˇcn´eho pˇredka tzv. ControllerBase, kter´y nad nimi zajiˇst’uje ovˇeˇren´ı pˇr´ıstupu pro kaˇzd´y pˇr´ıchoz´ı poˇzadavek. Vzhledem k tomu, ˇze vˇsechny zdroje jsou pˇr´ıstupn´e pouze autorizovan´ym uˇzivatel˚um, resp. jejich poˇzadavk˚um s validn´ım pˇr´ıstupov´ym k´odem, tak tento je-jich spoleˇcn´y pˇredek pr´avˇe toto ovˇeˇren´ı prov´ad´ı. Ovˇeˇren´ı spoˇc´ıv´a v tom, ˇze se hled´a v datab´azi OAuth a entitˇe pˇr´ıstupov´ych k´od˚u (access token) takov´y pˇr´ıstupov´y k´od, kter´y existuje a kter´y je v ˇcase pˇrijet´ı poˇzadavku ˇcasovˇe platn´y. V opaˇcn´em pˇr´ıpadˇe je pak vygenerov´ana odpovˇed’ s n´avratov´ym chybov´ym k´odem 403, kter´y oznamuje neautorizovan´y pˇr´ıstup ke zdroji.
Pro ´uˇcely splnˇen´ı poˇzadavku z kapitoly 3.1, kter´y poˇzadoval omezen´ı pˇr´ıstupu na ´urovni schematu, byla vytvoˇrena komponenta ACL. Jej´ım ´uˇcelem je pˇri kaˇzd´em pˇr´ıstupu ke schematu ovˇeˇrit, zda-li pˇristupuj´ıc´ı uˇzivatel se svoj´ı identitou m´a takov´e opr´avnˇen´ı, kter´e by mu toto dovolovalo. Pro rozliˇsen´ı jednotliv´ych druh˚u opr´avnˇen´ı k pˇr´ıstupu ke schematu byla zvolena textov´a reprezentace ve form´atu RWX, kdy R oznaˇcuje opr´avnˇen´ı ke ˇcten´ı, W pak opr´avnˇen´ı z´apisu a X opr´avnˇen´ı k zad´an´ı a ´upravˇe v´ypoˇcetn´ı ´ulohy. Opr´avnˇen´ı je v´az´ano k identitˇe uˇzivatele a pˇr´ısluˇsn´emu schematu. Uchov´av´a se v datab´azi s´ıtˇe (network) v entitˇe opr´avnˇen´ı (permission).
D´ıky ˇsirok´emu rozsahu funkˇcnosti pracuje tato implementace s modely z v´ıce datab´az´ı, konkr´etnˇe S´ıt’ (viz pˇr´ıloha C), Poskytovatel identit (viz pˇr´ıloha A), OAuth (viz pˇr´ıloha B) a tak´e V´ypoˇcetn´ı ´ulohy (viz pˇr´ıloha D). D´ale je zde pouˇzita technika ORM, coˇz v pˇrekladu znamen´a objektovˇe relaˇcn´ı mapov´an´ı. To spoˇc´ıv´a v mapov´an´ı objekt˚u, v tomto pˇr´ıpadˇe model˚u aplikace, na jejich ekvivalenty v datab´azi.
5.4.3 Zabezpeˇ cen´ı
I v r´amci v´yvoje webov´ych sluˇzeb, resp. aplikaˇcn´ıho serveru poskytuj´ıc´ıho webov´e sluˇzby, je nutn´e uvaˇzovat potenci´aln´ı zranitelnosti, kter´e s t´ım souvisej´ı. Mezi z´akladn´ı typy tˇechto zranitelnost´ı patˇr´ı XSS (viz [20]), SQL Injection (viz [21]) a CSRF (viz [22]). K oˇsetˇren´ı tˇechto zranitelnost´ı existuj´ı doporuˇcen´e postupy, kter´e mini-malizuj´ı moˇznost proveden´ı ´utok˚u.
Zranitelnosti XSS a SQL Injection jsou si do jist´e m´ıry podobn´e. Ke sv´emu
´
uˇcelu potˇrebuj´ı modifikovan´y vstup od uˇzivatele. Jejich rozd´ılem je pak m´ısto, kam se ˇskodliv´y k´od pˇred´av´a a co m´a zp˚usobit. Zranitelnost typu XSS c´ıl´ı na JavaScriptov´y k´od, kdy v pˇr´ıpadˇe nevhodnˇe oˇsetˇren´ych vstup˚u m˚uˇze b´yt zadan´y k´od proveden. Pokud k takov´emu proveden´ı dojde, existuje riziko zneuˇzit´ı vlastn´ıch dat. Naopak zranitelnost typu SQL Injection vyuˇz´ıv´a upraven´y vstup uˇzivatele k z´ısk´an´ı dat z datab´aze, kdy lze pomoc´ı ˇspatnˇe oˇsetˇren´ych vstup˚u sestavovat libo-voln´e dotazy, kter´e budou n´aslednˇe nad datab´az´ı provedeny. Mezi z´akladn´ı techniky oˇsetˇren´ı vstup˚u se pouˇz´ıvaj´ı regul´arn´ı v´yrazy, odstranˇen´ı b´ıl´ych znak˚u po stran´ach ˇretˇezce a escapovan´ı znak˚u. T´eˇz se vyuˇz´ıvaj´ı tzv. pˇripraven´e dotazy (prepared state-ments), kter´e pˇredchoz´ı techniky korektnˇe implementuj´ı v r´amci zvolen´eho frame-worku. Aplikaˇcn´ı server vyuˇz´ıv´a pˇripraven´e dotazy pro komunikaci s datab´azemi, takˇze v´yˇse uveden´a rizika jsou minimalizov´ana.
Dalˇs´ı zranitelnost´ı je CSRF, coˇz je ´utok spoˇc´ıvaj´ıc´ı v tom, ˇze uˇzivatel je donucen navˇst´ıvit str´anku, kter´a skrytˇe vykon´a ´utok na webovou aplikaci, kde je uˇzivatel zrovna pˇrihl´aˇsen. Oˇsetˇren´ım t´eto zranitelnosti je generov´an´ı jedineˇcn´eho k´odu pro kaˇzdou akci, kter´a sv´ym proveden´ım mˇen´ı data. Pˇred proveden´ım akce se pak zkon-troluje poslan´y a pˇredem vygenerovan´y k´od. Tyto k´ody se mus´ı shodovat. V opaˇcn´em pˇr´ıpadˇe je moˇzn´e, ˇze se jedn´a o ´utok. Zde je vhodn´e vzpomenout, ˇze zde exis-tuje v´ıce moˇznost´ı, jak toto zabezpeˇcen´ı realizovat. Nejdˇr´ıve je nutn´e si uvˇedomit, ˇze v r´amci poˇzadovan´eho zabezpeˇcen´ı pˇr´ıstupu k aplikaˇcn´ımu serveru je nutn´y validn´ı pˇr´ıstupov´y k´od. Ten se vytv´aˇr´ı na z´akladˇe ´uspˇeˇsn´e autentizace a autorizace, pˇriˇcemˇz je tvaru n´ahodn´eho ˇretˇezce urˇcit´e d´elky. Uˇz to samo o sobˇe je urˇcitou m´ırou zabezpeˇcen´ı, jelikoˇz bez jeho existence bude poˇzadavek vˇzdy zam´ıtnut. Vyuˇz´ıv´a se tak´e jako sd´ılen´y k´od pr´avˇe pro potˇreby CSRF. Vylepˇsen´ım tohoto postupu by bylo generov´an´ı dalˇs´ıho k´odu pro potˇreby CSRF, kter´y by byl sv´az´an s pˇr´ıstupov´ym k´odem. To by bylo v´yhodn´e zejm´ena kv˚uli faktu, ˇze by existovaly dva rozd´ıln´e k´ody a bylo by tak obecnˇe sloˇzitˇejˇs´ı je zjistit. Posledn´ım vylepˇsen´ım by bylo pˇredeˇsl´y k´od pro CSRF aktualizovat pˇri kaˇzd´em pˇrijet´ı poˇzadavku mˇen´ıc´ıho stav dat. Po jeho proveden´ı by byl v odpovˇedi zasl´an novˇe vygenerovan´y k´od, kter´y by slouˇzil pro ovˇeˇren´ı dalˇs´ıho poˇzadavku.
5.5 Testov´ an´ı
Testov´an´ı t´eto komponenty prob´ıhalo za pomoc´ı n´asleduj´ıc´ıch technik. Po vytvoˇren´ı k´odu byl k´od testov´an program´atorem. Vzhledem k existenci objekt˚u, u kter´ych mˇelo smysl je podrobit jednotkov´emu testov´an´ı, byly tyto objekty testov´any za pomoc´ı PHPUnit, coˇz je knihovna pro psan´ı jednotkov´ych test˚u, kterou lze vyuˇz´ıt i v pˇr´ıpadˇe projektu zaloˇzen´em na frameworku Phalcon. Nad celou komponentou pak probˇehlo syst´emov´e testov´an´ı, jenˇz mˇelo za ´ukol ovˇeˇrit jej´ı funkˇcnost. To bylo provedeno za pomoci n´astroje Codeception, coˇz je n´astroj poskytuj´ıc´ı v´ıce kategori´ı test˚u. Pro testov´an´ı na ´urovni syst´emov´eho byl zvolen modul pro testov´an´ı REST API. Pro nˇej byla vytvoˇrena sada sc´en´aˇr˚u, kter´e testovaly pr´aci s jednotliv´ymi implementovan´ymi zdroji. Uveden´ym testov´an´ım komponenta proˇsla.
5.6 Provozn´ı prostˇ red´ı
Aplikaˇcn´ı server je naps´an ve skriptovac´ım jazyce PHP a t´ım p´adem je pro nˇej potˇrebn´e zajistit interpret, kter´y jej prov´ad´ı. T´ım je PHP-FPM, kter´y se spouˇst´ı z webov´eho serveru. Jako webov´y server je zvolen Nginx, d´ıky sv´emu pˇrehledn´emu a snadn´emu nastaven´ı a tak´e z hlediska v´ykonu. Samozˇrejmˇe je moˇzn´e zvolit i jinou kombinaci. V tom pˇr´ıpadˇe bude ale nutn´e upravit pravidla pro pˇrepisov´an´ı URL, protoˇze aplikaˇcn´ı server obsahuje v tento moment pouze pravidla pro pouˇzit´ı s Nginx serverem.
Kv˚uli zajiˇstˇen´ı bezpeˇcn´e komunikace mezi aplikaˇcn´ım serverem a ostatn´ımi kom-ponentami jsou jeho webov´e sluˇzby dostupn´e pouze pomoc´ı HTTPS protokolu, coˇz je nadstavba s´ıt’ov´eho protokolu TCP, kter´a umoˇzˇnuje zabezpeˇcit komunikaci mezi klientem a serverem pomoc´ı ˇsifrov´an´ı. Ke spr´avn´e funkci ˇsifrov´an´ı je zapotˇreb´ı, aby server disponoval platn´ym certifik´atem, kter´ym je komunikace ˇsifrov´ana. Za zm´ınku stoj´ı moˇznost z´ısk´an´ı validn´ıho certifik´atu od certifikaˇcn´ı autority Let’s Encrypt, kter´a na sklonku roku 2015 zaˇcala takov´eto nekomerˇcn´ı certifik´aty vyd´avat, aby podpoˇrila ˇsifrovan´y provoz na webu. S pouˇzit´ım ˇsifrovan´eho spojen´ı je vhodn´e jeˇstˇe nastavit HSTS hlaviˇcku (viz [23]), kter´a prohl´ıˇzeˇci ˇr´ık´a, zda m´a pouˇz´ıvat ˇsifrovan´e spojen´ı pro dan´y pˇr´ıstup k serveru. Rovnˇeˇz je moˇzn´e v aktu´aln´ı verzi Nginx aktivo-vat podporu protokolu HTTP2 (viz [24]), kter´y poskytuje urˇcit´e v´yhody z hlediska v´ykonu. To je d´ano t´ım, ˇze se jedn´a o bin´arn´ı protokol, kter´y podporuje multi-plexov´an´ı poˇzadavk˚u a kter´y ˇreˇs´ı i komprimaci pˇren´aˇsen´ych hlaviˇcek. Na serveru je tak´e nutn´e nastavit CORS (viz [25]), aby byla zajiˇstˇena podpora v pˇr´ıpadˇe poˇzadavk˚u z jin´e dom´eny.