ZADÁNÍ DIPLOMOVÉ PRÁCE

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická katedra počítačů ZADÁNÍ DIPLOMOVÉ PRÁCE Student: Bc. Valentin Kostělej Studijní program: Elektrotechnika a informatika (magisterský), strukturovaný Obor: Výpočetní technika Název tématu: Rezervační systém pro dárce krevní plazmy Pokyny pro vypracování: Analyzujte stávající rezervační systém dárců krevní plazmy. Systém využívá 8 nemocnic a plasmaferetíckých center po celé ČR. Celkem je registrováno více než aktivních uživatelů Aktuální systém je napsán v PHP nad MySQL databází, což aktuálné bráni rozšiřování uživatelské základny. Navrhněte a vytvořte zcela novou internetovou aplikaci zaměřenou na online rezervace. Systém bude umožňovat, kromě jiného, kompletní správu skrze webové rozhraní, selfprovisioning (zprovoznění a nastaveni systému zákazníkem), propojení s rozhraním pro SMS notifikace, rozsáhlé možnosti nastavení rezervačních prostředků a časových harmonogramů. Seznam všech nutných funkčních požadavků konzultujte se zadavatelem. Systém otestujte jak z hlediska správné funkcionality, tak z pohledu uživatelského rozhraní s reálnými uživateli. Seznam odborné literatury: Dodá vedoucí práce Vedoucí: Ing. David Sedláček Platnost zadání: do konce letního semestru 2013/2014 L. S. doc. Ing. Miroslav Šnorek, CSc. vedoucí katedry prof. Ing. Pavel Ripka, CSc. děkan V Praze dne

2 ii

3 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Rezervační systém pro dárce krevní plazmy Bc. Valentin Kostělej Vedoucí práce: Ing. David Sedláček Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 30. dubna 2013

4 iv

5 v Poděkování Chtěl bych poděkovat vedoucímu práce za rady při volbě tématu. Mému bratrovi Pavlovi hlavně za technické připomínky. Haně Ptáčkové, kamarádce a studentce 1. LF Karlové Univerzity, za gramatické opravy. A všem lidem, kteří mi ukázali, že stačí na sebe tlačit o něco víc a dostat se k cíli.

6 vi

7 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Bílině dne

8 viii

9 Abstract Booking system for blood plasma donors is information system for booking and people administration. System is fully modular and safe. Also is fully portable and fully visually editable thanks to jquery UI. Abstrakt Rezervační systém pro dárce krevní plasmy je informační systém pro rezervace a správu lidí. Je plně rozšířitelný a bezpečný. Také plně přenositelný a plně vzhledově upravitelný díky jquery UI. ix

10 x

11 Obsah 1 Úvod 1 2 Analýza Zadání a řešení úkolu Use Case a funkční požadavky Architektura Závěr řešení Návrh řešení Databáze CENTRÁLY Databáze LOKÁLU Osoba Objekt Otevírací doba Jednotka a nedostupná doba Ostatní tabulky LOKÁL - PHP Přihlášení Změna hesla KLIENT Závěr Implementace Implementace LOKÁLU - PHP Jádro Moduly - PHP private/aes.php private/jed_local.php a private/otv_local.php Ostatní moduly API PHP modulů Nový modul - PHP Implementace KLIENTA API a Hlavní okno Moduly - KLIENT tabs/uvod.html a aktualita.html tabs/lidi.html xi

12 xii OBSAH tabs/darovani.html tabs/objekt.html, profile.html a system.html Nový modul - KLIENT Výhled do budoucnosti 37 6 Testování a použité nástroje Úvod Použité nástroje Vlastní testování PHP a MySQL HTML a JavaScript aplikace NetBeans php Uživatelské testování Závěr Závěr 43 A Příručky úvod 47 B Návod pro uživatele 49 B.1 Úvod B.2 Požadavky B.3 Úvodní stránka B.3.1 Otevírací doba B.4 Darování B.4.1 Výběr data B.4.2 Výběr času B.4.3 Rekapitulace B.4.4 Změna a odstranění B.4.5 Moje rezervace B.4.6 Události B.5 Můj profil C Návod pro redaktora 59 C.1 Úvod C.2 Změna od běžného uživatele C.3 Správa lidí C.3.1 Nová registrace C.3.2 Upravit osobu C.3.3 Výpis lidí C.3.4 Výpis rezervací C.3.5 Události C.3.6 Vzkazy

13 OBSAH xiii C.4 Často kladené otázky D Návod pro administrátora 69 D.1 Úvod D.2 Správa objektu D.2.1 Rozvrh D.2.2 Jednotky D.2.3 Nastavení E Návod pro guru 75 E.1 Správa systému E.1.1 Objekty E.1.2 Import E.1.3 Logy E.2 Nový objekt F Instalační příručka 79 F.1 Požadavky F.2 Instalace F.3 SLAVE server F.4 Konfigurace G Obsah přiloženého CD 85

14 xiv OBSAH

15 Seznam obrázků 2.1 Starší systém Use case Základní architektura Rozšířená architektura Síť CENTRÁLA Osoba Objekt Otevírací doba Jednotka a nedostupná doba Zamluvení termínu Rezervace termínu Výhled do budoucnosti B.1 Úvodní stránka B.2 Otevírací doba B.3 Výběr data B.4 Výběr času B.5 Rekapitulace B.6 Moje rezervace B.7 Moje rezervace B.8 Události B.9 Můj profil B.10 Změna hesla B.11 Vzkazy C.1 Správa aktualit C.2 Hledání uživatele C.3 Nová registrace C.4 Upravit osobu C.5 Výpis lidí C.6 Výpis rezervací C.7 Události C.8 Nová událost xv

16 xvi SEZNAM OBRÁZKŮ C.9 Upravit lidi C.10 Vzkazy C.11 Nový vzkaz C.12 Cizí rezervace D.1 Rozvrh D.2 Otevírací doba D.3 Jednotky D.4 Nedostupní doba D.5 Nastavení D.6 Odběry E.1 Objekty E.2 Import E.3 Logy F.1 phpmyadmin F.2 index.php - úvod F.3 index.php - výpis F.4 Kate - soubory

17 Kapitola 1 Úvod Téma diplomové práce je Rezervační systém pro dárce krevní plasmy. S tím souvisí velká zodpovědnost, systém musí být bezpečný a také přehledný. Systém bude spravovat data uživatelů a termíny odběrů krevní plasmy, která denně zachraňuje životy mnoha lidí. Starší systém potřeboval rozšíření, a tak vznikla tato práce. Nový systém využívá technologie MySQL, PHP, HTML a JavaScript. Též prostředí jquery a jquery UI. Stejně jako tyto technologie, systém je plně rozšířitelný díky modulům. A jelikož jquery UI je graficky měnitelné pomocí grafických témat, vzhled systému můžete kdykoliv upravit dle svých představ. Kromě běžných úkonů rezervačního systému, tento informační systém dokáže plně nahradit hlavní webové stránky menší odběrné stanice nebo může být využit k obecné správě prostředků a lidí. Systém spravuje převážně separátory, které odebírají krevní plasmu. Krevní plasma se dále zpracovává a pomáhá zachraňovat lidské životy. Také se z ní vyrábí různé druhy léčiv pro popálené pacienty, pacienty s rakovinou nebo se špatnou srážlivostí krve. Díky novému systému nyní můžete provádět rezervace nejen darování krevní plasmy, ale i například krve. Můžete přidávat nebo odebírat odběrné jednotky. Spravovat otevírací dobu nebo dobu, kdy je přistroj mimo provoz. A to i s týdenním opakováním. Můžete různě měnit časovou délku různých druhů darování, nastavit interval mezi odběry nebo nastavit limit dnů dopředu, kdy můžete provést rezervaci. A to s přesností na minuty. V následujících kapitolách si přiblížíme pohled na různé oblasti systému, instalace, uživatelské prostředí a budoucí vývoj. 1

18 2 KAPITOLA 1. ÚVOD

19 Kapitola 2 Analýza 2.1 Zadání a řešení úkolu Hlavní úkol je zachovat předešlou funkčnost starého systému a rozšířit ji o novou. Analýza starého systému ukázala, že oprava a rozšíření starého systému je náročná a musel bych skoro celý systém přepsat od základu. Proto začal vývoj na zelené louce, tedy od nuly. Měl jsem už částečně rozpracovaný systém na správu uživatelů, a po větší úpravě architektury jsem využil jeho základy. Starší systém využíval technologie PHP a MySQL server, nový systém obsahuje i tyto základy. Obrázek 2.1: Starší systém Obrázek 2.1 ukazuje vzhled starého systému. Starší systém měl jen základní grafické rozhraní pouze s hodinovými sloty, takže neumožňoval rezervaci přesně na minuty. V přílohách najdete soubor[11], který jsem dostal od zadavatelské společnosti. Ten probereme a doplním ho o další funkčnost. 3

20 4 KAPITOLA 2. ANALÝZA Funkcionalita podporovat procesy spojené s rezervací termínů systém bude generovat základní statistické přehledy veřejně dostupný webový server doba nebude nijak omezena klient bude své rezervace zadávat sám, prostřednictvím grafického rozhraní aplikace bude navržena univerzálně, s nastavitelnými parametry případné modifikace bez hrozby ztráty dat Uživatelé Klient Recepce Správce ovládání má být intuitivní a přehledné vytvořit bezpečnostní opatření přihlášení pomocí u a hesla kontrola odesílaných dat evidence pouze nejnutnějších údajů Základní postupy a pravidla používání konflikt při zapisování dvou uživatelů ve stejný čas interval, během kterého nelze zapsat další rezervace délka doby dopředu bude limitovaná účty tvořeny zaměstnancem vytvořit bezpečnostní opatření přihlašovací údaje budou ová adresa a heslo nastavit otevírací dobu celé stanice

21 2.1. ZADÁNÍ A ŘEŠENÍ ÚKOLU 5 individuální rozvrh pro jednotlivé separátory nastavit mimořádný rozvrh nastavení jména, loga stanice a kontaktů Doplňující charakteristiky nový účet - Recepce, Správce zapsat cizí rezervaci - Recepce, Správce nastavit systém - Správce uživateli je poslán Požadavky na uživatele byly rozšířeny o jednoho uživatele Guru, protože jeden server může mít několik objektů (odběrných míst), což pokrývá toto oprávnění. Přihlášení pomocí u bylo rozšířeno na přihlášení díky čemukoliv, včetně mezer, háčků a čárek. I evidence byla rozšířená na další nepovinné (však nesmí být nulové) údaje. Základní postupy a pravidla používání byly zohledněny skoro ve všech případech, a také byly rozšířeny o zaslání zapomenutého hesla. Požadavky na rozvrh byly také přepracovány, takže na celé roky stačí jedno otevírací pravidlo (pokud nebudou svátky), o tom více v dalších kapitolách. Původní Use-case (Případy užití) diagram byl rozšířen také a můžete ho porovnat s novým v další kapitole. Doplňující charakteristiky byly také rozšířeny. Z poskytnutého souboru tedy byly požadavky zahrnuty, a navíc i rozšířeny o další možnosti. Funkční požadavky zadavatele teď znáte, a můžete si o nich přečíst v přílohách, jdeme tedy na takzvané Nefunkční požadavky, neboli požadavky, které nemají funkci, ovlivňující chování systému, jeho základní vlastnosti. Systém by měl být jednoduchý a rychlý, o čemž se můžete přesvědčit dále. Měl by být přehledný a stabilní, proto byla použita určitá architektura a technologie, o kterých si také povíme dále. Má být samozřejmě i bezpečný, a to jak z pohledu Host-Uživatel (útočník z venku), tak i Uživatel-Zaměstnanec (získání vyššího oprávnění). Nefunkční požadavky jednoduchý rychlý přehledný stabilní bezpečný Popsal jsem požadavky zadavatele, vlastnosti systému a vysvětlil jsem novou funkčnost. V další podkapitole popíšu oprávnění uživatelů, co mohou dělat a jaké jsou funkční požadavky tohoto systému.

22 6 KAPITOLA 2. ANALÝZA 2.2 Use Case a funkční požadavky V této části diplomové práce si povíme, jakých rolí může nabývat uživatel (obrázek 2.2) a co může spravovat, což je vlastně i seznam funkčních požadavků. Obrázek 2.2: Use case Systém rozpoznává 5 rolí Host, Uživatel, Redaktor, Admin na objektu a Guru. Host je nepřihlášený uživatel, který může prohlížet aktuality, otevírací dobu, kontaktní adresu nebo se přihlásit. Až se přihlásí, má alespoň základní oprávnění Uživatel, který v systému má číslo oprávnění 1. Systém ho přesměruje na stránku Darování, kde uživatel může vybrat nový termín nebo upravit stávající rezervace. Zde se dají též vypsat minulé rezervace, nebo se zúčastnit událostí. Ve svém profilu uživatel může zobrazit svoje data, změnit heslo a kontaktní informace, popřípadě přečíst vzkazy od redaktora. Redaktor s oprávněním 2 může na rozdíl od běžného uživatele spravovat cizí rezervace. Též spravuje aktuality a události nebo může poslat jednotlivci, skupině nebo lidem na celém objektu vzkazy. Může vypsat všechny osoby v systému a rezervace na objektu. Také zaregistrovat nového uživatele nebo upravit současného. Uživatel nesmí však mít vyšší oprávnění než 3 Admin na objektu. Ten spravuje otevírací a nedostupní dobu na objektu, adresu a kontaktní údaje. Určuje též časy pro odběry a počet odběrných jednotek nebo separátorů. Vše toto i něco navíc může Guru, který přidává nové objekty nebo typy odběru, čistí staré rezervace, uživatele nebo systémové záznamy. Též může importovat data ze starého systému.

23 2.2. USE CASE A FUNKČNÍ POŽADAVKY 7 Funkční požadavky pro uživatele jsou (dědí se): Host: Zjistit základní informace Zapomenuté heslo Přihlásit se Uživatel: Spravovat svoje termíny Odhlásit se Prohlížet / Přihlásit se na událost Prohlížet / Změnit svoje udaje Prohlížet svoje data Redaktor: Spravovat cizí termíny Zakládat nové registrace / úprava a odstranění současných Výpis lidí / rezervací Spravovat vzkazy / aktuality / události Admin na objektu: Spravovat otevírací a nedostupní dobu / časy odběrů Guru: Správa objektů / odběrů / systému

24 8 KAPITOLA 2. ANALÝZA 2.3 Architektura V této podkapitole si představíme použité komponenty (celky) a jejich spolupráci. Nový systém bude obsahovat následující: máte centrální SQL databázový server, kde jsou uložená jen základní data, jeden a více lokálních serverů, které jsou navzájem propojené, přitom jeden objekt může komunikovat s několika servery, nebo naopak jeden server může obstarávat několik objektů (odběrných míst), a na závěr máte klienta, který má za úkol zobrazit poskytnutá data nebo žádat server o provedení nějaké akce. Všechno tohle může provozovat jak několik počítačů, tak i jeden, a k tomu můžete systém nebo jeho část rozšířit i na jiné, než základní platformy, např. na mobily nebo tablety, bez zásahů do jádra. Centrální SQL databázový server (CENTRÁLA) obsahuje data, která se v systému vyskytují jen jednou. To jsou rezervační data, seznam objektů, seznam a hesla uživatelů a záznamy správy systému, jako jsou vypadlé lokální uzly a zda jsou data na nich konzistentní, nebo nepovolené SQL příkazy. Lokální server má vlastní SQL databázi a PHP část v roli vrátného. Lokálních serverů jsou dva druhy MASTER a SLAVE. Každý z nich může libovolně zapisovat rezervace a odpovídat na dotazy. Rozdíl je v tom, že pokud máte dva a více lokálních serverů, musíte zajistit stejná data (konzistenci) ve všech databázích, proto je zápis vyhrazen MASTER serveru, a SLAVE se vzdáleně přihlásí na MASTER. Více o tom bude v příslušné kapitole. Server odpovídá v JSON[P] protokolu, což jsou standardizované odpovědi ve formě textu, proto je koncovému klientu jedno, zda se jedná o PHP, Ruby, JSP nebo ASP.NET. Kdykoliv můžete změnit část nebo i celou technologii a klientská část se nemusí měnit. Toto jsou dvě základní části, které může obsahovat jeden server, ba i jedna databáze. Komunikace přes příkazový řádek a textové odpovědi jsme však zažili v minulém století. Proto je tu třetí část klient. Serveru je jedno, zdá komunikuje s počítačem a prohlížečem, mobilem nebo tabletem. Stačí, když klient reaguje na určité odpovědi a podporuje technologii cookies. Při vývoji klienta jsem se proto rozhodl pro tu nejzákladnější technologii HTML a JavaScript, koncový uživatel nebo provozovatel tak nemusí mít PHP, ASP.NET nebo JSP server. Nemusí mít ani server, stačí mu novější internetový prohlížeč. Webová stránka je asynchronní (popis v příslušné kapitole) a využívá vývojové prostředí jquery a jquery UI.

25 2.3. ARCHITEKTURA 9 Obrázek 2.3: Základní architektura Obrázek 2.3 má 3 komponenty: HTML+JavaScript aplikace, PHP aplikace a MySQL databáze. Toto je nejzákladnější architektura, kterou jsem zvolil. Povšimněte si prosím, že komponenty nejsou izolované na servery. Tuto architekturu řeším provozem na jednom serveru, není však problém provoz na dvou nebo třech serverech. Popřípadě na serveru a klientu. Veškerá komunikace probíhá v TCP/IP protokolu, což je nejrozšířenější síťový protokol. HTML+JavaScript aplikace zprostředkovává vzhled systému, PHP aplikace obsahuje řídící logiku a MySQL databáze schraňuje data. Dotazy HTML+JavaScript aplikace probíhají přes AJAX, dozvíte se o tom v další kapitole. Zpětná odpověď od PHP aplikace je v JSON nebo JSONP formě, tedy v textově formě, jako je například: {" chyba" : 1, " v r a t i t ":{" jmeno" : " Nemocnice New", " adresa " : [ ], " " : null, " mobil " : n u l l } } Důvody, proč jsem zvolil tuto architekturu, (rychlost, přenositelnost, mobilní aplikace... ) můžete najít v dalších podkapitolách. Teď se spíše podíváme, jak se dá tato architektura rozšířit. Obrázek 2.4: Rozšířená architektura Během vývoje jsem rozdělil databázi na dvě skupiny (obrázek 2.4). Na CENTRÁLE se nachází jen málo tabulek a záznamů, které budou obsahovat jen rezervační data, seznam uživatelů a objektů a společné logy. Naopak na LOKÁLU se ukládají záznamy, které se mění méně často aktuality, otevírací a nedostupná doba, atd. Nejen z důvodu oddělení stabilních (skoro neměnných) záznamů a logiky od záznamů měněných často, ale i z důvodu dalšího rozšíření.

26 10 KAPITOLA 2. ANALÝZA Obrázek 2.5: Síť Systém mohu rozšířit na Síť (obrázek 2.5). Teď můžete k MASTER PHP serveru přidat libovolný počet SLAVE PHP serverů, všechny mohou libovolně zapisovat rezervace a mají každý svoji lokální databázi (LOKÁL1 a LOKÁL2). Servery mají společnou databázi CENTRÁLA. Tím můžeme zrychlit odezvu až o 100 procent! Jedinou nevýhodou tohoto řešení je nutnost režie zápisu do lokálních databází, kterou má vyhrazenou MASTER server. Na LOKÁLU je uložená například otevírací doba. Jeden klient se připojí k MASTER serveru, druhý ke SLAVE serveru. A oba se mohou ptát na otevírací dobu ve stejný okamžik, bez front a čekání. Tak se zrychlí odezva až o 100 procent. Distribuci zápisu řeší funkce sendtoallnodes($dotaz), kde $dotaz je několik SQL příkazů. Uživatel master se přihlásí na MASTER serveru, bude mít seznam lokálních databází (LOKÁL1 a LOKÁL2) a $dotaz. Nejdříve zkontroluje, zda jsou všechny databáze živé a obsah je konzistentní. Potom všem pošle dávku příkazů k zápisu ve formě transakce. Jestli data nejsou konzistentní nebo uzel vypadl, zápis se neprovede a uloží se záznam do Master logů. Rezervace a přihlášení budou fungovat, jsou na CENTÁLE. Jestli nějaký uzel vypadl dlouhodobě, musí být vyškrtnutý ze seznamu, aby zápis nových uživatelů, aktualit nebo otevíracích dob byl možný. Po návratu uzlu na něj musí být nahrána nová databáze, jako kdyby to byl nový SLAVE server. Když dojde k výpadku MASTER serveru, musíte zvolit nový a upravit záznamy. Starší systém uměl jen rezervace, nebyl rozšířitelný na jiné platformy a umožňoval jen pevné hodinové rezervace na začátku hodiny. Nový systém bude umět víc než rezervace, bude rozšířitelný na jiné platformy a také bude umožňovat nastavit jak časovou délku odběru, tak i rezervace přesně na minuty. A také jiné vlastností. Tím se dostáváme i ke způsobu rozšíření aplikací. Obě aplikace jsou rozšiřitelné díky modulům souborům, které zvýší funkčnost systému. U každé máte vzorové soubory rozšíření, o jejich využití se něco dozvíte v dalších kapitolách, které na Vás teď čekají.

27 2.4. ZÁVĚR ŘEŠENÍ 11 Nový systém: Používá nejrozšířenější technologie Každá komponenta (celek) je nahraditelná Každá komponenta má svoje rozhraní Minimální komunikace přes textové odpovědí Rozšířitelný díky modulům Rozšířitelný na jiné platformy Distribuovaný přistup k informacím MySQL, PHP, HTML, JavaScript, jquery a JSON[P] Seznámili jste se základní a rozšířenou architekturou, kterou můžete dále rozšířit na celou síť serverů. Víte teď, jaké jsou komponenty v systému a jak spolu komunikují. Také víte něco o komunikaci přes JSON (textové odpovědi) a dozvěděli jste se proč byla zvolena taková architektura, a co každá komponenta obsahuje. Příručky a popis jednotlivých funkcí najdete v přílohách. 2.4 Závěr řešení Máte za sebou úvod, nastínění problémů, co by měl systém umět, jakou má architekturu, funkční a nefunkční požadavky. Toto je tedy konec analýzy a dále můžete se podívat na návrh řešení a implementaci. Předtím, než se podíváte, jak se systém ovládá, pár slov k vývoji. Tato dokumentace vznikla až po vytvoření systému, a jediný nástroj, který jsem používal k vývoji, byl Kate, což je poznámkový blok. Až později byly použity nástroje na kontrolu PHP, JavaScript a HTML kódu. Většinu času mi zabralo vytvořit stabilní jádro, pak lokální funkce modulů, a až potom PHP moduly. Nezapomínejte však na vývoj HTML+JavaScript aplikace a její rozhraní. Hodně funkcí prošlo několikrát optimalizací. Nyní má systém 3 hlavní části, jako i 3 typy komponent HTML+JavaScript aplikace, PHP aplikace a MySQL databáze. Toto jsou tři technologie (a jejich nadstavby), které musíte znát, abyste mohli systém rozšířit a vyvíjet dál. Nyní Vás čeká část, kde se nejen seznámíte s ovládáním nejen grafického rozhraní HTML+JavaScript aplikace, ale též se podíváte na PHP aplikaci a databázi MySQL.

28 12 KAPITOLA 2. ANALÝZA

29 Kapitola 3 Návrh řešení 3.1 Databáze CENTRÁLY V této části se podíváte na část systému nesoucí jméno CENTRÁLA. Jedná se o SQL databázi, která obsahuje hesla uživatelů, seznam objektů, zamluvené a rezervované časy a záznamy systému. Obrázek 3.1: CENTRÁLA 13

30 14 KAPITOLA 3. NÁVRH ŘEŠENÍ Ke správě a vývoji databáze slouží nástroj DB Designer Fork [1]. CENTRÁLA má jen základní jednoduchou strukturu. Obsahuje jen minimum věcí společných s LOKÁLEM, a to jsou ID osob a objektů. Vždy platí, že když na LOKÁLU vytvoříte nový objekt nebo nového uživatele, tak se nejdříve vytvoří na CENTRÁLE a pak získáte jeho ID a použijete ho na lokální databázi. Je vidět (obrázek 3.1), že věci, jako ID jednotky nebo ID druhu, nejsou na CENTRÁLE, a spravuje je LOKÁL. Tabulka Zaznamy_masteru, kde jsou uloženy logy informačního systému, jako jsou nedostupnost uzlů nebo neprovedené SQL příkazy, které způsobily nekonzistentnost sítě lokálních databází. Pokud máte jen MASTER server, najdete tam pokusy možných útoků. Pokud máte dva a více serveru (Síť), a máte záznam o nekonzistentnosti jednoho z nich, zkontrolujte a opravte, prosím, nekonzistentnost databáze ručně. Úkol této části systému je jednoduchý rychle poskytnout a zapsat data od CENTRÁLY.

31 3.2. DATABÁZE LOKÁLU Databáze LOKÁLU Zde rozdělím lokální server na dvě části SQL databázi a PHP část. Tato podkapitola popisuje SQL databázi. Na rozdíl od CENTRÁLY, databáze je rozsáhlá a dávat sem celý obrázek by bylo nepřehledné, proto jej proberu po částech Osoba Obrázek 3.2: Osoba Největší celek je Osoba (obrázek 3.2). Má identifikaci id, svoje data, jako username, jeho MD5 hash, , telefon, současný klíč pro komunikaci klic a pro přihlášení loginklic, o kterých se dozvíte v PHP logice, a další data. Má jak vazbu sama na sebe, v případě registrátora, tak i vazby na tabulky výčtů hodnot, jako jsou Opravneni, Stav_v_systemu nebo Operator, abych se co nejvíce přiblížil k 3. normální formě databáze. Také vztahy 1:N, jako jsou Logy nebo kdo je autorem Vzkazy, kde se ID osoby vyskytuje přímo. Vztahy M:N se řeší díky vztahu 1:N a tabulkám _has_ ( Osoba_has_Vzkazy, Osoba_has_Objekt a Osoba_has_Udalost ), kde se mohou vyskytovat nejen dvojice aktérů, ale i stupeň oprávnění.

32 16 KAPITOLA 3. NÁVRH ŘEŠENÍ Objekt Obrázek 3.3: Objekt Objekt (obrázek 3.3) sám o sobě neobsahuje hodně informací, jen jméno, , telefon, mobil a ID adresy. Avšak má hodně vazeb a vztahů, a to včetně identifikační závislosti v případě Nastaveni_objektu, kde máte uložená data o způsobu odběru. Máte tu vztahy na otevírací dobu ( Mimoradny_den, Mimoradny_rozvrh a Tydenni_rozvrh ), kde se objekt vyskytuje jako identifikační klíč. Máte zase klasické vztahy M:N, řešené přes 1:N vztah a tabulky _has_ ( Osoby_has_Objekt a Vzkazy_has_Objekt, kde jsou uloženy aktuality). U tabulky Adresat jsem zamítl identifikační závislost, i když by tady klidně mohla být. A pak tu jsou tabulky ( Udalost, Jednotka nebo Logy ), kde se ID objektu vyskytuje jako atribut přiřazování.

33 3.2. DATABÁZE LOKÁLU Otevírací doba Obrázek 3.4: Otevírací doba Každá otevírací doba (obrázek 3.4) má vazbu na objekt. Jsou tři typy Mimoradny_den (jeden den, jedno datum), Mimoradny_rozvrh (jak dlouho platí a pro který den nebo dny) a Tydenní_rozvrh (standardní doba, pro ten den nebo dny). V případě dnů, je zde tabulka Den, kde jsou uložené jednotlivé dny (1-7) nebo skupina Po-Pá (8). Na každý typ se váže ID otevírací doby v tabulce Otevreno, která je jedinečná na rozdíl od pauz. Jelikož oba objekty mohou mít otevřeno 08:00-18:00, nemusí mít stejné pauzy, proto každý má svoje idotevreno. A naopak - dva objekty mohou mít pauzu 14:00-14:30, systém to pozná a vyhnete se duplicitě.

34 18 KAPITOLA 3. NÁVRH ŘEŠENÍ Jednotka a nedostupná doba Obrázek 3.5: Jednotka a nedostupná doba Poslední část databáze, na kterou se podíváte zblízka, bude Jednotka (obrázek 3.5) a nedostupná doba. Pro nedostupnou dobu platí podobná pravidla, jako pro otevírací dobu, až na názvy tabulek ( Mimoradny_cas, Mimoradne_nedostupne_casy a Tydenni_nedostupne_casy ) a neplatí zde jedinečnost pro Nedostupnost, kde v otevírací době to bylo Otevreno. Další rozdíl je, že nedostupná doba se váže na jednotku, ne na objekt. Jednotka reprezentuje spíše pseudo-přístroj, jako například separátor s jedinečným ID, aby se od sebe odlišily Ostatní tabulky Databáze LOKÁLU obsahuje i jiné tabulky. Některé jsou entity, jako je Udalost, některé jsou jen výčet ( Opravneni ) a některé jsou vztahové ( Osoba_has_Udalost ) i nesoucí informace ( Osoba_has_Objekt ). Vyjmenovat a popisovat každou z nich tu nebudu, i když každá z nich je důležitá, a nechám to na samostatném procházení zdrojů. Jsou tu i pozůstatky, jako je stav jednotky, který je vždy aktivní, což nemůžete měnit v systému a jsou v základu na 1, protože změny v PHP části se nemusely promítnout na změny databázové části. Pro plné pochopení databáze doporučuji otevřít zdrojové soubory už ve zmiňovaném programu DB Designer Fork, nebo v phpmyadmin. Další sekcí je řízení obou těchto skupin (CENTRÁLA a LOKÁL).

35 3.3. LOKÁL - PHP LOKÁL - PHP V této části bych rád poukázal na perličky, které provázely vývoj. Nejsou zde diagramy průběhů funkcí, protože všechny jsou lineární. Buď máte všechno v pořádku, nebo Vás systém upozorní, popř. odhlásí (obrázek 3.6 a 3.7). Obrázek 3.6: Zamluvení termínu Obrázek 3.7: Rezervace termínu Přihlášení Vaše heslo během celé relace se nepošle. Ano, je to popsáno níže. Dostanete řetězec, který je platný jen 2 minuty, spojíte ho dohromady se zašifrovaným heslem a Vaším jménem, a z toho celého vypočtete kontrolní součet, který následně pošlete. Pokud někdo bude mezi Vámi a serverem odposlouchávat heslo, neuspěje.

36 20 KAPITOLA 3. NÁVRH ŘEŠENÍ Postup: Požádám server o loginklic Server vygeneruje náhodný řetězec a připojí podpis, který je také vázán na IP adresu žadatele Server pošle mi loginklic a max. do 2 minut očekává odpověď MD5(MD5(Heslo)), loginklic a UPPERCASE(Username) -> Do jednoho ŘETĚZCE Pošlu serveru MD5(UPPERCASE(Username)), MD5(ŘETĚZCE), loginklic a číslo objektu Server pošle mi komunikační klic klic je vázán na ID uživatele, jeho IP adresu a je podepsaný serverem Změna hesla Změna hesla se provádí jinak. Klient vezme současné ID uživatele, středník a kontrolní součet kontrolního součtu nového hesla. Spojí to dohromady a díky funkci OpenSSL a algoritmu AES-256[8] zašifruje tento řetězec - GibberishAES.enc(text, md5_stareheslo)[6], kde text je tento řetězec a md5_stareheslo je kontrolní součet Vašeho starého hesla, který je uložen na serveru. Klient tím získal řetězec, který může dešifrovat jen dvojitý kontrolní součet Vašeho starého hesla a který pošle serveru. Ten to dešifruje, a jestli ID souhlasí, heslo změní. 3.4 KLIENT Veškerá logika je na stráně PHP serveru, přesto klient zachytí špatné parametry a odmítne poslat příkaz na hlavní server. Nejedná se však o dvojitou ochranu, protože každý může poslat PHP serveru dotaz přes adresovou řádku, a server tento dotaz v případě chyby odmítne. Klient tedy pomáhá nejen grafickým prostředím, ale snižuje i počet dotazů na hlavní server. KLIENT je jen ochranka, co vezme kartotéku uživatele, zběžně zkontroluje žádost a pošle jí dál. Je na PHP serveru zda tu žádost schválí. 3.5 Závěr Toto není závěr návrhu řešení, je to závěr počátečních předpokladů, které Vás čekají v kapitole Implementace. Na další stránce si povíme něco o vývoji, řešení a implementaci systému, se kterým jste se teď setkali. Proto toto není konec ani analýzy, ani návrhu řešení, je to konec počáteční vize, a realizace Vás teprve čeká.

37 Kapitola 4 Implementace 4.1 Implementace LOKÁLU - PHP V této kapitole se podíváte na jádro systému. Veškerá logika na MASTER a SLAVE serverech je psána v jazyce PHP, její popis najdete v minulých kapitolách. K vývoji systému jsem zvolil nejrozšířenější webový programovací jazyk PHP, ale jak jsem už psal v úvodu, není problém nahradit tento jazyk platformou ASP.NET, JSP nebo Ruby. Server odpovídá v JSON[P] protokolu, což jak už jsem zmínil, jsou textové odpovědi. Server sám o sobě nemá grafické rozhraní, proto není problém přidat podporu třeba Qt aplikace ve Windows či Linux nebo aplikace pro mobilní platformy Android či ios. PHP část je napsána v takzvané procedurální formě, aby byla zachována co největší kompatibilita se staršími verzemi jazyka PHP, i když je doporučená verze 5.3. Procedurální forma rovněž zajistí, aby přechod na jinou technologii byl co možná nejjednodušší. PHP část má svoje malé základní jádro a moduly, díky kterým můžete systém rozšířit. Všechny operace, až na jednu, která používá metodu POST, berou parametry z adresového řádku a povíme si o tom něco dále v této kapitole. Všechny moduly vrací zpět JSON[P] odpověď Jádro Ve složce MASTER serveru jsou PHP soubory - jsou to moduly. Ve složce objekty jsou uloženy JavaScriptové soubory, kde jsou uvedeny nastavení objektů pro klienta. Složka private obsahuje soubory jádra. private/.ht-konfigurace.php Kromě hesel, zápisu do LOKÁLU, nastavení zabezpečení a seznamu MASTER a SLAVE serverů, má za úkol nastavit a nastartovat session. Pak jsou tu hesla a nastavení pro spojení s CENTRÁLOU a LOKÁLEM. VERYSECURE pro paranoidní zabezpečení a LOGOUT_CAS pro nastavení automatického odhlášení. Jsou tu dva jedinečné klíče ID_WEBU a ID_WEBU2, které slouží pro ověření a šifrování dotazů. Pak je tu inicializace 3 globálních proměnných pro spojení s databází a seznam serverů v systému. Konfigurace do sebe též začleňuje soubor pripojeni.php. 21

38 22 KAPITOLA 4. IMPLEMENTACE private/pripojeni.php Tento soubor zajistí spojení se dvěma databázemi CENTRÁLY a LOKÁLU, nebo vypíše chybu a skončí. Dále tento soubor zajišťuje zápis do LOKÁLNÍCH databází, aby obsah byl konzistentní (stejný na všech serverech). Např. když dva lidé zapisují naráz, může vzniknout nekonzistentnost. Příklad já zapíšu do databáze otevírací dobu, kterou chci použít dále. Mezitím kolega spustí čištění, a jelikož moje otevírací doba není přiřazena, systém ji odstraní. Já pak budu chtít tuto dobu použít a budu mít smůlu. A máme tu chaotické chování systému, protože nevíme, čí příkaz bude rychlejší. Proto se to řeší transakcí. A teď si představte, že chcete zapsat do několika databází na různých serverech, hrůza. Budou zapisovat dva lidé, v první databázi záznam bude mít ID 3 a na druhé ID 4, a teď někdo pošle odstranění ID 3, a to je problém. Proto byl vytvořen uživatel master a funkce sendtoallnodes($dotaz), viz Architektura 2.5. Když jsem člověk, tak se pokusím přihlásit jako master na MASTER serveru. Když tam někdo je přihlášen, tak počkám náhodnou dobu a zkusím se znovu přihlásit, a to 4 krát. Když se přihlásím a server není v údržbě, pošlu zašifrovaný dotaz, a systém ho provede ve všech databázích v seznamu. Toto je zjednodušený popis, systém hlídá i čas dotazu, konzistentnost a dostupnost databází. private/getset.php Kromě správy hodnot v session, tento soubor nám generuje náhodný řetězec dané délky ( loginklic, klic a nové heslo), nebo také vypíše v JSON[P] chybějící parametr. Dále, má za úkol posílat na určitou adresu a také zde máme funkci getklic(). Tato funkce nejen vrátí obsah z adresové řádky, ale také ověří, zda tento klíč platí pro IP adresu klienta a jeho ID, to vše podepsáno systémem díky proměnné ID_WEBU. Je tu i funkce getkontrolniklic(), která zvyšuje bezpečnost. Postup: Server dostal požadavek Pokud jádro není načteno, načte ho Zkontroluje, co obsahuje adresový řádek Podle požadavku zkontroluje přihlášení, pravost klic, oprávnění a čas přihlášení U plné kontroly také zkontroluje záznamy přes databázi, ne přes session Kde také provede getkontrolniklic() kontrolu SessionID a klic z databázi Provede se požadavek

39 4.1. IMPLEMENTACE LOKÁLU - PHP 23 private/promenne.php Vám při startu session nastaví potřebné hodnoty a také přemaže proměnné a klíč v databázi při odhlášení. private/vstup.php Tento soubor sloučí celé jádro dohromady. Též má funkci zkontroluj(), která dle potřeby provede kompletní nebo běžnou kontrolu uživatele, a případně ho odhlásí. Jádro: Načtu jednou (require_once).ht-konfigurace.php Načtu jednou pripojeni.php Načtu jednou getset.php Načtu jednou promenne.php Také jejích funkce Jsou tu i jiné funkce, všechny z nich jsou zdokumentované a jsou také uvedeny vstupy a výstupy, proto není důvod je tady rozebírat. Teď se podíváte na chvíli pryč ze složky private do hlavního adresáře. index.php Slouží pro počáteční instalaci systému, kde uživatel zadá potřebné údaje a systém vytvoří databázové tabulky uživatele a vygeneruje výpis, se kterým jste se setkali v příručce o instalaci systému. Využívá tyto soubory centrala.sql a node.sql, kde jsou uloženy vzorové tabulky, konfigurace_vzor.php a objekt_vzor.js, kde jsou uloženy vzorové soubory, a soubor sql.php z dílny phpbb[10], který zapíše vzorové databázové tabulky místo phpmyadmina. login.php a logout.php Přestože se jedná o moduly, jsou nedílnou součástí systému. Při startu login.php se uživateli vygeneruje takzvaný loginklic, ten má celkem 26 písmen (13 náhodných, zbylých 13 obsahuje jeho podpis). Je platný jen 2 minuty, je uložen do session, je vázán na IP adresu žadatele a vše je podepsáno proměnnou ID_WEBU2. První ochrana před nepovolaným uživatelem. Klient vezme uživatelské dvakrát šifrované heslo pomocí MD5, tento loginklic a uživatelské přihlašovací jméno (vše velkými písmeny), spojí to dohromady a to celé dá do MD5 získá loginheslo. Druhá ochrana před nepovolaným uživatelem, který chce odhalit cizí heslo. Klient toto přihlašovací jméno napíše (vše velkými písmeny) a dá MD5 získá loginjmeno. A teď společně s číslem objektu ( loginobjekt ) odešle loginklic, loginheslo a loginjmeno. Získá takzvaný klic, který má 26 písmen (13-20 písmen náhodných, zbylé obsahuje podpis,

40 24 KAPITOLA 4. IMPLEMENTACE IP adresu žadatele, jeho ID a vše je podepsáno ID_WEBU ) a se kterým komunikuje se systémem během session a který je uložen v databázi společně s loginklic. Třetí ochrana před nepovolaným uživatelem, protože i opakované posílání získaných dat útočníkovi nepomůže, a to tu ještě nemluvím o další kontrole (getkontrolniklic(), intval(), date()...) - jednoduše každý vstup je kontrolován a transformován. Odhlášení logout.php zničí session a její proměnné, plus zapíše klic do databáze, že jste odhlášen. 4.2 Moduly - PHP Systém je rozšířitelný díky souborům neboli modulům. Jsou dva různé typy modulů. První má jednu funkci ( cron.php, už zmíněné login.php a logout.php, zamluv.php, rezervuj.php nebo odstran.php ), provádí jednu určitou akci bez potřeby doplňujících parametrů. Druhý typ ( aktualita.php, jednotky.php, objekt.php, otev_doba.php,... ) musí mít parametr akce=x, kde X je číslo funkce. Oba typy se však volají stejně: v e r e j n e. php? c a l l b a c k=jquery1910&akce=7&objekt=1&p o c a t e c n i=0&pocet=5 verejne.php je název modulu callback je proměnná, která značí, že chceme odpověď v JSONP akce číslo akce, 7 = vypiš aktuality objekt parametr akce, číslo objektu pocatecni parametr akce, počáteční číslo aktuality pocet parametr akce, počet aktualit Některé parametry musíte uvést, některé nemusíte. Každá akce chce svoje parametry a musíte se podívat do API rozhraní modulu, co daná akce chce. Proto metodu POST najdete jen u importu uživatelů, kde posíláte soubor. Pro získání dat proto používáte metody REQUEST a GET, a samozřejmě ošetření vstupů (intval(), date() nebo mysqli_real_escape_string()). Nepsané pravidlo je, že modul má dva soubory jeden v hlavním adresáři serveru, kde je jen kontrola vstupů, volání funkcí a výpis, a jeden ve složce private, kde jsou lokální funkce. Také proto používám v jednom modulu lokální funkce z jiných modulů, což snižuje redundanci (zdvojení) kódu. V každém modulu je popsáno, co dělá, a jsou zdokumentované všechny lokální funkce. Proto tady nebudu vypisovat API každého modulu - viz API PHP modulů, spíše se zaměřím na zajímavé věci. Až na výjimky platí pravidlo UNIXu: psát menší funkce, ale kvalitně, pak to spojit dohromady.

41 4.2. MODULY - PHP private/aes.php Je to knihovna, která dokáže dešifrovat řetězec poslaný z JavaScriptu. Slouží ke změně hesla. Když budete chtít změnit heslo, posílat nové a nešifrované není bezpečné. Proto vezmete nové heslo, dvakrát zašifrované v MD5, které bude v této podobě uloženo na serveru. Připojíte k tomu ID uživatele, a zašifrujete to řetězcem starého hesla, které je momentálně na serveru. aes.php [8] tento řetězec dešifruje, zkontroluje ID a zapíše nové heslo (viz Návrh řešení Změna hesla) private/jed_local.php a private/otv_local.php Kromě vytváření sítě MASTER a SLAVE uzlů, jsou to jediné knihovny, u které byly velmi náročné na vývoj. Jak bylo uvedeno v Návrhu řešení, jsou 3 typy otevírací a nedostupné doby, a zkontrolovat při změně pravidel pro co, kdy a jaká pravidla platí, bylo velice obtížně. A jsou tu právě porušení pravidla UNIXu, že funkce má být malá Ostatní moduly aktualita.php - spravuje aktuality cron.php - posílá y a SMS jednotky.php - spravuje jednotky objekt.php - spravuje objekt odstran.php - odstraní rezervaci rez_data.php - vrátí rezervační data rezervuj.php - provede rezervaci zamluv.php - zamluví termín otev_doba.php - spravuje otevírací dobu profile.php - spravuje můj profil registrace.php - spravuje uživatele system.php - spravuje systém ucet.php - spravuje účet udalost.php - spravuje události verejne.php - základní informace Každý modul používá různé soubory ze složky private.

42 26 KAPITOLA 4. IMPLEMENTACE API PHP modulů aktualita.php akce=1 - Nová aktualita, Potřeba: barva, titulek, datum, text akce=2 - Vrátí aktualitu, Potřeba: menim akce=3 - Upraví aktualitu, Potřeba: menim, barva, titulek, datum, text akce=4 - Odstraní aktualitu, Potřeba: menim cron.php nic - Pošle SMS a y jednotky.php akce=1 - Vrátí mimořádný den, Potřeba: datum, idnedostupno, idjednotky akce=2 - Nastaví mimořádný den, Potřeba: old_datum, datum, idnedostupno, idjednotky, prepis, nedostupno akce=3 - Odstraní mimořádný den, Potřeba: datum, prepis, idnedostupno, idjednotky akce=4 - Vrátí mimořádnou dobu, Potřeba: plati_od, den, idnedostupno, idjednotky akce=5 - Nastaví mimořádnou dobu, Potřeba: old_plati_od, old_den, plati_od, plati_do, den, idnedostupno, prepis, idjednotky, nedostupno akce=6 - Odstraní mimořádnou dobu, Potřeba: idnedostupno, plati_od, den, prepis, idjednotky akce=7 - Vrátí týdenní dobu, Potřeba: den, idnedostupno, idjednotky akce=8 - Nastaví týdenní dobu, Potřeba: old_den, den, idnedostupno, prepis, idjednotky, nedostupno akce=9 - Odstraní týdenní dobu, Potřeba: idnedostupno, den, prepis, idjednotky akce=10 - Nové pravidlo, Potřeba: typ, prepis, idjednotky, nedostupno, ostatní dle typu akce=11 - Vrátí seznam jednotek, Potřeba: - akce=12 - Nastaví počet jednotek, Potřeba: typ, pocet akce=13 - Odstraní jednotku, Potřeba: idjednotky login.php nic - Vrátí loginklic loginklic, loginjmeno, loginheslo, loginobjekt - Přihlášení

43 4.2. MODULY - PHP 27 logout.php nic - Odhlásí uživatele objekt.php akce=1 - Nastaví jméno, Potřeba: jmeno akce=2 - Nastaví adresu, Potřeba: ulice, mesto, smer_cislo, stat akce=3 - Nastaví , Potřeba: akce=4 - Nastaví telefon, Potřeba: telefon akce=5 - Nastaví mobil, Potřeba: mobil akce=6 - Nový odběr, Potřeba: druh, priprava, odber, odpojeni, cisteni, interval, max_dnu, zamestnancu akce=7 - Upraví odběr, Potřeba: druh, priprava, odber, odpojeni, cisteni, interval, zamestnancu, max_dnu, prepis akce=8 - Odstraní odběr, Potřeba: druh odstran.php rezervace - Odstraní rezervaci, Volitelné: user, objekt otev_doba.php akce=1 - Vrátí mimořádný den, Potřeba: datum, idotevreno akce=2 - Nastaví mimořádný den, Potřeba: old_datum, datum, prepis, otevreno, pauzy akce=3 - Odstraní mimořádný den, Potřeba: datum, prepis akce=4 - Vrátí mimořádnou dobu, Potřeba: plati_od, den, idotevreno akce=5 - Nastaví mimořádnou dobu, Potřeba: old_plati_od, old_den, plati_od, plati_do, den, prepis, otevreno, pauzy akce=6 - Odstraní mimořádnou dobu, Potřeba: plati_od, den, prepis akce=7 - Vrátí týdenní dobu, Potřeba: den, idotevreno akce=8 - Nastaví týdenní dobu, Potřeba: old_den, den, prepis, otevreno, pauzy akce=9 - Odstraní týdenní dobu, Potřeba: den, prepis

44 28 KAPITOLA 4. IMPLEMENTACE akce=10 - Nové pravidlo, Potřeba: typ, prepis, otevreno, pauzy, ostatní dle typu profile.php akce=1 - Vrátí uživatelské data, Potřeba: - akce=2 - Změní heslo uživatele, Potřeba: magicstring akce=3 - Statistika událostí, Potřeba: - akce=4 - Změní kontakty, Potřeba: telefon, operator, akce=5 - Statistika rezervací, Potřeba: - registrace.php akce=1 - Nová registrace, Potřeba: username, jmeno, prijmeni, telefon, operator, , narozen, rc, Volitelné: objekt, opravneni, poznamka akce=2 - Otestuje Username, Potřeba: username akce=3 - Vrátí uživatele, Potřeba: id akce=4 - Resetuje heslo, Potřeba: id akce=5 - Odstraní uživatele, Potřeba: id akce=6 - Upraví uživatele, Potřeba: id, username, jmeno, prijmeni, telefon, operator, , narozen, rc, Volitelné: neomluveno, objekt, opravneni, poznamka akce=7 - Vrátí seznam uživatelů, Potřeba: idfrom, idto akce=8 - Vrátí seznam uživatelů, Potřeba: idlist akce=9 - Vrátí seznam rezervací, Potřeba: datefrom, dateto, jedid, uziid rez_data.php datum, davam - Vrátí rezervační data, Volitelné: user rezervuj.php zadost, odber - Rezervuje žádost, Volitelné: user, upozorneni

45 4.2. MODULY - PHP 29 system.php akce=1 - Nový objekt, Potřeba: jmeno akce=2 - Odstraní objekt, Potřeba: objekt akce=3 - Nový odběr, Potřeba: jmeno akce=4 - Vrátí odběr, Potřeba: iddruh akce=5 - Upraví odběr, Potřeba: iddruh, jmeno akce=6 - Odstraní odběr, Potřeba: iddruh akce=7 - Vrátí logy, Potřeba: - akce=8 - Odstraní logy, Potřeba: - akce=9 - Vrátí MASTER logy, Potřeba: - akce=10 - Odstraní MASTER logy, Potřeba: - akce=11 - Import uživatelů, Potřeba: POST:import_objekt, import_opravneni, FILES:sys_import_file akce=12 - Odstraní staré rezervace, Potřeba: mesicu akce=13 - Odstraní sirotky, Potřeba: - ucet.php akce=1 - Vrátí nebo obnoví čas přihlášení, Potřeba: - akce=2 - Vrátí nastavený čas odhlášení, Potřeba: - akce=3 - Vrátí jméno uživatele, Potřeba: - akce=4 - Vrátí seznam uživatelů, Potřeba: like akce=5 - Provede kontrolu prav, Potřeba: stupen akce=6 - Vrátí uživatele, Potřeba: id akce=7 - Vrátí nadcházející rezervace, Potřeba: - akce=8 - Vrátí předchozí rezervace, Potřeba: - akce=9 - Pošle vzkaz, Potřeba: barva, titulek, datum, text, komu akce=10 - Odstraní vzkaz, Potřeba: vzkaz akce=11 - Vrátí vzkazy, Potřeba: -

46 30 KAPITOLA 4. IMPLEMENTACE udalost.php akce=1 - Vrátí událostí, Potřeba: - akce=2 - Přihlásit se na událost, Potřeba: udalost akce=3 - Odhlásit se z události, Potřeba: udalost akce=4 - Nová událost, Potřeba: nazev, popis, datum_od, datum_do, misto, barva akce=5 - Odstraní událost, Potřeba: udalost akce=6 - Vrátí událost, Potřeba: udalost akce=7 - Upraví událost, Potřeba: udalost, nazev, popis, datum_od, datum_do, misto, barva akce=8 - Upraví účastníky, Potřeba: udalost, prihlaseny, jedou akce=9 - Vrátí účastníky, Potřeba: udalost akce=10 - Pošle vzkazy potvrzeným, Potřeba: udalost verejne.php akce=1 - Výpis objektů, Potřeba: - akce=2 - Darování na objektu, Potřeba: objekt akce=3 - Standardní otev. doba, Potřeba: objekt akce=4 - Všechny mim. otev. doby, Potřeba: objekt akce=5 - Určitá mim. otev. doba, Potřeba: doba, objekt akce=6 - Svátky, Potřeba: objekt akce=7 - Vrátí aktuality, Potřeba: objekt, Volitelné: pocatecni, pocet akce=8 - Všechny mim. otev. doby hromadně, Potřeba: objekt akce=9 - Standardní nedost. doba, Potřeba: objekt akce=10 - Všechny mim. nedost. doby, Potřeba: objekt akce=11 - Sváteční nedost. doby, Potřeba: objekt akce=12 - Informace o objektu, Potřeba: objekt akce=13 - Darování na objektu podrobně, Potřeba: objekt akce=14 - Zapomenuté heslo, Potřeba: md5jmeno, md5 , md5telefon

47 4.3. NOVÝ MODUL - PHP 31 akce=15 - Určitý odběr podrobně, Potřeba: objekt, druh akce=16 - Všechny odběry v systému, Potřeba: - zamluv.php datum, davam, jednotka, zacatek - Rezervuje žádost, Volitelné: user, edit 4.3 Nový modul - PHP Pro nový modul byly vytvořeny soubory empty.php a emp_local.php. Jsou okomentované a kdykoliv po zkopírování obou souborů můžete systém rozšířit o danou funkci. Pro vývoj dalších modulů však doporučuji nejdříve prostudovat současný kód, podívat se na hotové systémové metody a funkce. Dále, platí druhé nepsané pravidlo odpověď má mít vždy příznak chyba, kde 1 znamená OK a minus číslo kód chyby. V této podkapitole jste se dozvěděli, jaké soubory jsou na serveru a co soubory dělají. Dozvěděli jste se něco o struktuře kódu, posílání dotazů a získávání odpovědí. Doufám, že svůj účel sekce splnila a v další podkapitole se dozvíte, jak to spojíte s JavaScriptem a konečně se podíváte na grafické rozhraní, než na textové odpovědi. 4.4 Implementace KLIENTA API a Hlavní okno Dostáváte k uživatelskému rozhraní (GUI). Ne, že by práce v konzoli nebyla zábavná, ale musíte moderní technologie využít naplno. A také, zvyšující se výkon počítačů a mobilů nám pokládá otázku proč nevyužít tento výkon. Server je moc vytížený na to, aby nám vykresloval tabulku a pak to posílal po síti. Navíc by server musel vědět, jaké zařízení je na druhé straně. To všechno mě vedlo k vývoji systému na bázi JSON serveru (a jeho variantě s callback JSONP). JSON odpověď vypadá následovně: {" chyba " : 1, " v r a t i t ":{" jmeno " : " Nemocnice New"," adresa " : [ ], " " : null, " t e l e f o n " : null, " mobil " : n u l l }} Je to unifikována textová odpověď, které rozumí PHP a JavaScript. Tím se dostáváme k architektuře klienta. Klient je napsaný v HTML + JavaScript kódu. JavaScript je ale sám o sobě jen programovací jazyk, jako C nebo Java, pro zkvalitnění práce potřebujeme už hotové knihovny, takzvané frameworky. Jejich výhody (šetří kódem a fungují) a nevýhody (kompatibilita prohlížečů) nechám stranou. Jako základní framework jsem si zvolil jquery 1.9[3] a jeho grafickou nadstavbu jquery UI 1.10[5]. Pro jejich správné fungování Vám stačí starší Firefox 3, v případě Internet Exploreru, verze 8.0. Osmá verze je dostupná pro zatím nejstarší podporovaný operační systém Windows XP, jehož podpora končí v roce 2014.

48 32 KAPITOLA 4. IMPLEMENTACE Funkce v PHP a JavaScriptu spolu nemohou komunikovat napřímo, jako například PHP a MySQL. Pro jejich spolupráci existuje technologie zvaná AJAX (Asynchronní JavaScript a XML). A to slovíčko asynchronní hraje v tomto webu důležitou roli. Ne, že by AJAX neuměl být synchronní (zavolám funkci, čekám na provedení a až potom pokračuji), kombinace jquery a JSONP nás nutí dodržovat tuto asynchronnost (zavolám funkci a pokračuji dále, a za nějakou dobu dostanu odpověď, kterou zpracuji). Výhodou toho je možnost rychlejšího webu, nevýhodou jsou nároky na programátora. Výhodou použité architektury je nejen nezávislost na koncovém zařízení (dostanu text a je na mně, jak to zpracuji), ale tato struktura také nezatěžuje server, koncový zákazník nepotřebuje mít vlastní PHP server, dokonce mu stačí prohlížeč s podporou posílání AJAX (přesně XMLHttpRequest) dotazů, kde např. Firefox to má v základu. Výhodou je samozřejmě i objem datového přenosu, který je minimální. Teď se podíváte na propojení PHP a jquery. Až na jednu výjimku, veškeré rozhraní je ve složce lib v klientské části (instalační složka view ). / Provede kontrolu prih. { i n t } stupen prih. { s t r i n g } k l i c k l i c u z i v a t e l {none} vola ajax_kontrola_done ( data ) / f u n c t i o n ajax_kontrola ( stupen, k l i c ) { var adr = ucet. php? k l i c = + k l i c ; adr = ajax_server + adr ; var v r a t i t = new Array ( ) ; v r a t i t. chyba = 1; } $. ajax ({ u r l : adr, data : { } ) ; akce : 5, stupen : stupen }, datatype : jsonp, s u c c e s s : f u n c t i o n ( data, s t a t u s ) { ajax_kontrola_done ( data ) ; }, e r r o r : f u n c t i o n ( data, status, e ) { ajax_kontrola_done ( v r a t i t ) ; }

49 4.4. IMPLEMENTACE KLIENTA API A HLAVNÍ OKNO 33 Toto je ukázka, na které vysvětlím, jak to funguje. Někde v kódu zavoláte funkci ajax_kontrola(stupen, klic), které poskytnete parametr stupen a klic, které následně poskytnete PHP serveru, tedy LOKÁLU. Do proměnné adr zapíšete celou adresu lokálního serveru se jménem modulu a přístupovým klíčem. Vytvoříte proměnnou vratit, která se vrátí při selhání dotazu. Přes AJAXový příkaz $.ajax, kterému poskytnete url (adresu LOKÁLU), data (co posíláte serveru), datatype (typ serveru a formát odpovědi), success (když je vše v pořádku) a error (když je chyba), se zeptáte serveru, ale nečekáte na odpověď. Aplikace provádí další úkony, a za 10ms nebo i 100ms, i za 333ms přijde odpověď. Pokud vše bylo OK, provede se success, tedy zavolá se funkce ajax_kontrola_done(data), kde jsou data odpovědi ze serveru. Když dojde k chybě, tak se provede error, a zase se zavolá funkce ajax_kontrola_done(vratit), kde ale vratit.chyba je -1, a funkce si to musí pohlídat. Funguje to na stejném principu, jako telefonování. Někomu zavoláte telefonem, nevíte, kdy to vezme. Až to vezme, my řeknete zkontroluj záznam Josef, on zkontroluje záznam a odpoví 12, tak Vy otevřete balíček č. 12. Nebo až to vezme, a Vy řeknete zkontroluj záznam Pepa, a on odpoví chyba -1 nebo když to nikdo nevezme, máte smůlu a žádný balíček neotevřete a upozorníte na chybu vedoucího. A tak funguje ve zkratce asynchronní web něco zavoláte a nevíte, kdy přijde odpověď. Zase platí nepsané pravidlo, že funkce volání má název ajax_něco() a závěrečná má jméno ajax_něco_done(data). A ajax_něco_done(data) musí mít data.chyba, kde 1 znamená OK a něco jiného neok. Kromě API (rozhraní) k PHP serveru ve složce lib najdete soubor gibberish-aes.js [6] od Marka Percivala, tento soubor slouží k zašifrování hesla, aby se zabránilo případným odposlechům. Složka obr obsahuje obrázky použité ve webu. O složce tab se dozvíte v další podkapitole. Ve složce ui jsou uloženy kaskádové styly (CSS) jak systému, tak i jquery UI a doplňku wysiwyg, který vytvoří grafický textový editor. Také zde máte zmíněné frameworky a moduly (doplňky) pro něj ve složce js. Modulů pro frameworky je dostatek[4]. Už jsem se zmínil o wysiwyg (grafický textový editor), moduly s názvem cookie nebo md5 programátorovi nemusím vysvětlovat. Modul migrate slouží pro zpětnou kompatibilitu starších modulů, a právě tam se může vyskytnout problém u internetového prohlížeče Internet Explorer. Doplněk overscroll, který slouží pro posouvání časové osy v rezervaci díky táhnutí myší, je ve starší verzi 1.6.4, protože novější verze v IE8 hlásí chybu. Musím tak použít starší verzi modulu a modul migrate. Proto chci upozornit další vývojáře, že ne vždycky novější verze znamená něco lepšího, ale také i nefunkčnost na starších systémech. Doplněk datatables jsou tabulky a form je nástroj pro AJAXový POST bez nutnosti přesměrování, použitý u importu osob. V hlavním adresáři klienta najdete též CSS styly, které určují vzhled hlavní stránky a modulů. Rovněž tam najdete ikonku webu nebo soubor lang.xml. Což nás vede k další vlastnosti webu multijazyčnost[2]. Internetová stránka je za běžného provozu v češtině, přitom v požadavcích je vícejazyčnost webu. Právě v lang.xml je prozatím jen český a anglický jazyk, rozšíření na další jazyky nechám na jazykových odbornících, kterým stačí poskytnout tento jeden soubor. Pozor když budete měnit češtinu, musíte ji změnit jak v souboru lang.xml, tak i v kódu aplikace. lang2.xml má jazyková data pro zaměstnance.

50 34 KAPITOLA 4. IMPLEMENTACE Pomalu se dostáváte k závěru této kapitoly, a to k souborům index.html a index.js. Tento HTML soubor je napsán v XHTML Strict normě, což zaručuje ten nejpřesnější standard ve všech prohlížečích. Jinak tu není nic závratného, máme zde metadata, odkazy na kaskádové styly a skriptové soubory, pak už je to čistý HTML kód, který vytvoří základ vzhledu stránky. Soubor index.js už z názvu značí, že se jedna o JavaScriptový dokument. Máte zde nějaké globální proměnné, nějaké funkce, které jsou samozřejmě okomentované, a jquery funkci $(function()), která se provede po načtení stránky. Zase, nebudu tu rozebírat, co dělají jednotlivé funkce, toto není příručka, ale návod, který nám má pomoct pochopit strukturu a vlastnosti systému. Pokud chcete vědět, jaké funkce jsou v systému, otevřete kód v textovém editoru, a máte tam vše zdokumentováno vstupy, výstupy a co daná funkce dělá. V další podkapitole se dozvíte něco o modulech do systému a jak vytvořit vlastní. Doufám, že tato kapitola Vám pomohla pochopit, co všechno obsahuje instalační složka view a k čemu slouží jednotlivé soubory. Omlouvám se za větší používání technických termínů a zkratek, které nezasvěcenému čtenáři budou připadat jako španělská vesnice. Děkuji, že jste dočetli až sem, trochu porozuměli klientské části a jdeme na další sekci. 4.5 Moduly - KLIENT Stejně tak, jak byla rozšířitelná PHP aplikace, musí být rozšiřitelná i klientská aplikace. Přesto platí logické pravidlo musíte nejdříve rozšířit PHP část a k tomu dělat grafické rozhraní v HTML+Javascript kódu. Neplatí však, což jste mohli vidět u souborů ve složce lib, že modul v PHP musí přesně odpovídat modulu v klientském API (rozhraní). Klient může volat libovolně jakékoliv moduly na LOKÁLU a provádět jakékoliv akce. Jak jste se už dozvěděli z minulé podkapitoly, můstek mezi PHP a JavaScriptem zaručuje AJAX, díky souborům ve složce lib. Už víte, co je na straně PHP aplikace, je na čase se podívat podrobněji, co je na stráně klientské aplikace. Nastínil jsem, jak probíhá komunikace po tom můstku, a trochu jsem řekl o souborech index.html a index.js, o něž se opřu. Je na čase otevřít složku tabs, kde jsou uloženy HTML stránky, které se načítají do hlavního okna. Na rozdíl od souborů zmíněných dříve ( index.html a index.js ), tyto soubory nejsou rozdělené do dvou částí tj. JavaScript a HTML jsou v jednom souboru. Také musíte zachovat určitou HTML strukturu, protože po načtení zvolené stránky se na ní aplikují transformace od jquery UI. Jak jquery, tak i jeho grafická nadstavba jquery UI, jsou dynamické, neboli dokážou určitou část HTML kódu změnit v objekt, který reaguje na určité podněty. Vysvětlím to na příkladu. Máte díly od auta, řeknete mechanikovi (tedy jquery UI), že je to auto, a on Vám to auto postaví, a Vy můžete to auto řídit. Toto v podstatě udělá jquery UI se stránkou, kterou načte. Ale nemohou to být díly z lodi, když chcete auto. Proto musíte dodržovat určitou strukturu HTML kódu, aby to fungovalo správně.

51 4.6. NOVÝ MODUL - KLIENT tabs/uvod.html a aktualita.html Jsou to stránky, které se Vám zobrazí při startu, kde se dozvíte o novinkách a otevírací době tabs/lidi.html Tady můžete spravovat lidi a vidíte tuto stránku, když klepnete na tlačítko Správa lidí tabs/darovani.html Největší a též nejdůležitější stránka rezervačního systému. Obsahuje různé grafické a logické části, kterým se raději vyhneme a necháme je na samostatné prostudování kódu, který samozřejmě je vždy zdokumentován tabs/objekt.html, profile.html a system.html Jsou to další moduly, které odpovídají za správu objektu, systému a uživatele. 4.6 Nový modul - KLIENT Podobně jako i v PHP aplikaci, máte zde dva soubory ( /lib/empty.js a /tabs/empty.html ), které Vám pomohou vytvořit novou sekci v systému nebo pomohou porozumět struktuře současných. Soubor /lib/empty.js má ukázkové funkce volání lokálního PHP serveru, které jsem už vysvětlil, a snad jste pochopili, v minulé podkapitole. Ba /tabs/empty.html má popsanou a zdokumentovanou strukturu sekce, kterou by měl pochopit běžný programátor webových aplikací. Pokud jste přečetli všechny návody této diplomové práce, měli byste něco vědět o souborech, technologiích a způsobu jejích využití. Dozvěděli jste se, kam se podívat při vývoji nebo změně systému. Běžným uživatelům však stačí se jen přesvědčit, že systém funguje. Toto nebyla příručka, která by obsahovala výčet souborů a jejich funkcí. Toto byl návod, průvodní dopis, textový popis systému, který měl pomoct pochopit, kde a co všechno máme. Pokrok ale nezastavíš a dále se dozvíte, kam může směřovat další vývoj vzhůru k oblakům.

52 36 KAPITOLA 4. IMPLEMENTACE

53 Kapitola 5 Výhled do budoucnosti Prošli jste hodně. Z obyčejného zadání rezervačního systému, přes úvod, analýzu, seznámení se s architekturou a funkčními a nefunkčními požadavky, až na konec návody a popisem částí. Teď se podíváte do budoucnosti, a na to, co všechno může čekat tento projekt. Nejhorší vyhlídky, které mohou nastat, jsou ty, že tato práce bude k ničemu. Nedostane oblibu a podporu uživatelů nebo se nahradí komerčním konkurenčním softwarem. Skončí jako zaprášená diplomová práce v univerzitní knihovně. To by ale bylo smutné, a přidáme trochu naděje. První směr rozvoje, který vidím, je rozšíření na mobilní aplikaci (obrázek 5.1): Obrázek 5.1: Výhled do budoucnosti Právě zvolená architektura nám dovoluje téměř cokoliv. Potřebujete jen klientskou část, která umí pracovat s JSON nebo JSONP protokolem a práce se session. Popřípadě se dá naprogramovat JSON parser, neboli program, který převede textovou odpověď na data, což pro zvolenou architekturu nebude problém. A nejen odpověď je textová, PHP aplikaci můžeme kompletně řídit textovým rozhraním, takže vůbec nejste závislí na AJAX technologii. Vnější vývoj tedy spočívá v rozšíření platforem, nejen webové aplikace. 37

54 38 KAPITOLA 5. VÝHLED DO BUDOUCNOSTI Vnitřní vývoj vidím ve tvorbě modulů, též známých jako soubory rozšiřující funkčnost systému. Tato práce se vlastně točí kolem skupiny modulů, které mají na starost rezervace. Dokonce i přihlášení do systému je řešeno modulem. Což nás přivádí na další směr vývoje bezpečnost. Přestože zde jsou jedinečné mechanismy zabezpečení, které samy o sobě zabrání téměř jakémukoliv útoku, spojení s dalšími technologiemi (HTTPS nebo databázové certifikáty) udělá ze systému pevnost. Avšak i všechny zmíněné technologie jsou napadnutelné, zvlášť, když jsou teď ve vývoji různé algoritmy, které dnešní zabezpečovací technologie obejdou. Proto například i do našich počítačů musíme instalovat záplaty pro operační systémy a aplikace. Toto je tedy náhled na možný vývoj. Rozšíření platforem, tvorba nových a vylepšení současných modulů a neustálé sledování dění ve světové bezpečnosti informačních technologií. Na další stránce Vás čeká testování a závěr, kde shrnu přínos aplikace a i této práce.

55 Kapitola 6 Testování a použité nástroje 6.1 Úvod Pověděl jsem něco o vývoji aplikací jak v minulých kapitolách, tak i v úvodu. Otázka zůstává ale nezodpovězená Je systém funkční? O tomto i dalších postřezích si povíme v této kapitole. Zajisté Vám nemohly uniknout problémy s registrem vozidel. Systém byl pomalý, firma vývojářů nezkušená a napojení na centrální registry také nebylo moc úspěšné. Člověka napadne otázka: Proč?. Nedostatečné testování byl možný důvod. Proto i já, jak už jsem psal na začátku práce, se rozhodl pro malé funkce, u každé jsem kontroloval funkčnost a postupně jsem přidával další výpočet do celku po vzoru spirály. Problém nastal, když už jsem měl už hotový celek, který fungoval, ale potřeboval jsem sjednotit rozhraní, a tak jsem změnil API PHP aplikace. Došlo právě k tomu, co u registru vozidel, systém zkolaboval. Musel jsem pak každou funkci testovat znovu. Novější vývojové prostředí, jako jsou NetBeans nebo Eclipse, mají automatické testy, a tak programátoři zlenivěli. Enterprise Architektor zas pro ně vygeneruje kód z takzvaného Modelu. Ani jedno jsem z toho nepožil v době vývoje. Ne, že by to nebylo dobré nebo bych to neuměl, ale já jsem byl jediný vývojář a nepotřeboval jsem to s někým sdílet nebo někomu vysvětlovat. Jediné, co jsem potřeboval, byl pokročilý poznámkový blok Kate. Až všechno bylo sepsáno, otestováno a rozhraní bylo stabilizováno, poté jsem použil různé nezávislé kontrolory (validátory) kódu, které odstranily drobné chyby. Důvodů tohoto řešení je hned několik. První věděl jsem, kde a jak část programu dělá svou práci. Druhý mohl jsem definovat přesně, co každá funkce dělá. U Modelu s proměnnými, a zvlášť globálními, vůbec nepracujete, proto to může být velice pomalé. Došlo sice k poskvrnění programátorského pravidla o globálních proměnných, ale pokaždé žádat server o stejná data, a pak data upravovat podle nového pravidla (např. u otevírací doby), by bylo zbytečně pomalé, jak je to popsáno v Modelu. Zkušenější vývojář zálohuje data, i kdyby měl použít globální proměnné, a nemusí se ptát znovu serveru. Třetí důvod mohl jsem krok po kroku sledovat chování aplikace a opravit chod, než kdybych navrhl celý proces, který bych pak těžko optimalizoval. Popsal jsem vývoj a testování, proč jsem se rozhodl pro tento způsob vývoje a v další sekci se podíváte na použité nástroje a způsoby testování. 39

56 40 KAPITOLA 6. TESTOVÁNÍ A POUŽITÉ NÁSTROJE 6.2 Použité nástroje Vlastní testování Žádné analyzátory, unit testy či generátory jsem nepoužil. Otevřel jsem poznámkový blok a psal. Až jsem měl hotové funkce a podmínky, kód jsem už přeložil nebo spustil. A ne jen tak spustil, ale nastavil jsem kompilátor nebo interpreta, aby hlásil i tu nejmenší chybu a varování. A tak jsem pokračoval, dokud jsem neměl celek testoval jsem každou funkci, kontroloval jsem nebo upravoval vstupy, a optimalizoval jsem je PHP a MySQL Nastavil jsem v php.ini, aby mi vypsal všechno, co se mu nelíbí, a to včetně neinicializovaných proměnných, i když implicitně je to nula. Kontroloval jsem přístup k databázím, aby nedošlo při paralelnímu přístupu k nekonzistentnosti nebo náhodným výsledkům. Proto chci upozornit na použití takzvaného multiquery, což je několik MySQL dotazů v jednom řetězci. Když toto budete provádět, a pak i číst například vložené ID, tak nemusíte dostat výsledek, protože ještě není zapsaný. Budete proto muset buď dotaz rozdělit na jednotlivé, nebo zapisovat tuto dávku společně s použitím posledního vloženého záznamu. V PHP modulech také najdete řádek: error_reporting(0); Tento řádek vypne výpis chyb, na které narazí. A také se můžete přesvědčit, že je okomentovaný, takže PHP server vypíše všechny chyby. Celé testování jsem prováděl v tom to režimu, a na žádnou chybu jsem nenarazil. S tím souvisí i JSON a JSONP výstup. Tento výstup by při výpisu chyby byl neplatný, i přestože se může provést, tak pozor na hlášky. Tvrdit, že PHP aplikace je bezchybná nemohu, i přestože se tak tváří. Potřebuje projít zátěžovými testy a testy s větším počtem uživatelů. Což jsem také popisoval v úvodu ohledně registru vozidel. Testem se musí ale projít i klientská aplikace, o čem se dozvíte v další sekci HTML a JavaScript aplikace Výhodou této platformy je dostatek volně šiřitelných nástrojů na hledání chyb. Další výhodou je, že tato část jen zobrazuje data, provede menší kontrolu a posílá dotaz PHP aplikaci. Proto je skoro jedno, zdá tato aplikace bude obsahovat chyby, protože všechno má odchytit PHP aplikace. Musím upozornit zaměstnance a administrátory, že tato aplikace je přenositelná a upravitelná dle požadavků zákazníka. Proto musíte vědět, že pracujete s pravou aplikací. Je to jako když do svého domácího adresáře umístíte soubor dir.exe a poprosíte administrátora, aby ve Vaší složce spustil výpis souborů příkazem dir. Provede se škodlivý program, namísto neškodného výpisu. (Proto v Linuxu musíte zadat./dir ). PHP aplikaci je jedno, zdá jedná s mobilem, touto aplikací nebo škodlivou aplikací, která může odposlouchávat hesla. Proto používejte jen zdroje, kterým důvěřujte. Není to moje chyba, ale obdobně jako u podvodných ů, kde Vám přijde upozornění jakoby z Vaší banky, že musíte změnit údaje, a uvede odkaz na cizí stránky, i tady člověk musí vědět, s kým jedná.

57 6.2. POUŽITÉ NÁSTROJE NetBeans I přestože je to výkonné prostředí pro vývoj, které má podporu PHP, HTML a JavaScript, nepoužil jsem ho při vývoji. NetBeans byl původně navržen pro jazyk Java, a také je v tom dobrý. Naopak doplňky, které zapnou podporu C/C++, PHP nebo HTML obsahují jen základní funkce. Nedokážou upozornit na nedeklarovanou nebo nepoužitou proměnnou. Nedokážou správně pracovat s XHTML a také jquery logikou, kde pracujete s id nebo class, a hlásí je jako nevyužité. To co umí, je formátování kódu. Takže kódy ve zdrojových souborech jsou zarovnaně. Také mě upozornil na některé podmínky ( === místo == ) v JavaScriptu, které nedokázal odhalit další nástroj Výborný nástroj na kontrolu JavaScript kódu. Odhalí už zmíněné podmínky, středníky, tečky a závorky v kódu. Mohu poznamenat, že jak tady, tak i v NetBeans, prošel kód této práce na zelenou Asi nejrozšířenější nástroj na kontrolu standardu HTML. Zase mohu hlásit, že statický kód je v tom nejpřísnějším standardu XHTML 1.0 Strict. Tady však musím upozornit, že prohlížeče tento standard předělají na svůj, aby vzhled byl co nejvíce jednotný v každém prohlížeči. Také jak jquery, tak jquery UI upravují HTML a JavaScript dynamicky, takže konečný kód má jiný standard. Dokonce když dáte v prohlížeči uložit stránku do souboru, tak například místo <br/>, což je standard XHTML, bude uloženo <br>, což už je standart HTML php Jako nejlepší nástroj pro kontrolu a testování jsem využil přímo interpreta tohoto programovacího jazyka program php. V php.ini jsem nastavil hlásit a vypsat všechny chyby (E_ALL), pro znalce C/C++ je to něco jako režim Wall a pedantic. Do toho jsem ještě doinstaloval pluginy, které také prověřily kód.

58 42 KAPITOLA 6. TESTOVÁNÍ A POUŽITÉ NÁSTROJE 6.3 Uživatelské testování Úkol: Přihlásit se Provést rezervaci na příští týden ve středu v 15:15 Odhlásit se Toto testování jsem prováděl jak já, tak i kamarádí a kolegové různých věkových skupin a vzdělání. Dostál jsem několik připomínek, které jsem opravil, ale jednalo se o zvýraznění dat. Všechno je přesně definováno a ovládaní je intuitivní, a každý byl schopen provést daný úkol bez toho, aby se díval do příručky. Byly i připomínky, jako aby uživatel neviděl jednotlivé separátory, ale na otázku, jak by to chtěli jinak zobrazit, jsem nedostal odpověď. Grafické rozhraní má za úkol zobrazit přehledně data a PHP aplikace zas hlídá oprávnění. Proto uživatelské testy se týkají jen klienta a vzhledu, protože každý modul PHP aplikace na začátku provede kontrolu práv uživatele. A i běžný nezkušený uživatel dokázal provést rezervaci bez příruček, které najdete na konci této práce. Tím bych tuto sekci ukončil a nechal uživatele udělat názor na vzhled a chování aplikace. 6.4 Závěr Důležité je, aby kód obsahoval co nejméně chyb, proto jsem zvolil tento vývoj a testování. O funkčnosti webu se můžete přesvědčit na veřejném serveru: Adresa: Username: admin, valentin, user4 Heslo: Heslo123 Též v příručkách najdete ukázky funkčnosti jednotlivých modulů, a každý z nich byl testován, jak jsem popsal výše. Požadovaná funkčnost byla splněná dle poskytnutého souboru a starého systému. Ba i doplněná o další. Systém je připraven k ostrému provozu. Je modulární a dokáže pracovat jak s jinými klienty, včetně mobilních platforem, tak i s rozhraním proprietárních a otevřených modulů. Tedy vytvořil jsem stabilní základ a funkčnost, bezpečný web a čeká nás závěr této písemné práce.

59 Kapitola 7 Závěr Závěr? Zní to, jako kdyby něco mělo skončit. Ano, blížíme se ke konci této diplomové práce, tedy písemné části. Konce jsem nikdy neměl rád, i přestože všechno jednou skončí a my musíme jít dále. Dále zkoumat nové možnosti a příležitosti. Konce starých dobrých časů na střední, bezstarostných časů dětství nebo krásných časů v práci asi zažil každý. Občas se tam chceme vrátit a změnit to, co bylo. Pak si ale uvědomíme, že díky těm časům a koncům jsme lepší než předtím a díky nim jsme teď tam, kde jsme. Někdo v horší situaci, někdo v lepší. Toto je i tento případ. Tato diplomová práce vznikla na základě něčí potřeby, jehož potřeba teď končí nebo změnila jeho pohled. Tato diplomová práce uzavřela jednu z kapitol života studenta ČVUT. Tato diplomová práce zůstane v paměti čtenářů a, jak jsem už psal, v universitní knihovně. Nezbývá jen doufat, že bude dobře sloužit. Když otevřete stránky ať už Vašeho oblíbeného vyhledávače, nebo sociální sítě, denně vidíte práci stovek až tisíců programátorů. Některých nezkušených, některých průměrných a některých nadprůměrných. Nějakého studenta, zaměstnance nebo vzor ze šablony, který ale předtím někdo vytvořil. Stránky informativní, poučné, zábavné nebo jako tato práce rezervační. Jsou placené nebo open-source platformy. Stránek jsou na světě milióny, tisíce z nich jsou kvalitní a máme zde stovky technologií. Výkon prohlížečů se zvyšuje, zvyšuje se i náročnost na kvalitu stránek. Byl to jeden z důvodů, proč starý systém dosloužil. Přestože ve své době mohl patřit ke špičce. Každý projekt má svou životnost. Vždy přijde čas se poohlédnout po nových možnostech. Zda se tento projekt usadí a kolik vydrží, nemůžeme s jistotou říct. Proto byla tato diplomová práce rozdělená na několik částí a různé technologie. Každá část je nahraditelná a můžeme ji libovolně změnit nebo optimalizovat. Toto jsem už řešil v předchozí kapitole. Nové technologie nás tlačí dopředu a ten, kdo se zastaví, se těžko vrátí zpět na výsluní. Odešli jsme ale od tématu, a je na čase se k němu vrátit. Právě jste dočetli dokumentaci k diplomové práci, která řeší problematiku rezervačního systému pro dárce krevní plasmy, věci, která jak už jsem naznačil, je dost důležitá pro každého z nás. Výsledek můžete vidět jak před sebou, tak i ve svém internetovém prohlížeči. Výsledek, který funguje a který můžete používat. Výsledek, co uvádí práci studenta elektrotechnické fakulty. A výsledek, jenž je bezpečný a spolehlivý. A toto je jeho poslání a účel. 43

60 44 KAPITOLA 7. ZÁVĚR

61 Literatura [1] DB Designer Fork. stav z [2] Google. stav z [3] jquery,. stav z [4] jquery plugins,. stav z [5] jquery UI,. stav z [6] Gibberish AES. stav z [7] jsdoc-toolkit. stav z [8] PHP manual,. stav z [9] phpdocumentor 2,. stav z [10] Stack Overflow. stav z [11] PAVEL KANTOR, D. V. Specifikace požadavků,

62 46 LITERATURA

63 Příloha A Příručky úvod Tato část má za úkol seznámit jak běžného uživatele, tak i redaktora, administrátora na objektu, guru, ba dokonce vývojáře, s tím, co systém umí a co byste měli zvládnout vy. Počáteční kapitoly jsou nejjednodušší, ale každá další chce hlubší znalosti problémů nebo technologie. Můžete narazit na pojem nebo termín, kterému nebudete rozumět, protože jste nějakou kapitolu nebo kapitoly přeskočili, přestože se budu snažit psát co nejméně odborně, i když to Vám může připadat dětinské a samozřejmé. Také se budu pokoušet uvést jednoduché příklady ze života, abyste pochopili, jak systém funguje. Jak jsem upozorňoval předtím a budu upozorňovat dále, toto jsou návody, ne příručky. Nehledejte zde manuál k funkcím a souborům, co soubory dělají a vysvětlení seznamu akcí. Proto existují přílohy na CD, kde najdete až 100 stránkovou automaticky vygenerovanou dokumentaci PHP aplikace[9][7]. Po přečtení příslušných kapitol budete znát základní vlastnosti systému pro určitého uživatele. Některé vlastnosti jsou však vynechané nebo jen nastíněné. Určité způsoby, jako rozbalovací seznam, jsou intuitivní. Intuitivním jsem se pokoušel udělat i celé ovládání. Pokud jste běžný uživatel, můžete tuto část přeskočit. Pro redaktora mám tip, aby vyplňoval všechny položky ve formuláři, i kdyby tam musel napsat nemá. Admin na objektu by měl přečíst, jak fungují otevírací a nedostupní pravidla, aby se předešlo nedorozumění, že to pravidlo tam je, ale není v systému. A guru ať zkontroluje MASTER logy, když systém nechce zakládat nové rezervace nebo měnit aktuality. A všichni, koho jsem zmínil v minulém odstavci, mohou tento návod jen prolistovat a hledat zde odpovědi, pokud narazili na problém, který nemohou vyřešit, což doufám nenastane. Na další stránce se dozvíme, jak vypadá úvodní stránka a co všechno tam najdeme. Výlet do grafické části začíná. 47

64 48 PŘÍLOHA A. PŘÍRUČKY ÚVOD

65 Příloha B Návod pro uživatele B.1 Úvod Žádný návod či příručku nepotřebujete. Web je intuitivní a vše, co se v této kapitole dozvíte, jsou spíše výpisy funkcionality a místa, kde máte tuto funkčnost hledat. Rozhraní bylo inspirováno ze známých a často používaných webů, jako jsou sociální sítě, on-line TV programy nebo e-shopy. Samozřejmě stejné ovládaní mají i jiné internetové stránky. Takže pokud nemáte problém, který nemůžete vyřešit, klidně tuto kapitolu přeskočte a jděte rovnou na internetové stránky. Jestli se chcete dozvědět více o tom, co web umí, směle čtete dál. B.2 Požadavky Webové rozhraní využívá vývojové prostředí, neboli framework, jquery, jquery UI a jeho zásuvné moduly (pluginy). Proto se požadavky na internetové prohlížeče odvíjí od požadavků těchto vývojových prostředí. Pro správné fungování stránek potřebujete jeden z těchto prohlížečů: Internet Explorer 8 nebo vyšší, Firefox 3+, Opera 10+ nebo současnou verzi Google Chrome nebo Chromium. Pokud jako internetový prohlížeč používáte Konqueror a jeho jádro KHTML, nainstalujte prosím do něj jádro Webkit. Také pozor na identifikaci Konqueroru, nesmíte použít cizí identifikaci prohlížeče nižší, než je uvedeno výše. To platí, i jestli používáte Rekonq. 49

66 50 PŘÍLOHA B. NÁVOD PRO UŽIVATELE B.3 Úvodní stránka Obrázek B.1: Úvodní stránka První, co spatříte po načtení stránky, jsou úvodní stránky s aktualitami (obrázek B.1), názvem objektu (1) a přihlašovacím formulářem (2). Pokud chcete změnit aktuální jazyk nebo jste zapomněli svoje heslo, použijte, prosím, panel v pravo (3). U zapomenutého hesla musíte znát svoje přihlašovací jméno (Username), a telefonní číslo. Jestli jste neměli uvedený telefon, zkuste zadat základní telefonní číslo: (bez mezer). Pro přihlášení použijte, prosím, přihlašovací formulář (2) a zadejte buď původní jméno ( ) a heslo ze starého systému, nebo údaje, které jste dostali elektronickou poštou. Pozor na malá a velká písmena a Caps Lock. Když heslo zadáte špatně, systém to zaznamená, aby odhalil případného útočníka, a když heslo zadáte 3 krát špatně, budete muset počkat 10 sekund na další pokus.

67 B.3. ÚVODNÍ STRÁNKA 51 B.3.1 Otevírací doba Obrázek B.2: Otevírací doba Na úvodní stránce (obrázek B.2) se též dozvíte běžnou otevírací dobu (1), svátky a mimořádné dny (2) nebo dlouhodobé změny v otevírací době a od kdy do kdy platí (3). Také se dozvíte kontaktní informace a adresu příslušného objektu (4). Návody a nápověda budou přibývat v dalších dvou podsekcích.

68 52 PŘÍLOHA B. NÁVOD PRO UŽIVATELE B.4 Darování B.4.1 Výběr data Obrázek B.3: Výběr data Po úspěšném přihlášení budete přesměrováni na stránku Darování do podsekce Stabilní odběr (obrázek B.3). Též zmizí přihlašovací formulář a objeví se tlačítko s Vaším jménem (1), díky kterému se dostanete na svůj profil, a panel s tlačítkem Odhlásit a automatickým odhlášením (2). Čas se obnovuje po projevení aktivity, ale jen po uběhnutí 1/4 celkové doby, tedy po 5 minutách, proto nemějte obavy. Pro provedení rezervace, prosím, zvolte datum v kalendáři (3), které se také zobrazuje níže společně s výběrem, co chci darovat (4). Po zvolení data a odběru, prosím, pokračujte dál tlačítkem Další krok (5).

69 B.4. DAROVÁNÍ 53 B.4.2 Výběr času Obrázek B.4: Výběr času V další sekci (obrázek B.4) se objeví tabulka s časem (1) a seznamem odběrných jednotek (2), v případě darování plasmy - seznam separátorů. Pro pohyb v čase stačí táhnout myší vnitřní pole tabulky. Novou rezervaci můžete provést 3 způsoby. První způsob je, že chytnete myší červený čtvereček JÁ (3) a přitáhnete ho do zeleného pole, kde se ukotví (4). Druhý způsob je kliknutí kamkoliv na zelenou plochu a program ukotví Vaší rezervaci na nejbližší možné místo. Doladit čas a jednotku můžete díky formuláři níže (7), kde nastavíte jednotku a čas přesně na minuty, což je také třetí způsob. Obnovit data můžete díky tlačítku Obnovit (8), dále vidíte žlutě (5) přestávky a výluky nebo červeně (6) rezervace jiných lidí a zamluvené časy. Tlačítkem Další krok (9) zamluvíte určený termín a máte 20 minut na jeho potvrzení.

70 54 PŘÍLOHA B. NÁVOD PRO UŽIVATELE B.4.3 Rekapitulace Obrázek B.5: Rekapitulace Třetí a závěrečná sekce je rekapitulace (obrázek B.5). Máte lístek, zamluvený čas, který musíte potvrdit do 20 minut. Na něm jsou uvedeny Vaše údaje, co a kde darujete, začátek, konec a stav (1). Zvolte, prosím, jakým způsobem chcete být upozorněni (2) ráno em nebo/a hodinu předem díky SMS (jen pokud máte operátora O2, Vodafone nebo T-Mobile a máte povolené SMS z internetu). Pro potvrzení rezervace dejte, prosím, tlačítko Pokračuj (3) a počkejte na potvrzovací dialog. B.4.4 Změna a odstranění Chcete-li už potvrzenou rezervaci změnit nebo odstranit, máte dva způsoby. První najdete příslušný den a svoji rezervaci (obrázek B.6). Obrázek B.6: Moje rezervace Klepnutím na ikonku koše danou rezervaci odstraníte, nebo klepnutím na červenou zónu můžete rezervaci přesouvat, jako by byla nová.

71 B.4. DAROVÁNÍ 55 B.4.5 Moje rezervace Obrázek B.7: Moje rezervace Druhým způsobem je výpis všech rezervací v druhé podsekci (obrázek B.7) Moje rezervace (1) stránky Darování. Kde nadcházející rezervace můžete upravit (2) nebo odstranit (3). B.4.6 Události Další podsekcí stránky Darování jsou Události (obrázek B.8). Obrázek B.8: Události Díky tlačítku Načti (2) načtete možné události. Vždy tam máte datum, kdy událost probíhá, místo, popis a Váš stav (3). Pokud nejste potvrzen, můžete se na událost přihlásit nebo se z ní odhlásit (4).

72 56 PŘÍLOHA B. NÁVOD PRO UŽIVATELE B.5 Můj profil Obrázek B.9: Můj profil Do sekce Můj profil (obrázek B.9) se dostanete kliknutím na tlačítko s Vaším jménem (1) vpravo nahoře. První, co uvidíte, jsou Vaše údaje (jméno, příjmení, oprávnění, kontakty,... ) v systému (2), pak si můžete všimnout statistiky rezervací (3) a statistiky událostí (4). Pokud budete chtít změnit přihlašovací jméno (Username), jméno nebo datum narození, obraťte se, prosím, na zaměstnance objektu. Avšak telefon, operátora, nebo heslo můžete změnit sami. Obrázek B.10: Změna hesla Proto slouží druhá podsekce Změna údajů (obrázek B.10). Kde pro změnu hesla zadáte staré heslo a dvakrát nové heslo, které bude mít nejméně 6 písmen. Svůj telefon, operátora a změníte díky druhému formuláři (3). Změní se tak i údaje pro zapomenuté heslo, proto si změněné údaje pamatujte, jinak se pak budete muset obrátit na zaměstnance objektu.

73 B.5. MŮJ PROFIL 57 Obrázek B.11: Vzkazy Třetí a poslední podsekcí jsou Vzkazy (obrázek B.11). Zde se dozvíte důležité sdělení (2), na které Vás upozorní systém em. Toto jsou základní funkce systému. Doufám, že budete spokojeni, a neváhejte se obrátit na zaměstnance v případě nejasností. Děkujeme.

74 58 PŘÍLOHA B. NÁVOD PRO UŽIVATELE

75 Příloha C Návod pro redaktora C.1 Úvod V této kapitole se dozví běžný zaměstnanec, co všechno smí a může dělat a jak na to. Platí zde stejné pravidlo, jako u návodu pro uživatele pro práci, můžete toto přeskočit a podívat se sem jen v případě problému. Také platí pravidlo intuitivního chování a uvádění všech důležitých políček, typu rodného čísla, i když tam dáte nesmysl. Program počítá, že na druhé straně sedí zkušenější uživatel, ale když program objeví zásadní chybu, operaci neprovede a vypíše chybu. 59

76 60 PŘÍLOHA C. NÁVOD PRO REDAKTORA C.2 Změna od běžného uživatele Obrázek C.1: Správa aktualit První změnou od běžného uživatele je správa aktualit (obrázek C.1). Můžete aktualitu odstranit, upravit nebo přidat novou (1). Po kliknutí se objeví dialog, kde zadáte titulek (2), datum (3), obsah a barvu (5) aktuality. Obsah můžete formátovat jako ve Wordu díky tlačítkům (4) nad ním. Úpravu nebo novou aktualitu potvrdíte tlačítkem OK (6). Obrázek C.2: Hledání uživatele Další změnou od obyčejného uživatele je formulář Jméno (obrázek C.2) v sekci Darování. Díky tomuto formuláři můžete zarezervovat termín cizím jménem nebo vypsat rezervace v podsekci Moje rezervace a upravovat je. Rozdíl je i ve výběru termínů, kde můžete odstranit nebo přesunout rezervaci kohokoliv i s kolizí bloků. Musíte však každou změnu potvrdit, jako byste byli běžný uživatel. Také po klepnutí na rezervaci se Vám vypíše jméno, budoucí a předchozí rezervace v podsekci Moje rezervace.

77 C.3. SPRÁVA LIDÍ 61 C.3 Správa lidí C.3.1 Nová registrace Obrázek C.3: Nová registrace Další viditelnou změnou je tlačítko nahoře se jménem Správa lidí (1), jehož první podsekcí je Nová registrace (obrázek C.3). V tomto formuláři musíte vyplnit všechny položky, až na poznámku, když tyto údaje nemáte, tak buď nechte, co tam je (telefon, operátor a datum narození), nebo zadejte správný tvar (jméno, příjmení a (4)), nebo napište třeba nemá u rodného čísla (5). Přihlašovací údaje budou uživateli poslány na (4). Uživatel musí mít jedinečné přihlašovací jméno (Username (2)), systém Vás upozorní animací buňky v případě, že už takové jméno existuje. Jinak můžete zadat cokoliv od ové adresy po celé jméno s háčky a čárkami Tomáš Novák. Položka Práva určuje oprávnění uživatele. Práva jsou následující: 1 = obyčejný uživatel, 2 = redaktor, 3 = administrátor na objektu, 4 = guru. Nemůžete dávat větší číslo, než je Vaše. Do položky Objekt se píšou ID čísla objektů. Když nejste guru, měňte jenom číslo Práva. Když jste guru, můžete do práv napsat: 1,3 a objektu: 2,5 to znamená, že uživatel bude mít práva běžného uživatele na objektu s ID 2 a práva administrátora na objektu s ID 5. Registraci potvrdíte tlačítkem Nový (6). Úspěšný zápis se vypíše v konzoli (7).

78 62 PŘÍLOHA C. NÁVOD PRO REDAKTORA C.3.2 Upravit osobu Obrázek C.4: Upravit osobu Upravit nebo odstranit uživatele a resetovat heslo můžete v další, tedy druhé, podsekci Upravit osobu (obrázek C.4). Formulář se jménem (2) funguje jako v Darování. Můžete resetovat heslo uživatele, které se mu odešle na . Pozor, systém zaznamenává tuto aktivitu, abyste neresetovali heslo administrátorů každou minutu. Upravit osobu můžete jen se stejným nebo s nižším oprávněním v celém systému. Můžete zapsat uživatele do svého objektu díky položkám Práva a Objekt (4). Připsáním do práv..., 1 (čárka a číslo) pro obyčejného uživatele a..., 3 do objektu, kde 3 je Váš objekt. Změnu potvrdíte tlačítkem Upravit (5), kde úspěšné provedení uvidíte v konzoli (7). Zablokovat uživatele můžete odstraněním hodnot z Práva a Objekt (4) a potvrzením Upravit (5). Odstranění buď z Vašeho objektu, nebo z celého systému dosáhnete díky tlačítku Odstranit (6).

79 C.3. SPRÁVA LIDÍ 63 C.3.3 Výpis lidí Obrázek C.5: Výpis lidí Výpis lidí (obrázek C.5) je třetí podsekce Správy lidí. Zde můžete vypsat lidi z celého systému a to buď od určitých ID do určitých ID (2), nebo podle seznamu ID (3) ve tvaru: 2,4,5,7 pro 4 uživatele s daným ID, nebo pole nechat prázdným pro zobrazení všech lidí. Vyhledávat obsah můžete díky Search (4) a listovat v seznamu pomocí tlačítek dole (5).

80 64 PŘÍLOHA C. NÁVOD PRO REDAKTORA C.3.4 Výpis rezervací Obrázek C.6: Výpis rezervací Dostáváte se do druhé poloviny podsekcí. Čtvrtou položkou v seznamu je Výpis rezervací (obrázek C.6). Zde se můžete dozvědět průběh předchozích a nadcházejících darování. Stačí zadat, od kterého do kterého data, a vypsat odběry a zmáčknout tlačítko Načti (2). Můžete zas listovat (3) a vyhledávat v tabulce. Též můžete omezit seznam na určité jednotky nebo lidi, kde zadáte jejich ID v už známém tvaru 3,5,6,9. C.3.5 Události Obrázek C.7: Události

81 C.3. SPRÁVA LIDÍ 65 Pátou a předposlední podsekcí jsou Události (obrázek C.7). Zde je správa něčeho jiného, než událostí. Aktivní události načtete pomocí tlačítka Načti (2), kde se vypíšou už do známé tabulky. Tlačítkem Nová událost (3) vytvoříte překvapivě novou událost. Tenhle dialog (obrázek C.8) uvidíte při zakládání nové nebo úpravě (6) staré události. Obrázek C.8: Nová událost Máte tu jméno události (1), počáteční a koncové datum (2), místo (3), popis (4) a barvu (5). Změnu nebo novou událost zrušíte tlačítkem Storno, potvrdíte to tlačítkem OK (6). Událost odstraníte tlačítkem koše (7) z obrázku C.7, a lidi, které se událostí zúčastní nebo jsou přihlášeni, zobrazíte díky tlačítku Upravit lidi (4). Obrázek C.9: Upravit lidi Tento dialog (obrázek C.9) se zobrazí, když chcete upravit lidi, kteří se zúčastní události. Pokud si nejste jistý v ID, zkopírujte obsah a dejte Výpis lidí, kde se zobrazí podrobnosti. Přihlášení lidé (1) jsou lidé, kteří mají zájem se události zúčastnit a potvrzení (2) jsou lidé, kteří jste už potvrdili. Je však jedno, jak se kdo přihlašoval nebo byl potvrzen, zapíšete ID už ve známém tvaru: 1,3,13,16 do dvou položek ve formuláři a dáme OK (3). zúčastněným (potvrzeným) lidem pošlete díky tlačítku Poslat y (5) z obrázku C.7.

82 66 PŘÍLOHA C. NÁVOD PRO REDAKTORA C.3.6 Vzkazy Poslední a šestou podsekcí jsou Vzkazy (1). Obrázek C.10: Vzkazy Vzkazy (obrázek C.10), na rozdíl do ostatních položek, nejdou upravit, jen odstranit (5), protože poslané y také nemůžete upravit. Vzkazy můžete načíst pomocí tlačítka Načti (2) a obsah uvidíte dole (4). Nový vzkaz (obrázek C.11) vytvoříte tlačítkem Nový vzkaz (3). Obrázek C.11: Nový vzkaz Zadáte ID (1) už ve známém tvaru 3,5,7,13 nebo -1 pro všechny lidi na objektu. Též zadáte předmět (2), datum (3), obsah (4) a barvu (5), jako ve všech ostatních dialozích. Vzkazy odešlete tlačítkem OK (6) a systém upozorní zadané uživatele em, že mají vzkaz.

83 C.4. ČASTO KLADENÉ OTÁZKY 67 Tohle je ve stručnosti vše, co můžete jako redaktor provádět, a jestli jste to dočetli až do konce, tak děkuji, protože jak jsem psal na začátku, vše by mělo být srozumitelné a uvítal bych připomínky, proč a čemu jste nerozuměli. C.4 Často kladené otázky Jak zobrazím nebo zapíšu rezervaci jiné osobě, než sobě? Obrázek C.12: Cizí rezervace Jako redaktorovi se Vám zobrazí v Darování formulář (obrázek C.12), kde můžete po napsání jména, příjmení nebo username vyhledávat určitou osobu. Po zvolení osoby můžete zobrazit její rezervace nebo se přihlásit na termín, jako byste byli dotyčná osoba. Mohu zapisovat rezervace, nemohu však měnit aktuality a osoby. Platí i pro administrátora na objektu. Požádejte hlavního správce (guru) o kontrolu MASTER logu. Nemohu změnit osobu, která má na jiném objektu vyšší oprávnění než já. Samozřejmě, je to z důvodu bezpečnosti, kde se dva redaktoři na různých objektech se domluví a změní u administrátora a pak resetuji heslo. Proto můžete upravovat jen data lidí se stejným nebo nižším oprávněním. Proč nemohu být současně přihlášen na dvou různých počítačích zároveň? Systém hlídá aktivitu uživatele. Z důvodu bezpečnosti můžete být přihlášen jen na jednom počítači a skoro jakýkoliv pokus o porušení tohoto pravidla odhlásí oba počítače.

84 68 PŘÍLOHA C. NÁVOD PRO REDAKTORA

85 Příloha D Návod pro administrátora D.1 Úvod Dostali jste se k návodu pro administrátory na objektu, druhého nejvýše postaveného oprávnění v systému. Má všechna práva redaktora, plus spravuje otevírací a výlukovou dobu, jednotky, kontakty a odběry na objektu. Je to jediný případ, u kterého se musíte dívat do návodu, protože jsou tu dvě následující pravidla. Pravidlo otevírací doby máte svátky a mimořádné dny, mimořádné doby a standardní otevírací dobu. Svátky a mimořádné dny jsou jasné jedno datum, jedna určitá otevírací doba. Zábava začíná u mimořádných dob, musíte nejprve zvolit, od kdy platí, což je zatím v pohodě. Pak musíte zvolit, do kdy platí nebo do neznáma, a zábava začíná. Teď už všechny mimořádné doby, které se kryjí s právě vytvořenou, musí mít stejný počátek a konec, proto musíte zvolit období moudře. Platí to z důvodu jednoznačnosti otevírací doby. Pak musíte zvolit, pro který den nebo dny (Po-Pá) platí, a vždy nejdříve platí jednotlivý den. Pro ostatní dny, které nesplňují podmínku mimořádné doby, platí standardní otevírací doba nebo je zavřeno. V krátkosti: Chci otevírací dobu na (čtvrtek). Podívám se, jestli je to v seznamu mimořádných dnů je=dám otevírací pravidlo. Není podívám se, zda je v seznamu období, co kryje zvolené datum je=podívám se, zda existuje pravidlo pro čtvrtek, v druhém kole po pravidlu Po-Pá. Není podívám se po pravidlu ve standardní době pro čtvrtek, a zase v druhém kole po pravidlu Po-Pá. Další vysvětlení objekt má jediné pravidlo standardní doby, že Po-Pá má otevřeno 08:00-18:00 a nějaké pauzy. Tak je od pondělí do pátku otevřen od 8 hodin do 18 hodin. V pátek je ale málo lidí, tak chcete upravit, aby bylo otevřeno do 16 hodin tak jen přidáte pravidlo do standardní doby, že pátek má otevřeno 08:00-16:00. Tak od pondělí do čtvrtka máte od 8 do 18, a pátek od 8 do 16 hodin. Zatím rozumíte pátek má vyšší váhu, tak vítězí. Celý příští měsíc má půlka zaměstnanců dovolenou, tak potřebujete mít zavřeno v pondělí a pátek, a sobotu (jen příští měsíc) mít otevřeno od 10 do 14 hodin. Tak přidáte pravidlo mimořádné doby od do pro pondělí, že má zavřeno (prázdný řetězec v Otevřeno ). Pak přidáte pravidlo od do pro pátek, že má zavřeno. Pak přidáte pravidlo mimořádné doby od do pro sobotu, že má otevřeno 10:00-14:00. Tak se Vám objeví tabulka mimořádné otevírací doby, která 69

86 70 PŘÍLOHA D. NÁVOD PRO ADMINISTRÁTORA platí od , kde bude: Pondělí zavřeno, od Úterý po Čtvrtek 08:00 18:00, Pátek zavřeno, Sobota 10:00 14:00 a Neděle zavřeno. Zatím srozumitelné vždy platí pravidlo nejvyšší váhy. Sobota se Vám osvědčila, ale nechcete to ještě zavádět napevno, protože nevíte, do kdy se Vám to vyplatí. Tak políčko Platí DO necháte prázdné. Nebo v půlce května Vám vypadla hlavní lékařka, která ordinovala ve středu, tak potřebujete mít od zavřeno ve středu do neznáma. Pokud se pokusíte přidat mimořádnou dobu od do neznáma (prázdný řádek), tak neuspějete, protože se doby kryjí. Budete muset přidat pravidlo od do pro středu, že má zavřeno, pak pravidlo od do neznáma pro středu a zavřeno. Srozumitelné protože pravidla na pondělí a pátek platí jen do a pak už ne. Základní logiku otevírací doby snad chápete, teď pravidla nedostupné doby. Obdobně jako u otevírací doby, máte 3 druhy mimořádné dny, mimořádné doby a standardní dobu. Platí stejná pravidla data a opakování. Na rozdíl od otevírací doby, nedostupná doba zakáže rezervaci v daný čas. Také platí, že nedostupný čas platí pro skupinu odběru a nedědí se. Např. máte standardní pravidlo, že v pátek jednotka 4, která odebírá plasmu, je nedostupná po celý den. Tak jestli přidáte pravidlo mimořádné doby nebo dne na pátek na jednotku 2, která také odebírá plasmu, v ten den nebo dobu pravidlo na jednotku 4 neplatí, a budete ho muset znovu zapsat. Důvod je jednoduchý, normálně je jednotka 4 v pátek mimo provoz, ale zrovna v ten den máte Světový den odběru, a potřebujete mít všechny jednotky aktivní. Proto Vám stačí přidat pravidlo, kde nedefinujete nedostupní dobu, a stačí pro jednu jednotku ve skupině, a funguje to. Jiný rozumnější způsob negování nedostupných časů jsem nenašel. Proto musíte všechny potřebné nedostupné časy pro mimořádný den nebo dobu zapsat znovu. Pořád nesrozumitelné? Tak jinak, pravidla jsou v následujícím pořadí: Mimořádný den Mimořádná doba pro 1 den Mimořádná doba pro pracovní dny Standardní doba pro 1 den Standardní doba pro pracovní den Žádné pravidlo. Vždy se vybere to nejvyšší pravidlo pro dané datum nebo den a víc ne nedívá se také pod sebe. Otevírací pravidla platí pro celý objekt a jednotky a dědí se. Nedostupná pravidla platí pro odběrovou skupinu a nedědí se. Konec popisu a ukážeme si, jak to vytvoříte.

87 D.2. SPRÁVA OBJEKTU 71 D.2 Správa objektu D.2.1 Rozvrh Obrázek D.1: Rozvrh Po přihlášení administrátora na objektu se objeví tlačítko Správa objektu (1). První podsekcí je Rozvrh (obrázek D.1), kde můžete upravit otevírací dobu. Máme tlačítko Přidat pravidlo (2), seznam mimořádných dnů (3), seznam mimořádných dob (4), seznam standardních dob (5) a tlačítka na správu úprava (6) a odstranit (7). Obrázek D.2: Otevírací doba

88 72 PŘÍLOHA D. NÁVOD PRO ADMINISTRÁTORA Pro nové pravidlo nebo úpravu slouží dialog, který vidíte na obrázku D.2. Zvolíte, nebo máte předvolen, Typ (1) Mimořádný den, Mimořádná doba nebo Standardní doba, jejichž popis a účel je popsán v úvodu. Podle Typu zvolíte datum nebo platnost (2) a pro který den (3). Zadáte otevírací dobu ve tvaru HH:MM-HH:MM nebo necháte prázdnou pro zavřeno. Je důležité psát i počáteční nuly (08:00). Zvolíte pauzy (5) ve tvaru HH:MM-HH:MM,HH:MM-HH:MM,... jako otevírací doba oddělaná čárkami, nebo můžete nechat prázdnou pro žádné pauzy. Jestli chcete, aby se už zapsané budoucí rezervace podřídily tomuto pravidlu, zaškrtnete Aplikovat na současné (6), kde se rezervace mimo pracovní dobu odstraní a systém pošle , že daná rezervace byla zrušena. Pravidlo potvrdíte tlačítkem OK (7). D.2.2 Jednotky Obrázek D.3: Jednotky Druhou podsekcí Správy objektu jsou Jednotky (obrázek D.3). Zase je tu tlačítko na přidání nového pravidla (2), editaci pravidla (11) nebo jeho odstranění (12). Oproti předchozí podsekci, kde jste měli mimořádné dny (8), mimořádné doby (9) a standardní doby (10), máte navíc černý formulář Seznam jednotek (3). Jeho chování je poněkud odlišné, máte seznam ID jednotek (4) a počet jednotek (5) určitého odběru. Dále je odlišné chování tlačítek. Tlačítko pro editaci (6) nastaví počet (5) jednotek, vybranou jednotku needituje. Naopak tlačítko odstranění (7) odstraní jen jednu vybranou jednotku (4). Systém se pokusí najít pro kolizní rezervaci volnou sousední jednotku namísto odstraněné nebo odstraněných, v případě hromadného snížení počtu (6). Případné odstranění bude oznámeno vlastníkovi rezervace em.

89 D.2. SPRÁVA OBJEKTU 73 Obrázek D.4: Nedostupní doba Zde máte obdobný dialog (obrázek D.4) pro nedostupnou dobu, jako pro otevírací dobu. Typ (1), platnost (2) a den (3) jsou stejné jako předtím. Rozdíl je, že platnost doby musí být identická pro skupinu, když v otevíracích pravidlech musela být pro celý objekt. Skupinu a jednotku zvolíte díky selektorům (4). Napíšete už ve známém tvaru HH:MM-HH:MM nedostupný čas (5) a opět zvolíte, zda systém má upravit existující rezervace dle nového pravidla. I zde se systém pokusí najít sousední jednotku, jestli nedojde ke kolizi. Tlačítko OK (7) Vám dané pravidlo vytvoří. D.2.3 Nastavení Obrázek D.5: Nastavení

90 74 PŘÍLOHA D. NÁVOD PRO ADMINISTRÁTORA Třetí a poslední podsekcí jsou Nastavení (obrázek D.5). Tlačítko Přidat pravidlo (2) přidá nové pravidlo pro odběry, které definuje guru systému. Co definujete Vy, jsou nastavení, která platí pro odběr. Toto pravidlo můžete odstranit (4) nebo editovat (3). Pak můžete nastavit jméno objektu (5), adresu (6), , telefon nebo mobil (7), které se zobrazí na úvodní stránce. Obrázek D.6: Odběry Tento dialog (obrázek D.6) dostanete, když přidáváte nové pravidlo odběru nebo existující pravidlo upravujete. Máte na výběr (1), pro který odběr pravidlo platí. Logicky, pro jeden typ darování můžete mít jen jedno pravidlo. Jsou tu také časy (2), kde každý znamená něco jiného. Čas přípravy je čas, kdy k Vám přijde sestřička, napojí Vás na přístroj a odejde je potřeba 1 zaměstnanec. Pak sedíte a přístroj něco dělá (separuje plasmu nebo odebírá krev), což je Čas odběru není potřeba zaměstnance. Pak je Čas odpojení, kdy znovu přijde sestřička a musí Vás odpojit od přístroje, vzít získaný balíček plasmy nebo krve a Vám dát například jablko je potřeba 1 zaměstnanec. Pak má přístroj automatické čištění, což je v systému zohledněno jako Čas čištění není potřeba zaměstnance. Potřeba zaměstnance souvisí s položkou Počet zaměstnanců (4), kde určujete počet lidí na objektu. Jestli na objektu jsou jen dvě sestřičky, naráz přijde 10 lidí a 15 minut trvá napojení pacienta, tak poslední dvojice bude čekat celou hodinu, a to nepočítáme lidi, kteří dorazí během té hodiny, a vznikl by problém nekonečné fronty, kde by docházelo k časovému zpoždění i několika hodin. Tomuto problému se můžete vyhnout, když počet zaměstnanců bude stejný, jako počet jednotek. Interval ve dnech (3) je položka, která určí, kolik dnů musí pacient počkat, aby mohl mít další odběr. Jinak musí požádat zaměstnance o zápis na kratším rozestupu. Také jen zaměstnanec smí překročit limit dnů dopředu Max dnů dopředu (5). Jestli se jedná o editaci pravidla, je zaškrtnuté Aplikovat na současné (6) a nový interval je vyšší než předchozí, tak se odstraní oba termíny a bude to oznámeno majiteli em. Také když se zvýší doba celkového odběru a vznikne kolize, systém se pokusí najít volnou sousední jednotku nebo u zavírací doby odstraní rezervaci. Tlačítkem OK (7) potvrdíte změnu v nastavení. Toto jsou ve stručnosti základní možnosti systému, kterým byste měli rozumět pro úspěšnou administraci. Bude to chtít navyknout na pravidla hlavně nedostupných dob. V případě nejasností se neváhejte zeptat hlavního administrátora (guru).

91 Příloha E Návod pro guru E.1 Správa systému Zadáte do internetového prohlížeče adresu klienta a přihlásíte se jako admin nebo jako uživatel s oprávněním 4. E.1.1 Objekty Obrázek E.1: Objekty V hlavní liště zvolíte Správa systému (obrázek E.1) a uvidíte první podsekci Objekty. Můžete přidat odběr (2) nebo objekt (3) díky příslušným tlačítkům. Popřípadě odběry (4) spravovat tlačítky na editaci (5), pro změnu názvu, nebo na odstranění (6). Seznam objektů a jejich ID v závorkách můžete zobrazit selektorem (7). Objekt můžete odstranit (8), a pro změnu jména či adresy se musíte na tom objektu přihlásit. Pak můžete odstranit staré rezervace podle staří a zmáčknout tlačítko Vyčistit (9). Poslední položkou v podsekci je 75

92 76 PŘÍLOHA E. NÁVOD PRO GURU údržba, Vyčistit sirotky (10) odstraní lidi, kteří nejsou na žádném objektu, vyčistí stará pravidla otevírací nebo nedostupné doby. E.1.2 Import Obrázek E.2: Import Druhou podsekcí ve správě systému je Import (obrázek E.2). Slouží k nahrání uživatelů ze starého rezervačního systému do nového. Aby to fungovalo, potřebujete nejdříve data ze starého systému uložit do souboru. K tomu slouží nástroj, jehož obrázek F.1 je v dalším návodu, phpmyadmin. V původní databázi najděte tabulku uzivatele a exportujte to do XML souboru uzivatele.xml. Systém umí pracovat i s JSON souborem, avšak phpmyadmin nikoliv, i když tvrdí, že ano. Například telefonní číslo exportuje jako integer místo string, a JSON soubor je neplatný. Až budete mít XML soubor, vyberte ho prosím tlačítkem Procházet (2), zadejte, k jakému objektu patří a jaké budou mít uživatelé oprávnění (3), pak dejte Import (4). Nepovedení uživatelé se Vám vypíšou v konzoli (5).

93 E.1. SPRÁVA SYSTÉMU 77 E.1.3 Logy Obrázek E.3: Logy Občas, jako správný správce, se musíte podívat, co systém dělá. K tomu slouží Logy (obrázek E.3), což je poslední podsekce správy. Máte dva druhy záznamů Master a Logy, které načtete příslušnými tlačítky (2 a 3), popřípadě vyčistíte (4 a 5). Načtou se nám do vyhrazených tabulek (6 a 7). Master jsou logy sítě uzlů a nepovedené SQL příkazy. Pokud někdo provede neplatný SQL příkaz nebo uzel vypadne, server zablokuje hromadný zápis do všech lokálních databází (rezervace se budou zapisovat normálně) tj. žádná změna nebo vytváření aktualit, uživatelů, událostí nebo otevíracích pravidel, dokud nevyčistíte Master logy. V Logy jsou běžné záznamy špatně zadaná nebo resetovaná hesla, také odstranění uživatelů, atd. V další části práce se dozvíte, jak vytvořit další objekt, připojit další server do systému nebo co všechno můžete upravit v souboru.ht-konfigurace.php.

94 78 PŘÍLOHA E. NÁVOD PRO GURU E.2 Nový objekt Systém umožňuje běh několika objektů na jednom serveru, stejně tak i běh jednoho nebo více objektů na více serverech. Jsou dva kroky, které musíte udělat, abyste přidal nový objekt. Krok první ve správě systému vytvoříte nový objekt a opíšete jeho ID v závorce, např. Nový objekt (5), tak ID je 5. Krok druhý zkopírujete jeden z JavaScript souborů ve složce objekty na MASTER serveru, třeba new.js do novyobjekt.js, a upravíte hned první řádek var objekt = X;, kde X je ID objektu, tedy na var objekt = 5;. Teď už stačí zkopírovat view část a upravit a odkaz v index.html, kde místo new.js zapíšete novyobjekt.js. Koncový klient nepotřebuje PHP server, stačí mu složka s obsahem view a zbytek už je na něm.

95 Příloha F Instalační příručka F.1 Požadavky Apache server PHP server v5.3 curl a OpenSSL rozšíření Řízeni.htaccess Funkce mail() MySQL v5.5 F.2 Instalace V této kapitole se podíváme krok za krokem na instalaci a údržbu systému. Pro úspěšnou instalaci potřebujete mít SQL server a PHP+Apache server. Byla zvolena zatím nejrozšířenější varianta SQL serveru MySQL, skript na vytvoření databázových tabulek je kompatibilní i s MariaDB serverem, který v současné době nabírá na popularitě. Pokud používáte PostgeSQL nebo jiný SQL server, nezoufejte a požádejte o export databázových tabulek výrobce systému. Doporučená verze MySQL je 5.5 a vyšší, u PHP 5.3 a vyšší. Systém Vám poběží i na starších verzích. PHP server musí umožňovat posílat y přes funkci mail(), také mít rozšíření curl. Také přístup k souborům je řízen.htaccess. Základní softwarové požadavky máte. Teď potřebujete jednu databázi nebo nejlépe dvě. K vytvoření tabulek slouží například nástroj phpmyadmin (obrázek F.1), kde vlevo vidíte seznam databází. Ale můžete použít i příkazový řádek SQL serveru. Systém má dvě základní skupiny tabulek CENTRÁLA a LOKÁLNÍ. Pokud nebudete systém dále rozšiřovat o servery, stačí Vám jedna databáze, i pokud budete, systému to nevadí, obě skupiny jsou skoro nezávislé. Každopádně potřebujete dvě nebo jednu databázi a přístupové údaje k nim, které budete potřebovat v dalším kroku. Teď potřebujete dvě veřejné internetové adresy. Stačí zase i jedna, kde MASTER server bude v podsložce hlavní složky. A dostáváte se do architektury, která je popsaná v jiné 79

96 80 PŘÍLOHA F. INSTALAČNÍ PŘÍRUČKA Obrázek F.1: phpmyadmin kapitole. Stručně řečeno, máte MASTER a možné SLAVE servery, které zpracovávají data v PHP a odpovídají v JSON[P] protokolu. Pak máte klienta napsaného v HTML, což je grafické zobrazení dat. V návodu jsou to dvě různé instalační složky server a view na adrese Obě složky mohou být jak v jedné složce, tak i MASTER server může být v podsložce klienta, ale oba mohou být třeba na různých serverech. Systému je to jedno. Důležité je, abyste zkopírovali obsah složky server na místo, kde bude MASTER server, adresa byla veřejně přístupná, a samozřejmě byl zapnutý interpret PHP server. Obrázek F.2: index.php - úvod

97 F.2. INSTALACE 81 Po zkopírování souborů a zadání internetové adresy MASTER serveru do prohlížeče, se Vám objeví následující formulář (obrázek F.2). V prvním políčku (1) bude současná adresa (POZOR CELÁ VČETNĚ s LOMÍTKEM NA KONCI). Do Centrální databáze (2) zadejte přihlašovací údaje a jméno tabulky, které máte z první části návodu, pro CENTRÁLU. Do Lokální databáze (3) údaje pro LOKÁL. Jak už je uvedené výš, údaje mohou být identické, ale zadat je musíte do obou. Stejně tak i dvakrát heslo pro uživatele admin. Pak klikněte na tlačítko Hotovo (5). Chvíli se budou vytvářet databázové tabulky a dva uživatele admin a master. Uživatel master je virtuální a jeho úkol je popsán v jiné kapitole. Obrázek F.3: index.php - výpis Po úspěšné instalaci se Vám objeví následující výpis (obrázek F.3). Musíte vytvořit dva soubory a jeden upravit.

98 82 PŘÍLOHA F. INSTALAČNÍ PŘÍRUČKA Obrázek F.4: Kate - soubory 3 soubory (obrázek F.4) jeden ve složce private, druhý ve složce objekty a třetí soubor musíte upravit. Vytvořte nový soubor v adresáři MASTER serveru ve složce private. Soubor pojmenujte.ht-konfigurace.php, vložte do něj daný obsah a uložte. Další soubor v adresáři MASTER ve složce objekty. Soubor pojmenujte new.js (nebo jak chcete, ale upravte podle toho další krok) vložte obsah a uložte. V instalační složce view najděte soubor index.html a vložte na chybějící místo odkaz na skript new.js (2), změňte kontaktní a uložte to. Přidejte do CRONu, nebo třeba na stránkách záznam pro spuštění souboru cron.php na MASTER serveru pro SMS a ové upozornění každou hodinu. A je to! Teď můžete nahrát kamkoliv obsah instalační složky view nebo otevřít lokálně soubor index.html ve Firefoxu a spravovat systém. F.3 SLAVE server Důvodů, proč klonovat server může být hodně. Potřebujete zálohu, rychlejší odezvu nebo snížit zátěž vratného, neboli PHP serveru. Také s dnešní popularitou útoků hackerů na Váš server, jako jsou DoS útoky, díky fragmentaci systému dokážete tímto útokům lépe čelit. Podmínkou přidaní dalšího serveru, aby to mělo smysl, jsou dvě databáze, když jste zakládali MASTER server, a nejlépe na dvou různých serverech, aby účinek byl co největší až o 100 procent rychlejší. Samozřejmě můžete rozšířit systém, i když máte jen jednu databázi. Nesmyslem je rozšiřovat systém, když vše bude na jednom serveru. Krok 1 zakázat zápis do LOKÁLU. Všechny lokální databáze mají stejný hlavní obsah, jak to zařizuje systém je popsáno v jiné kapitole, proto musíte dočasně vypnout zápis na MASTER serveru. V souboru.ht-konfigurace.php upravíme řádek: define( MASTERUDRZBA, 0 ); na define( MASTERUDRZBA, 1 );.