Systém pro správu obsahu (CMS)

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Systém pro správu obsahu (CMS) Denys Manichyev Vedoucí práce: Mannová Božena Ing., Ph.D. Studijní program: Elektrotechnika a informatika, strukturovaný Obor: Výpočetní technika 25. května 2012

iv

v Poděkováni Na tomto místě bych rád poděkoval svým rodičům a své manželce za její trpělivost. Velké díky také paní Boženě Mannové, která mé věnovala svůj čas.

vi

vii Prohlášení Prohlašuji, ze jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závazný 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ákonu (autorský zákon). V Praze dne 25. 5. 2012...

viii

Abstract This bachelor thesis deals with the design and implementation of content management system for websites. The system consists of two parts - public and administration. Administration part is working with data in the database. In the public part data is only read and displayed in a userprepared template. Creating template, as and structure of the public part with the functions of the system, is the task of the user. The system is implemented in PHP / MySQL / JavaScript and functioning properly. Abstrakt Bakalářská práce se zabývá návrhem a implementací redakčního systému pro správu obsahu webu. Systém skládá ze dvou častí administraci a veřejné. Administrační část pracuje s data v databáze. Ve veřejné častí jen natahuji data z databázi a zobrazuji jich v připraveném uživatelem šablonu. Vytvořeni šablony, jako i struktury veřejné častí, která je tvořena pomoci funkce systémů, je nechána na uživatelé. Systém je realizován v php/mysql/javascript a je funkční. ix

x

xi Obsah 1. Úvod................................................ 2. Popis CMS, specifikace...................................... 3. Analýza............................................... 3.1. Motivace projektu..................................... 3.2. Cíle výsledného produktu................................. 3.3. Porovnáni volné dostupných redakčních systému a vlastního řešeni......... 3.3.1. Přehlednost a konzistence.............................. 3.3.2. Přizpůsobeni konkrétnímu účelu.......................... 3.3.3. Modifikovatelnost.................................. 3.4. Funkce nového systémů.................................. 3.5. Požadavky na systém................................... 3.5.1. Stránky......................................... 3.5.2. Komentáře....................................... 3.5.3. Kategorii a menu................................... 3.5.3.1. Kategorii.................................... 3.5.3.2. Menu.................................... 3.5.4. Obrázky a soubory.................................. 3.5.5. Šablony........................................ 3.5.6. Moduly......................................... 3.5.7. Nastaveni....................................... 3.5.7.1. Skupiny nastavení.............................. 3.6. Role uživatelů v systémů................................. 3.7. Omezeni návrhu a implementace............................ 3.8. Volba technologie..................................... 4. Návrh a implementace...................................... 1 3 5 5 5 5 5 6 6 6 6 6 7 7 7 7 8 8 8 8 9 9 9 10 11

4.1. Doménový model..................................... 4.1.1. Úvod do implementace doménového modelu ve zvolené technologii...... 4.1.2. Návrh a implementace doménového modelu................... 4.2. Administrační rozhraní.................................. 4.2.1. Funkce administrace................................. 4.2.2. Bezpečnost...................................... 4.2.2.1. Autorizace................................... 4.2.2.2. SQL injection................................. 4.2.2.3. Cross-site Scripting (XSS)........................... 4.2.2.4. Systémové soubory.............................. 4.2.2.5. Ostatně.................................... 4.2.3. Implementace..................................... 4.2.4. Použitelnost...................................... 4.3. Veřejná část systému................................... 4.3.1. Návrh......................................... 4.3.2. Implementace..................................... 4.3.2.1. Kam se ukládají data............................. 4.3.2.2. URL adresy zadané uživatelem....................... 4.3.2.3. Šablony a nastaveni............................. 4.3.2.4. Moduly.................................... 5. Testováni.............................................. 5.1. Funkčnost.......................................... 5.2. Použitelnost........................................ 5.3. Bezpečnost........................................ 6. Závěr................................................ Literatura.............................................. A. Seznam použitých zkratek.................................. B. Instalační příručka....................................... B.1 Požadavky na systém................................. 11 11 11 16 16 19 19 19 19 20 20 20 20 20 20 21 21 21 22 22 23 23 23 23 25 27 29 31 31

B.2 Konfigurace...................................... B.3 Instalace........................................ C. Obsah přiloženého CD.................................... 31 31 32 xiii

xiv

Seznam obrázků 4.1 Doménový model......................................... 4.2 Hlavni stránka administrace................................... 12 17 xv

Seznam tabulek 4.1 Seznam a popis atributů tabulky history............................ 4.2 Seznam a popis atributů tabulky url_static........................... 4.3 Seznam a popis atributů tabulky menu_row.......................... C.1 Obsah přiloženého CD...................................... 12 13 14 32 xvi

Kapitola 1 Úvod V současné době vzhledem k silnému rozvoji internetu téměř každá organizace, společnost nebo obchod potřebuje své webové stránky pro komunikace s klienty a zaměstnance, reklamu svých služeb a zboží a další potřeby. Také existuje mnoho různých soukromých internetových stránek. Takové stránky by měly být snadno vytvořené a ovladatelné. Proto při tvorbě webů často používají redakční systémy nebo anglicky content management system (dále jen CMS). Většina webu v síti - to jsou malé weby do 100 stran, vytvořený vlastníkem webu. Ti, kteří chtějí vytvořit web sami na základě jedné ze stávajících systémů se potýkají s mnoha problémy. Jedna z hlavních problému - je to design. Autor se musí využit buď stávající šablony nebo vytvořit vlastni šablonu, což je většinou problém, protože to vyžaduje pokročilou znalost webových programovacích jazyku - PHP, MySQL, HTML, CSS, JavaScript. Druhý problém - v adresách stránek. Dost často v dnešních CMS na jednu stránku se stejným obsahem vede mnoho různých URL adres. To způsobuje ze vyhledávače najdou místo jedné stránky - desítky, stovky či dokonce tisíce stejných stránek, což vede ke dublování obsahu stránek a ke snížení pozice stránky ve výsledku vyhledávačů. Další problém - nadměrná složitost moderních systémů, což neumožňuje uživateli rychle pochopit CMS. V této souvislosti jsem se rozhodl vytvořit CMS, které by nejlépe tyto problémy řešil, skoro bez ztráty funkcionality. V této práci jsou následující kapitoly: Kapitola 2 Popis CMS, specifikace. Kapitola 3 Analýza projektu obsahuje zkrácenou analýzu projektu. Kapitola 4 Realizace se zabývá doménovým modelem, návrhem a implementací administrační části webu, nasazením aplikace do produkčního prostředí a bezpečností systému Kapitola 5 - Testování informuje o způsobu testování aplikace Kapitola 6 - Závěr zhodnocuje výsledek práce 1

2

Kapitola 2 Popis CMS, specifikace Tato práce obsahuje analýzu, návrh a implementace nového systémů pro správu obsahu webové aplikace. Konečný produkt bude určen pro uživatele, kteří znají technologii html, css a základy programovacího jazyka php. Tyto znalosti dovolí na základě tohoto CMS vytvořit nový web s vlastním designem a strukturou nebo převést na tuto CMS už existující web během dost krátké doby. Tato CMS je určena především pro malé a středně velké weby se statickým obsahem. Ale lze vytvořit i dynamické stránky, například pro dodáni na webové stránky nějakého servisu v závislosti na volané adresu. CMS skoro nemá omezeni na budoucí vzhled webových stránek a strukturu webu. Autor webu především bude muset vytvořit svoji html šablonu a strukturu budoucích webových stránek. Dále, dle potřeby, rozdělit šablonu na několik souborů a natáhnout je na CMS. Kazda stránka odpovídá jenom jedné adrese URL. Při změně URL adresy stara adresa bude uložená a při přechodu do něj uživatel bude přesměrován na aktuální adresu stránky. Všechny odkazy uvnitř CMS při změně URL stránky ihned budou mít novou aktuální adresu stránky. 3

4

Kapitola 3 Analýza Cílem projektu bylo vytvořit redakční systém pro správu obsahu webu. V této kapitole se nachází zkrácený výpis požadavků na systém, přehled technologií, důvod pro jejich volbu a srovnání nového navrhovaného systému s existujícími systémy. 3.1. Motivace projektu Při vývoji několika webových stránek, pokaždé jsem měl s problémy s vytvořením vlastního designu, protože moderní CMS máji dost složité šablony sestavené z několika desítek souborů a vytvoření takové šablony trvalo mnoha dní. Taky při optimalizaci některých webu pro vyhledávače, jsem se setkával s tím, že jedna stránka je k dispozici na několika URL adresách, což vedlo k dublováni a bylo obtížné pro optimalizaci webu. Tak jsem se rozhodl vytvořit svůj vlastní CMS bez těch problémů. 3.2. Cíle výsledného produktu Mnou navržená CMS bude mít další vlastnosti: Snadno vytvořit a modifikovat design. Jeden URL odpovídá jedné stránce a naopak. Snadné rozšiřování funkčnosti systému. Možnost snadno měnit všechna zobrazovací data na každé stránce. Nižší zatížení serveru a rychlejší reakce ve srovnání s moderními CMS. Rychlá a snadná správa obsahu webu. 3.3. Porovnáni volné dostupných redakčních systému a vlastního řešeni Pro vytvoření webu je možné využít celou řadu volně dostupných redakčních systémů. Například Drupal, WordPress, Joomla. Posuzoval jsem vhodnost jejich použití, funkcionalitu, použitelnost a přehlednost na základě vlastni zkušenosti s nimi. Tyto systémy máji své výhody, ale zároveň také nevýhody. Největší problémy moderních CMS jsem se popsal výše a proto jsem se rozhodl vytvořit vlastni CMS pro řešeni těchto problémů. Důvodů pro toto rozhodnuti bylo vice, rozeberu zde ty nejpodstatnější. 3.3.1. Přehlednost a konzistence Většina volně dostupných redakčních systém poskytuje uživateli velké množství funkcí, z nichž se běžně používá jen 10%. V mé CMS v základní funkcionalitě budou jen dostačující funkce, a všechny doplňky a moduly si uživatelé mohou snadno vytvořit sami. 5

3.3.2. Přizpůsobeni konkrétnímu účelu Dalším důvodem proti stávající CMS - je standardní řešení, šablony a struktury. Například umístění menu, některá slova v URL a struktury webu. Moje CMS téměř neomezuje uživatele v tomto směru. Vzhledem k tomu, že neexistují žádné standardní řešení, uživatel musí vymyslet a vytvořit strukturu, URL a šablonu. 3.3.3. Modifikovatelnost Výhodou vlastního řešeni je také modifikovatelnost. Ve vlastním systému každé přidaní nebo úprava je jednodušší, než přidávat nebo upravovat vlastnost v nějakém cizím systému, který je navíc velmi rozsáhlý. A nevím, jestli při této úpravě nenaruším jinou jeho část. 3.4. Funkce nového systémů Správa statických stránek Správa dynamických stránek Správa komentářů Správa skupin Správa menu webu Správa šablon Správa modulu Správa obrázku a souboru Správa nastaveni Vícejazyčná jazyková podpora Historie provedených změn Skryti části obsahu webu pro neautorizované uživatele 3.5. Požadavky na systém Požadavky na systém byly sepsány na základě zadání bakalářské práce. Při návrhu a implementaci tyto požadavky byly o něco rozšířeny. Požadavky redakčního systémů jsou vzhledem k rozsáhlosti projektu rozděleny do několika kategorií: Stránky, Komentáře, Kategorii a menu, Obrázky a soubory, Šablony, Moduly a Nastaveni. 3.5.1. Stránky Systém bude umožňovat správu stránek (vytvářeni, editaci, mazáni). 6

Kazda stránka bude mít možnost zavolat funkce header() s nějakými parametry, vypsat hlavičku z title a meta tágu a nějaký kontent. Kazda stránka bude mít nějaký unikátní URL adresu, která bude skládat z adresy hlavni kategorii a adresy stránky, například: www.domain.com/adresa_hlavni_kategorii/adresa_stranky 3.5.2. Komentáře Komentáře jsou přiřazeny k nějaké stránce a uživateli. Podle nastaveni, komentováni lze dovolit nebo zabránit na nějaké stránce, skupiny nebo celém webu. Komentář muže přidat libovolný uživatel ale musí vyplnit kód z obrázku - cacha. Po vkládaní komentář dostávají stav, ze je ne schválen. Správce webu muže prohlednout neschválené komentáře a schválit jich nebo odstranit. Správce webu může prohlednout všichni komentáře webu, editovat jich nebo odstranit. Komentáře můžou mít i podkomentáře, tj. odpověď na komentáře. Při prohlednuti komentáře v administrační části lze jich třídit podle stránky ke které oni jsou přiřazeny, rodiče komentáře, autora a stavu. Při vkládáni komentáře systém taky vkládá čas vkládáni, který dal už nejde změnit. 3.5.3. Kategorii a menu 3.5.3.1. Kategorii Kategorii - seznam stránek. Při vytvořeni kategorii, taky vytvoří nova stránka kategorie, jejíž URL adresa i je adresa kategorie. Kategorie může být u stránky hlavní nebo ne hlavní. Ne hlavní kategorie znamená, že stránka je pouze uvedena v kategorii a při odpovídajících nastavení se zobrazí v menu z této kategorie, ale na URL adresu stránky to nevplývá. Hlavní kategorie znamená, že odkaz na stránku, bude se skládat z adresy kategorii (hlavní stránky kategorie) a adresy stránky. Jenom stránky u kterých kategorie není hlavni mohou být přidány nebo odstraněny z kategorie. Hlavni kategorii stránky lze přiřadit pouze v sekce upravit stránku. 3.5.3.2. Menu Menu se vytváří v administrační části. Ve veřejné části uživatel může využit funkce pro zjištěni všech odkazu, v závislosti od aktuální stránky. Další formátovaní a vystup odkazu menu uživatel musí vytvořit sám. Menu - seznam řádku různých typů. Typ řádku může být: 1. Číslo stránky, v tomto případě vrátí aktuální URL stránky. 2. Přímá adresa URL, která se vrací. 3. Číslo kategorie, v tomto případě vrátí odkazy na stránky kategorie. 4. Číslo hlavní stránky kategorií, vrátí odkazy na hlavní stránku kategorie a stránky kategorie. 7

Pro 1, 2 a 4 odkaz může být textový a/nebo obrázek (vrátí se atributy src a alt). V každém případě odkaz může mít atribut title. Pro 3 a 4 lze zvolit výstup všech stránek kategorii nebo pouze ty u kterých tato kategorie hlavní /ne hlavní. Pro každý řádek, lze se vybrat omezení ze bude zobrazovat kdekoli nebo za určitých podmínek (hlavni stránka webu, nějaká kategorie, atd.). Pro každý řádek lze zadat počáteční hloubku. Výchozí hodnota je 1. Tato příručka je určena k vytvoření vizuálně podkategorie. Libovolný řádek může být publikovány a ne publikovány. Při vložení nového řádku v menu lze ho přidat na začátek, na konec, na určitou pozici s posunutím dalších řádku dolů nebo s přesunutím řádku z této pozice na konec. 3.5.4. Obrázky a soubory Obrázky a soubory které by musely byt k dispozici pro uživatele měly by být uloženy ve adresáři /content. Administrátor vše soubory nahrává na server sám přes FTP nebo jinou technologii. V administrační části uživatel může prohlížet soubory na serveru a URL těch souborů. Pro obrázky lze přidat atributy alt a longdesc, v tomto případě obrázky budou zaevidovaný v databázi a výpis obrázků s těmito atributy bude možná volat podle ID obrázků v databázi. 3.5.5. Šablony Šablona stránky se skládá ze hlavního souboru šablonu(osnovy), elementu šablonu (boxy), a připojovaných souboru pomoci tagu <link>. V různých šablonách může byt využita jedna osnova a různé prvky. Osnova šablony hlavni soubor šablony a adresář pro obrázky šablony. Obrazy šablony lze uložit v této složce nebo ve sdílené složky pro obrázky. Boxy v osnově volané pomoci nějakého jména, který u různých šablon mohou byt spojeny s různými boxy. Osnova šablony - to je část designu která jsou nezměněna po cely web nebo skupinu stránek. Element šablony (box) - soubor, který třeba vložit do šablony. Používají pro značně menší počet stránek než osnova, možná i pro jednu stránku. 3.5.6. Moduly Modul - je vložka elementu šablonu s předběžným zpracováním dat v PHP kódu. To znamená, že modul skládá ze dvou souboru php a phtml. V php souboru je logika a v phtml souboru zobrazuji vypracované údaje v HTML kódu pomoci php-vložek. 3.5.7. Nastaveni Nastavení systému - jeden z nejmocnějších způsobů, jak lze ovlivnit CMS. 8

V nastavení administrátor vybírá skupinu nastavení pro cely web. Hodnoty tyto nastaveni budou platit jako výchozí nastaveni před každém otevíráni stránky, tj. budou platit pro stránku, pokud na stránce nebo v hlavni kategorie stránky nebyli toto nastavení vyměněny. 3.5.7.1. Skupiny nastavení V nastavení lze vytvářet, upravovat nebo odstranit skupinu nastavení. V každé skupině nastavení lze zadat následující parametry: default_0_file soubor který se zobrazí pokud kód odpovědi URL je 0 default_301_file soubor který se zobrazí pokud kód odpovědi URL je 301 default_302_file soubor který se zobrazí pokud kód odpovědi URL je 302 default_303_file soubor který se zobrazí pokud kód odpovědi URL je 303 default_401_file soubor který se zobrazí pokud kód odpovědi URL je 401 default_403_file soubor který se zobrazí pokud kód odpovědi URL je 403 default_404_file soubor který se zobrazí pokud kód odpovědi URL je 404 default_id_template ID šablonu default_access právo na prohlednuti stránky default_comments právo na možnost komentováni default_print_server_header vystup při voláni funkce header() default_print_meta_language vystup meta tágu při uvedeni language default_print_meta_charset vystup meta tágu při uvedeni charset default_print_meta_robots vystup meta tágu při uvedeni robots 3.6. Role uživatelů v systémů Systém bude rozlisovat mezi dvěma rolemi uživatelů - návštěvnici, a administrátor. Návštěvnici (neautorizováni uživatele) mohou prohlížet veřejný obsah webu. Administrátoři mohou spravovat obsah webu. 3.7. Omezeni návrhu a implementace Existuje několik limitujících faktoru, které v tomto projektu mohou nastat. Nejkritičtějším je jednoznačně nedostatek casu na tvorbu systém v rámci bakalářské práci. Podle hrubých odhadu bude pracnost tohoto projektu cca 500-600 hodin. V rámci bakalářské práci proto budou realizovaný nejdůležitější části systém a cely systém bude dokončen následně. Dalším limitujícím faktorem může byt změna požadavků v pozdní fázi vývoje, když adaptace na změny bude velmi náročná. Tomu se pokusíme předcházet vhodné zvolenou metodikou vývoje s agilním přístupem. 9

3.8. Volba technologie Pro vytvoření redakčního systémů je možné použít více technologií a programovacích jazyku. Rozhodnutí o volbě vhodné technologie je stěžejní záležitost, která ovlivňuje kvalitu výsledného produktu a také rychlost jeho vývoje. Možností, které technologie použít na straně serveru, je cela rada. První, dnes nejběžnější a zřejmě nejznámější technologií, je programovací jazyk PHP. Tento jazyk podporuje skoro všechny servery. A přestože s PHP moje zkušenosti jsou nejlepší moje volba padla na touto technologií. Další poměrně rozšířenou technologií je Java, a vsak s tou nemam s vývojem mnoho zkušeností a také se při vývoji narazí na jista omezení. Java je vhodná pro velmi rozsáhle projekty ve spolupráci mnoha lidí, což tento redakční systém není. Dalšími možnostmi byly jazyky Ruby a ASP, avšak s těmito technologiemi jsem nemel žádné zkušenosti.ale v porovnáni s PHP ostatní jazyky podporuje značně menší počet serveru. Pro ukládaní dat lze vybrat několik různých databázi. Je to MySQL, Oracle, MS SQL, PostgreSQL, SQLite a další. Ale nejpopulárnější a nejčastěji podporována různými hostingamy je MySQL. A protože moje zkušenosti s ni jsou nejlepší moje volba je MySQL. Statické data jako šablony, obrázky, soubory budou ukládané primo na hostingu administrátorem webu pres FTP nebo jinou technologii podporovanou hostingem. Tato bakalářka tento problém neřeší. Pro dobrou použitelnost a grafické prvky v systémů budou využity volné dostupné obrázky. Při využití obrázku nebudou porušeny licence, pod kterými jsou vydávány. Protože k zobrazování webové aplikace dochází ve webovém prohlížeči na straně klienta, mela by být zvolena taková technologie, která nevyžaduje zvláštní požadavky na uživatele. Na klientskou stranu, tedy pro počítač s internetovým prohlížečem, jsem v podstatné nucen použít HTML spolu s kaskádovými styly CSS, který je dobře podporované ve všech webových prohlížečích. Z důvodu větší použitelnosti při používání webové aplikace byl použit i skriptovací jazyk JavaScript, který umožňuje vytvářet interaktivní prvky na webové stránce. Byl zvolen právě tento jazyk, protože je ve webových prohlížečích nejvíce podporován. Pro tuto technologii bude také využit Framework jquery, který obsahuje již hotové aplikace v JavaScriptu a který je velmi jednoduché integrovat do systémů. Ve Frameworku jquery, bude použita technologie AJAX dovoluje spojit JavaScript s PHP kódem. Bylo zvažováno použití jazyka HTML5, který umožňuje moderní vývoj interaktivních aplikací. Tento jazyk je ale zatím ve fází návrhu a jeho podpora ve webových prohlížečích značné pokulhává, proto byl zamítnut. Vyber vhodné metodiky pro vývoj rozsáhlejšího systémů je základním kamenem projektu. Tím spíše to platí u projekt spojených s webovými technologiemi. Spatně zvolena metodika může zapříčinit neúspěšný projekt velmi snadno a naopak vhodné zvolena metodika vývoje dokáže projektu pomoci ve všech směrech. 10

Kapitola 4 Návrh a implementace Tato kapitola se zabývá návrhem a implementaci redakčního systému. 4.1. Doménový model Doménový model je základním kamenem redakčního systému. Zbytek systému nabízí jen určitý pohled na tento model (v případě veřejné části webu), popřípadě tento model modifikuje (v případě administrační části webu). Účelem vytvoření doménového modelu je převod objektu z reálného života na objekty vhodné pro počítačové zpracovaní. Doménový model se pak převede na konkrétní implementaci v konkrétní technologii. Doménový modelu bylo také věnováno mnoho casu kvůli jeho důležitosti. 4.1.1. Úvod do implementace doménového modelu ve zvolené technologii Prakticky všechny webové aplikace pro ukládání a práci s daty používají relační databáze. Jak už bylo výše zmíněno, základní databáze bude MySQL. Práce s databáze lze vest přes standardní PHP funkce nebo přes nějakou třídu. Jak jsem i udělal. Proto jsem napsal interface DBLayer(abstraktní třída) tohle umožní při potřebí použit jinou databázi se stejným SQL syntaxím a napsáním potřebné třídy která dědí DBLayer. Taky výhodou abstraktní třídy je něco zkrácení kódu a vetší jeho citelnost, protože několik funkce jsou sloučeny do jedné. Pro MySQL DB jsem napsal class MySQLDBLayer který dědí implements DBLayer, v něm jsem použil mysqli PHP funkce. Databáze MySQL nabízí velké množství datových typu. Pro potřeby redakčního systému používám jen číslové(smallint, TINYINT a INT) a textové(tinytext, TEXT, MEDIUMTEXT, LONGTEXT) typy různé velikosti. Pro logické hodnoty využit SMALLINT typ. Některé číslové typy definované bez znamínka UNSIGNED, a některé mají předdefinovanou hodnotu. Všichni tabulky používají stejný databázový engine MyISAM, protože je velmi rychlý a málo náročný. Neuvádím primo cizí klíče (FOREIGN KEY), protože tento engine fakticky jich nepodporuje. Další vlastnictví tabulek je: DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci. Používám kódování UTF-8 u tabulek protože všechna data a redakci systém pojiva taky kódování UTF-8 4.1.2. Návrh a implementace doménového modelu Pro lepší pochopení doménového modelu slouží obrázek 4.1, ve kterém jsou zakresleny jednotlivé objekty modelu a vazby mezi těmito objekty. 11

Obrázek 4.1: Doménový model V následující části popsány tabulky doménového modelu: history V tabulce history jsou zapsané všechny editace udělané v objektech CMS, ID autora a editora, datum vytvořeni a poslední editace. Popis atribut modelu history je uveden v tabulce 4.1 Tabulka 4.1: Seznam a popis atributů tabulky history Atribut Datový typ Popis id INT UNSIGNED NOT NULL AUTO_INCREMENT Číslo které je zapsáno v editovaném objektu. id_author INT UNSIGNED NOT NULL Id autora id_editor INT UNSIGNED DEFAULT 0 Id editora time_create INT UNSIGNED NOT NULL Čas vytvořeni, ve formátu timestamp time_update INT UNSIGNED DEFAULT 0 Čas poslední editace, ve formátu timestamp history_log LONGTEXT DEFAULT NULL Všechny udělané změny 12

settings_cms V tabulce settings_cms jsou zapsané nastaveni cms a má jenom jeden řádek. V něm je proměna id_settings ve které je uvedena aktuální skupina nastaveni a proměna cms_language pro jazykovou verzi administrační častí CMS. settings Toto lze chápat jako settings group. Je to skupiny nastaveni. Takovou skupinu lze vytvořit pro konkrétní stránky, skupiny stránek nebo cely web. Kazda skupina nastaveni má nějaké jméno a muže nastavit jaké budou otevírat soubory pro odpověď stránky odlišnou od 200, čísla šablonu a modulu, přístupová práva, právo na komentováni a některé meta tágy. Kazda hodnota muže byt nastavena na NULL, tehdy zástava plátna předchozí hodnota skupiny nastaveni. url_static Tabulka se statickými URL. Podrobnější popis jak se hledají URL v této tabulce je uvedeno v této kapitole v 4.3.1. Popis atribut je uveden v tabulce 4.2 Tabulka 4.2: Seznam a popis atributů tabulky url_static Atribut Datový typ Popis id INT UNSIGNED NOT NULL AUTO_INCREMENT id_ page INT UNSIGNED NOT NULL Id v tabulce page. Číslo stránky ke které tento URL patří id_ page_parent INT UNSIGNED DEFAULT 0 Id v tabulce page. Když ne 0, má číslo hlavni stránky skupiny do které stránka z tímto URL patří. http_code SMALLINT DEFAULT 200 HTTP odpověď serveru url TINYTEXT NOT NULL Jedno slovo bez znaku / a \ redirect TINYINT DEFAULT 0 Hodnota 0 odpovídá aktuálnímu url stránky, jinak třeba hledat v url_static jiný řádek se stejným URL a nulou zde. url_regular Je to dynamické URL které není známé předem. Má stejně atributy jako url_static, jen v atributu url je regulární vyraz. Tabulka je zavedena zvlášť pro jednoduší práce, pochopeni a možnost dat přednost statickým URL pages Data stránky. Má atributy id šablonu, modulu, nastaveni, právo přístupu a komentováni, čas aktualizace a deaktivace stránky, počet kolik byla stránka otevřena, text a title odkazu na tuto 13

stránku. Atribut main_page_for_category_id ukazuje ze to není hlavni stránka kategorii když je 0, jinak má id kategorii pro kterou je to hlavni stránka. Další atributy hodnoty které vyvadí CMS při otevíraní stránky. Zaprvé je to server_header řádky posílané pomoci PHP funkce header(). Dal title stránky, meta tágy (popis stránky, klíčová slova, jazyk, kódovaní a Index, Follow pro roboty vyhledávače), hodnota tágu h1 a cely text stránky v HTML kódu. categories Data skupiny. Má atributy má atributy jméno a id nastaveni(id_settings). category_pages Spojuje skupiny stránek(categories) a stránky. comments Je to komentáře. Obsahuje id komentáře, id stránky do které patří, id autora, status, čas vkládaní, titulek a text komentáře. comment_author Autor komentáře. Tabulka obsahuje jméno, email a website autora. menu Je to menu webu. Obsahuje jen jméno a nastaveni celého menu. V nastaveni mužů dovolit nebo zabránit publikace celého menu. Položky menu, kvůli složitosti a setřeni paměti jsou zapsané v tabulce menu_row. menu_row Radky menu. Jeden řádek muže odpovídat libovolnému poctu reálných odkazu v menu. Podrobnější popis v je uveden v této kapitole v 4.3.1. Popis atribut je uveden v tabulce 4.3 Tabulka 4.3: Seznam a popis atributů tabulky menu_row Atribut Datový typ Popis id INT UNSIGNED NOT NULL AUTO_INCREMENT id_history INT UNSIGNED NOT NULL ID history id_menu INT UNSIGNED NOT NULL Do jakého id menu tento řádek patří. position INT UNSIGNED NOT NULL Pozice v menu publish TINYINT NOT NULL DEFAULT 1 0 ne publikovat, jinak publikovat 14

type TINYINT NOT NULL Typ řádku 1 až 4. 1 odkaz na stánku po id 2 odkaz na stánku po URL 3 odkazy na stránky kategorii, po id skupiny 4 odkazy na stránky kategorii, po id hlavni stránky skupiny where_print TINYINT NOT NULL DEFAULT 0 Záležitost na vystup od ID stránky ze které menu voláno. depth TINYINT UNSIGNED DEFAULT 1 Hloubka, logická. follow TINYINT DEFAULT 1 Atribut rel pro roboty vyhledávače. class TINYTEXT DEFAULT NULL Atribut class odkazu. stype TINYTEXT DEFAULT NULL Atribut class odkazu. id_element INT UNSIGNED DEFAULT 0 Musí byt vyplněno když type je 1, 3 nebo 4. a_href TINYTEXT DEFAULT NULL Musí byt vyplněno když type je 2 a_title TINYTEXT DEFAULT NULL Atribut title odkazu. a_anchor TINYINT DEFAULT NULL Text odkazu img_src TINYINT DEFAULT NULL URL obrázku, pro odkaz-obrázek img_alt TINYINT DEFAULT NULL Atribut alt obrázku, pro odkaz-obrázek depth_max TINYINT UNSIGNED DEFAULT 1 Maximální hloubka, pro type 3 a 4 select_print TINYINT DEFAULT NULL Záležitost na vystup od hloubky, pro type 3 a 4 select_main TINYINT DEFAULT NULL Vyvádět odkazy na stránky u kterých tato skupina je hlavni/ne hlavni/nezaleží, pro type 3 a 4 modules Informace o modulech. Tabulka má atributy jméno, adresu PHP souboru a HTML souboru. template Je to šablony. Má atributy: id_base id osnovy šablonu v template_base, id_boxes pole uložené pomoci funkce serialize(), obsahuje id boxu z template_box links - pole uložené pomoci funkce serialize(), obsahuje soubory které budou připojené pomoci tágu link 15

template_base Osnova šablonu, podrobnější popis byl v kapitole 3, v 3.5.5. Obsahuje adresář kde uložené soubory šablonu, adresář pro obrázky a jméno souboru. template_box Je to část šablonu. Atributy: jméno a adresář souboru, typ adresy plna/relativní od adresářů osnovy šablonu. users Obsahuje data uživatelů. Atributy id v usergroup, login, heslo v zakódované formě, jméno, email a další data uživatele. usergroup Přístupová práva pro uživatelů. Umožňuje zadat přístup k různým funkcím administrační častí CMS images Informace pro obrázky. Obsahuje id, adresu obrázku, atributy alt a longdesc tágu img. 4.2. Administrační rozhraní Administrační rozhraní (dále jen administrace) je to část webu, která slouží pro vytváření obsahu viditelného ve veřejné častí. S touto částí přicházejí do styku administrátoři. Cela administrace leží v kořenovém souboru v adresáře administrátor. Dále jsou popsány funkce systému roztříděné do několika kategorií, které usnadní uživatelům administrace, orientaci a práci se systémem. 4.2.1. Funkce administrace Po přihlášeni do administrace administrátorů otevírá hlavni stránka administrace ve kterém je odkazy na všechny funkce CMS. Protože tento projekt je velmi rozsáhlý a z důvodu nedostatku casu na design administrační častí bylo věnováno minimum casu. Ale z důvodu lepší orientace a použitelnosti funkci administrační častí byli logicky rozdělené do skupin. Na obrázku 4.2 lze vidět hlavni stránku administrace. Skupiny funkcí jsou uvedeny dále. Stránky webu Tady lze vytvořit nove staticky stránky a editovat jich. Odkazy na editace stránek jsou na stránce Stránky webu. Protože při vytvořeni nove stránky a ji editace CMS pracuji se stejné hodnotami byl využit stejný formulář pro vytvořeni a editace stránky. Tento způsob dovoluje, při potřeby, rychle a jednoduché dodat nebo editovat poli ve formuláři. Na stránce zle zadat vše zobrazovací hodnoty jako title, meta tágy, tag h1 a kontent stránky; text odkazu na stránku a atribut title tohoto odkazu; zadat šablon a některé nastaveni nebo nechat předchozí (default) nastaveni. 16

Dynamické stránky mají rozdíl od statických v tom ze jejich URL adresa je zadána dynamickým výrazem a obsah stránky může záviset na tento URL. Komentáře Obrázek 4.2: Hlavni stránku administrace Komentáře může přidat libovolný uživatel na stránce kde je povolené komentáře a jsou formulář na jejich přidáni. Uživatel nemusí byt zaregistrován. Ve formuláři uživatel musí vyplnit své jméno, email, text komentáře a capcha kód. Taky může vyplnit svůj web sítě a tématu komentáře. Všichni autoři komentárů jsou evidovány v databázi pomoci pole email. Po přidáni komentář dostava stav ne schváleno. Administrátor může schválit komentář nebo odstranit ho. V administrace jsou dvě stránky pro práce s komentáře Autoři komentářů a Všechny komentáře. Na stránce Všechny komentáře administrátor může prohlednout všichni komentáře, filtrovat jich pomoci hodnot id_page,id_parent, id_comment_author a stavu komentárů. Z hlavni stránky administrace na tuto stránku vede 2 odkazy, 1. bez filtru a 2. s filtrem pro zobrazováni neschválených komentárů. Je to uděláno pro vetší použitelnost. Na stránce Autoři komentářů administrátor může prohlednout všech autoru komentárů, popřípadě změnit jejich údaje (jméno, email a web) a prohlednout vše komentáře libovolného autora. 17

Kategorie - Menu stránek Kategorie představuje nějakou skupinu stránek. Na stránce Kategorie lze prohlednout existující kategorie, přejit na vytvoření nove kategorie nebo editovat existující kategorii. Při přidáni stránky do kategorie, tato stránka bude jen evidovaná do v té kategorie ale hlavni kategorie stránky, jako i URL adresa stránky, zůstanou nezměněny. Změnit hlavni kategorii zle při editace stránky. Na stránce Menu stránek lze jen prohlednout existující menu v CMS a počet řádku v menu, podle typu. Dal můžu změnit někteří nastaveni a přejit na vytvoření nového menu nebo editovat existující. Obrázky - Soubory Na tento stránkách lze prohlednout vše URL adresy obrázku a souboru které lezou v adresáři /content. Vše soubory ležící v tomto adresáři jsou dostupný primo z URL adresy. Vše práce se soubory administrátor vede pomoci FTP nebo jiné technologie. V současní době redakční systém nemá žádné funkce pro nataženi souboru na server nebo z něho. Na stránce Obrázky zobrazuji jenom obrázky které lezou v adresáři. Do všech obrázku lze přidat, pomoci formulářů, atributy alt a longdesc pro výpis jich v tágu img. V tomto případe obrázek bude zaregistrován v databáze a pro výpis tohoto obrázků bude třeba jeho volat pomoci id toho obrázků, ale měnit adresu nebo název souboru na serveru ze zakázáno, v tom případe budou vrácené prázdné hodnoty. Šablony V této skupině je možné přidat osnovy šablonu, prvky šablonu boxy a sestavit z toho šablon který už bude využit na stránce ve veřejné častí. Na stránce Osnovy šablonu při vytvoření šablonu třeba zadat adresář šablonu a v něm ležící soubor a adresář pro obrázky. Tyto údaje bude ověřeno ze existuji. Taky lze změnit údaje už existujících osnov šablonu, které budou taky ověřené. Na stránce Prvky šablonu - boxy při vytvoření boxu třeba zadat soubor šablonu a lze zadat adresář ve kterém ten soubor leží. V rámci bakalářské práce je realizováno jenom relativní adresa, tj. ten soubor bude hledán v adresáři šablonu ze kterého je volán. Podporováni absolutní adresy bude realizováno později. Po výtvorní boxu lze jeho editovat nebo smazat. Ověžení na existováni souboru boxu se neprovádějí. Na stránce Osnovy šablonu jsou vypsané šablony s adresářem šablonu, hlavním souborem, adresářem pro obrázky, počtem využitých linku a boxu. Dal lze přejit na vytvoření nove šablony nebo editovat existující, tento stránky využívají stejný formulář, protože pracuji se stejnými hodnotami a usnadni práce s formulářem. Osnovu šablonu se připojuji pomoci její ID, pro linky třeba zadat vše hodnoty atribut. Pro připojeni boxu třeba zadat jméno jak bude volán z šablonu a id odpovídajícího boxu. 18

Moduly Moduly jsou podobné jako boxy v šablonu. Jenom ze skládají ze dvou souboru(php a html) a mají název. Pro vytvořeni modulu třeba tyto hodnoty zadat ve formuláři a dál lze jich editovat nebo odstranit modul. Při vytvoření modulu nebo jeho editace se povadej kontrola na existováni zadaných souboru. Nastavení Na stránce Nastavení systému můžu prohlednout vše skupiny nastaveni CMS a jejich některé hodnoty, vytvořit novou skupinu nebo editovat existující. Taky lze nastavit aktuální skupinu nastaveni pro cely redakční systém, tyto nastaveni bude mít nejmenší prioritu před ostatní ale pokud nebudou změněny při generaci stránky, budou platit pro každou stránky webu. Při vytvoření a editace nastaveni je využit jeden formulář, jako i stránek, kategorii, atd. Ve skupině nastaveni můžu zadat soubory který budou otevřeny pro odpověď URL adresy s číslem ne 200, id šablonu, modulu, právo na přístup a komentováni, vystup při volaní phpfunkce header(), meta tágy language, charset a robots. Všechny hodnoty mohou byt nastaveni jako default. 4.2.2. Bezpečnost 4.2.2.1. Autorizace Pro přístup od administrace administrátor webu musí zadat svůj login a heslo. kvůli omezeni casu a protože tato bakalářská práce nezahrnuje správu uživatelů v teto práce tento problém neřeší. Ale správa uživatelů je podporována doménovým modelem a bude napsána později. Po skončeni práce administrátor se musí odhlásit, kliknutím log out Při pokusu neautorizovaného uživatele otevřít nějakou stránku administrace, bude uvedeno upozornění a odkaz na stránku autorizace. 4.2.2.2. SQL injection SQL injection je útok, při kterém se útočník snaží spustit vlastní kód na databáze. Při úspěchu by útočník mohl z databáze získat důvěrná data nebo modifikovat data v databázi. Při útoku se využívá neošetřených vstupů ve webové aplikaci, například GET a POST data, která dal, jsou používána při tvorbě dotazů. Ochranou před tímto útokem je ošetření dat (escapování speciálních znaků), které se mohou tyto znaky mít. Interface DBLayer podporuje funkce escapování a při každém dotazu při tvorbě redakčního systému tato ochrana byla využita. 4.2.2.3. Cross-site Scripting (XSS) Útok cross-sitescripting využívá neošetřených vstupů a výstupů webové aplikace. Útočník se snaží ve webové stránky vložit vlastní HTML nebo JavaScript kód. Při úspěšném útoku na webovou stránku může útočník pozměnit vzhled webové stránky nebo přesměrovat uživatele na jinou stránku. Ochrana proti tomuto útoku převod všech speciálních znaků (u HTML například znaky < a >) na HTML entity. 19

4.2.2.4. Systémové soubory Uživatel nemá přístup k systémovým souborům CMS. Tento omezeni existuje protože uživatel bych mohl dostat do přístupovým datum k databázi, které uložené v jednom souboru a taky administrátor má vetší vyber URL adres pro stránky a skupiny. Tato nastaveni jsou realizované pomoci souboru.htaccess který server používá při otevíráni stránky. 4.2.2.5. Ostatně Při práce s administrace pokaždé před editace nějakých dat je ověřeni ze administrátor je autorizován ve systémů. 4.2.3. Implementace Implementace probíhala s využitím programovacího jazyka PHP, JavaScript s frameworkem jquery a technologie AJAX, databáze MySQL, technologie HTML spolu s kaskádovými styly CSS. Při implementace administrace byl využit architektonicky vzor MVC. Skoro všechna práce v administrace jde přes soubor administrator/index.php. V něm nejprve je ověřeni ze uživatel je autorizováni a dal jde řízeni dle zadaného URL jakou stránku a funkce vyraduje od administrace uživatel. Po zjištěni přepojuje PHP kód ze souboru administrator/engine, když logika skončí jde připojeni nejprve osnovy šablona soubor administrator/templates/index_template_main.phtml a dal potřebný soubor z adresáře administrator/ templates. Kromě souboru administrator/index.php v administrace taky používá soubory log_in.php pro autorizace uživatele a log_out.php pro odhlášeni(log out) uživatele. 4.2.4. Použitelnost Použitelnost administrace webových stránek je v velmi důležitá vlastnost, přestože je základem pro příjemnou práci se systém, z čeho vyplývá i kvalitní webová prezentaci. Použitelnosti administrační častí bylo věnováno hodné casu, protože si myslím, ze je pro uspěny produkt jednou z nejdůležitějších vlastnost. 4.3. Veřejná část systému Kapitola se věnuje samotné webové prezentaci, se kterou přicházej do styku nepřihlášení uživatele. Tato část je nezávislá na administrace a muže pracovat samostatné bez ni. 4.3.1. Návrh Jelikož sám tvůrce webu poskytuje jen určitý pohled na data, nebylo nutné zpracovávat návrh systémů kromě logiky. To znamená, ze jenom tvůrce webu musí vytvořit šablonu a vymyslit strukturu webu nebo využit existující šablonu. Veřejná část navazuje na doménový model, který byl rozebrán v kapitole 4.1. Veřejná část je realizovaná taky architektonickým vzorem MVC. Ze začátku jde analýza URL - jakou stránku vyraduje uživatel, dal podle ID stránky natahuji všechny hodnoty pro výpis a nakonec uživatelů zobrazuje šablon s natažené hodnotami. 20

4.3.2. Implementace Implementace probíhala s využitím programovacího jazyka PHP a databáze MySQL. Všechna práce jde přes soubor index.php který leží v kořenovém adresáři. Nejprve připojuje nastaveni CMS a funkce pro práce s databáze. Dal připojuje soubor /engine/go.php který představuje controller z MVC modelu. Nejprve jde nastaveni výchozích nastavení na vystup dle nastaveni CMS. Dale jde analýza URL, kde zjistím ID hledané stránky. A dal jsou několik možnosti: Stránka nalezena. Proměně na vystup budou nahrané do paměti. Stránka nenalezena. Odpověď serveru 404 Not Found. Stránka nalezena jinde. Odpověď serveru dle nastaveni URL: 301 Moved Permanently nebo 302 Found. Po provedeni logiky v paměti jsou adresa šablonu a všechna potřebné pro něho data. Dal jde připojeni šablonu, ve kterém zobrazuji předem nahrané hodnoty. V šabloně taky mohou byt moduly. 4.3.2.1. Kam se ukládají data Po připojeni souboru /engine/go.php, v něm vytvoří pole $data ve kterém budou uložené všechny data na vystup; vnitřní data, jako id stránky nebo URL stránky; adresa šablonu a další data. Po inicializace od $data ukládá výchozí hodnoty dle nastaveni CMS. 4.3.2.2. URL adresy zadané uživatelem URL adresy určují, jakou stránku systém musí zpracovat a zobrazit uživateli. Tyto adresy jsou zpracovaný pomocí regulárních výrazu, kde jméno serveru (tedy doménové jméno nebo adresa) již není předáváno od webového serveru (aplikace). Všechny regulární výrazy uležené v souboru /.htaccess jsou popsané dále: RewriteCond %{REQUEST_FILENAME}!-d RewriteCond %{REQUEST_URI} ^(.+)/$ RewriteRule ^(.+)/$ /$1 [R=301,L] #SERVICE PAGES RewriteRule ^comment_new\.php(.*)$ engine/comment_new\.php$1 [L,QSA] RewriteRule ^(engine/comment_new\.php)$ $1 [L,QSA] #GROUP PAGES RewriteRule ^administrator/(.*)$ administrator/$1 [L,QSA] RewriteRule ^content/(.*)$ content/$1 [L,QSA] RewriteRule ^install/(.*)$ install/$1 [L,QSA] RewriteRule ^template/(.*)$ template/$1 [L,QSA] RewriteRule ^js/(.*)$ js/$1 [L,QSA] RewriteRule ^css/(.*)$ css/$1 [L,QSA] RewriteRule ^images/(.*)$ content/images/$1 [L,QSA] RewriteRule ^(.*)$ index.php?url=$1 [L,QSA] 21

První 3 řádku zabraňuji znak / na konci URL a přesměruji na stejný URL bez / na konci. Dal skupina SERVICE PAGES odpovídá za systémové funkce komentáře a další. Dal skupina GROUP PAGES odpovídá za URL adresy zadané uživatelem. Prvních 6 řádku říká neměnit adresu zadanou uživatelem a hledat soubor na disku primo zadaný v URL, další řádek pro lepší zobrazováni adresu obrázku a poslední řádek říká převést adresu na zpracováni do souboru index.php s GET hodnotou tyto adresy. Taková implementace dovoluje vytvořit skoro libovolné adresy, jen s malým omezením. Všechny adresy skládají ze slov, které mohou skládat z malých a velkých znaku anglické abecedy, čísla 0123456789, znaky - a _. Slova mezi sebou rozdělené znakem /. Při analýze URL nejprve URL rozdělen na části znakem /. Všechny kromě posledního slova jsou chápané jako adresy hlavních stran skupin. A tyto adresy hledají v tabulce url_static. Poslední adresu nejprve hledají taky v url_static, ale když nenajde taky hledá pomoci regulárních výrazu v tabulce url_regular. Po naleznuti adresy ukládá ID stránky do proměny $data['page']['id'] 4.3.2.3. Šablony a nastaveni šablon je to nějaký soubor ve kterém leží html/css/javascript kód a jsou php-vložky. Proto většinou šablony mají rozšířeni.phtml. CMS implementován tak ze nejprve čte hlavni soubor šablonu, který se nazývá osnova šablonu, v něm by mel byt neměnitelný design pro cely web nebo pro nějakou množinu stránek. V osnově šablony připojuje vnitřní části šablonu, který se nazývá boxy, v nich by mela byt ta část designů, která je využita na konkrétně stance nebo nějaké skupiny stránek. Pro lepší pochopeni uvedu příklad: nějaký web, má třeba několik desítek stránek a na všech je stejná hlavička nahoře a menu zleva. Uprostřed a zprava je další blok ve kterém je různý obsah na různých stránkách, většinou je to text v rámečku, ale na hlavni a na stránce kontakty rámeček jsou jiný, a ve stránce dotazy je to forma bez rámečku pro odesíláni dotazu. Vzhledem k takovému příkladu v osnově šablonu bude hlavička, levé menu a voláni centrální měnitelné části. Pro stránky s textem bude využit jeden šablon, pro hlavni stránku a pro kontakty bude využit druhy šablon a pro dotazy třetí. Na konci výstupu klient dostava odpověď' na svůj požadavek ve formátu HTML. 4.3.2.4. Moduly Pro lepši funkcionalitu a nižší složitost jsem se dodal do CMS prvek moduly. Je to podobně s boxamy v šablonách jen ze skládá ze dvou souboru PHP a HTML. Nejprve pracuje PHP kód a v HTML souboru vyvodí pomoci php-vložek. Tohle dává autorovi webu vetší funkcionalitu při nízké složitosti. Nevýhodou toho je menší stabilita při vytvořeni webu různé uživatele a omezeni využití PHP funkce ve modulech, protože před jejich spouštěni nejspíš už byl vystup už nelze využit funkce header, menit cocees, session atd. 22

Kapitola 5 Testováni Při testovaní systému se zaměřilo především na kontrolu funkčnosti a použitelnosti. 5.1. Funkčnost Pro zajištění funkčnosti aplikace se používají převážně jednotkové testy a uživatelské testovaní. Redakční systém neobsahuje velké množství logiky ale obsahuje velké množství pohledů na data v databázi, které jsou realizovány pomocí databázových modelů. V administrace, lze říct, ze uživatel mění data v databázi. Ve veřejné části ty data načítají z databázi a zobrazuji přímo šabloně, nebo boxu, nebo modulu. Jelikož jsou tyto funkce již v php otestované, bylo by je zbytečné znovu testovat. Vzhledem k typu projektu jsem rozhodnul, že unit testy z důvodu malé užitnosti v této fázi nebudou implementovány. Vytvářit unit testů by bylo příliš časově náročné. Jelikož nebyly použity unit testy, třeba funkční testování zajistit jinou metodou. Funkční testování probíhalo formou uživatelské testování za dobu samotné implementaci a po ukončení implementace byl do tyto CMS převeden jeden web. Jelikož při každém uložení změněného kódu jsem obnovoval stránku ve prohlížeči a bylo možné změnu ihned vidět. Tímto způsobem bylo možné interaktivně testovat funkčnost jednotlivých fragmentů kódu. Prakticky všechny chyby, které se zůstaly po vývoji, se objevovaly v šablonách, které určují, která data a na jakých místech, se budou zobrazovat. Testování této funkčnosti probíhalo vizuálně pomocí uživatelských testů přímo ve webovém prohlížeči, popřípadě pomocí pluginy webového prohlížeče Firefox, jako Web Developer nebo Html Validator. 5.2. Použitelnost Jelikož je vývojář s aplikací velmi podrobně seznámen, může těžko říct fatální chyby použitelnosti aplikace. Proto je nutné u každé webové aplikace provádět test použitelnosti. Ten má za úkol odhalit chyby v použitelnosti aplikace. Tento test musí provádět osoba, která aplikaci nezná. Přestože redakční systém pro správu obsahu webu by mel byt dost pochopitelný pro uživatelé kteří s programováním nemají nic společného, požádal jsem o pomoct s testováním použitelnosti svoji manželku a matku. Kazdu z nich jsem seznámil s aplikace a na konci testu mě sdělily svůj názor na aplikaci, případně i navrhly způsob, jak by aplikace měla vypadat. Za základě toho testů byly odhaleny další drobnější nedostatky v použitelnosti, které byly opraveny. 5.3. Bezpečnost Aplikace byla testována i z hlediska bezpečnosti. Na někteří částí aplikace byl proveden útok SQLinjection pomoci GET a POST proměnách, ale tento útok neměl žádnou šanci, protože všude při práci s databáze byla využita ochrana proti SQLinjection. Dále byl proveden útok XSS. Jak již bylo v kapitole Bezpečnost zmíněno, v šablonách se všechny speciální znaky převádí na HTML entity a tím je aplikace uchráněna před útokem XSS. Ale v 23

některých částech šablonu bylo ale nutné tuto konverzi vypnout, protože bylo třeba speciální znaky zobrazovat. Jedna se o hlavni kontent stránky, který se vkládá v HTML kódu. Testem bylo odhaleno, že tato část aplikace nejsou chráněna proti útoku XSS. Ale tento útok by mohli provést jen správci systému, kteří mají přístup do administrační části webu. Výsledek tohoto testu byl hodnocen jako positivní, protože se nepředpokládá, že by administrátor chtěl poškodit web. Navíc pokud by administrátor chtěl poškodit web, mohl by to provést přímo v administraci, aniž by musel použít XSS. Test bezpečnosti neodhalil žádné chyby aplikace 24

Kapitola 6 Závěr Zadání bakalářské práce bylo splněno v plném rozsahu. Vytvořený redakční systém splňuje požadavky zadavatele vedoucí projektu Božene Mannovy a je téměř připraven pro vytvoření nových webu nebo do nasazení na existující web. Systém je momentálně ve fázi testování. Po dokončení této práce bude převeden na tento systém jeden existující website který momentálně běží na adrese www.gotocz.ru Při vývoji byl kladen velký důraz na použitelnost a bezpečnost aplikace. Podařilo se vytvořit aplikaci, kterou lze v budoucnu snadno upravovat, případně rozšířit novými funkcemi. Velkou výhodou redakčního systému je protože vaziva kódovaní UTF-8 který obsahuje skoro všechny mezinárodní znaky, proto na zaklade tento CMS zle vytvořit web sítě skoro v jakémkoliv jazyce. Další výhoda je to ze v současně době administrační část jsou realizovaná ve dvou jazyku češtině i ruštině. A aby přivést její do dalšího jazyku třeba jen udělat překlad jednoho souboru z češtiny nebo ruštiny do jazyka který potřebujeme a změnit jazykové nastaveni. Žádný zdrojové kódy měnit nebo kopírovat není třeba. Pokračování vývoje Během testováni projektu mě napadlo několik vylepšení ve funkcionalitě, které by bylo dobré do administrační části aplikace přidat. Z důvodu nedostatku casu budou tyto funkce navrhnuty a implementovány až v další etapě vývoje. Nejprve by bylo třeba předělat CMS na víceuživatelsky. Tato funkce je kritické nutná, protože většinou správu webových stránek provádí víc než jeden člověk. Přidat třeba různě skupiny uživatelů s různými právem vytvoření, editace a mazáni dat v CMS. Druha kritické nutná funkce je WYSIWYG editor pro vytvoření webových stránek. Tento editor dovoluje pracovat s html textem jako v obyčejným textovém redaktoru jako MS Word. Protože většinou běžný uživatel nezná ani html tohle značné zvýši použitelnost. Jako další funkce kterou lze přidat práce v administrační častí systému pomoci HTTPS zabezpečeného protokolu. Taky lze přidat vetší funkcionalitu pro práce s obrázky a funkcionalitu pro vytvoření na zaklade tento CMS internet obchodu. Hodnocení projektu Analýza projektu počítala s časovou náročností přibližně 500-600 hodin práce. Projekt v této chvílí už bylo věnováno cca 300 vypracovaných hodin a předpokládá se, ze mu bude věnováno ještě dalších přibližně 200 hodin. V této chvíle lze říct ze výsledný produkt bude dost použitelný, pochopitelný a rychlý. V porovnáni, se stejnými redakčními systémy, vystup stránek ve veřejné a administrační častí trvá o 5-10 krát rychleji. 25