ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická. Bakalářská práce. Jiří Šebek

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Bakalářská práce 2012

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Katedra grafiky a interakce [DCGI] Webová aplikace (eshop) pro využití v obchodní organizaci květen 2012 Student: Vedoucí práce: Ing. Ondřej Macháček

Čestné prohlášení Prohlašuji, že jsem zadanou bakalářskou práci zpracoval sám s přispěním vedoucího práce a používal jsem literaturu v práci uvedenou. Dále prohlašuji, že nemám námitek proti půjčování nebo zveřejňování mé bakalářské práce nebo její části se souhlasem katedry. V Praze dne 20.5.2012

Poděkování Děkuji Ing. Ondřeji Macháčkovi, vedoucímu bakalářské práce, za jeho cenné rady a připomínky, jimiž mi ochotně pomáhal. Dále děkuji své rodině za podporu při studiu.

Anotace: Bakalářská práce řeší úlohu vytvoření efektivní webové aplikace eshopu pro organizaci Eurocontracts s.r.o., zabývající se prodejem a distribucí elektronických zařízení, zejména zařízení radiových spojů a elektronických pojítek. Zadaný úkol, který má zeefektivnit administrativní práci organizace, zejména kontakt se zákazníky, zpřehlednit zákaznickou agendu a fakturaci zakázek, byl řešen pomocí technologií html, css, javascript, PHP, které autor zkombinoval tak, aby výsledné řešení úkolu splňovalo požadavky na bezpečný provoz podle současných standardů pro provoz podobných webových stránek. Řešení umožňuje zejména administrátorovi tohoto webu tyto hlavní kategorie funkčních požadavků: Evidence uživatelů, Evidence zboží a Evidence objednávek. Podrobný popis těchto funkčních požadavků je podrobně uveden v závěru této práce, spolu s výsledky testů a validací tohoto systému. Přínos této práce lze vidět zejména v odstínění prezetační vrstvy aplikace od perzistentní, což zvětšuje přehlednost a bezpečnost aplikace. Summary: This bachelor thesis deals with the creation of effective web application eshop for the organisation Eurocontracts s.r.o., which concentrates on the sales and the distribution of the electronic devices, especially the devices of the radio communication and the electronic connecting links. The given task is to make administrative work more effective. This matter covers particularly simplification of contacting the customers and making billing more clear. The task was solved using the technologies html, css, javascript, PHP. The author used these technologies to create the final application save according to the modern standards for running similar web applications. The proposed solution allows the administrator of the web application to use particularly these main categories of the functionality requirements: Evidence of users, Evidence of goods and Evidence of orders. Detailed description of each of these categories is referred to in the conclusion of this thesis. The gain of this thesis can be seen especially in the separation of the presentation layer from perzistant. This separation guarantees more security to the application and makes it more user friendly.

Obsah 1. Úvod... 9 2. Rešerše aplikace...... 10 2.1 Problematika eshopu...... 10 2.2 Výběr vhodného programovacího jazyka... 10 2.3 Výběr vhodného databázového systému... 12 2.4 Výběr modelu, metodiky vývoje softwaru... 13 2.5 Plán vývoje... 14 3. Sběr požadavků, analýza, návrh... 15 3.1 Vize... 15 3.2 Uživatelé... 15 3.3 Katalog požadavků... 16 3.3.1 Funkční požadavky... 16 3.3.2 Nefunkční požadavky... 17 3.4 Use case diagram... 18 3.5 Stavový diagram uživatelů... 19 3.6 Diagram nasazení... 20 3.7 Doménový model... 21 3.8 ER model... 22 3.9 Analytický model tříd... 23 3.10 Grafický návrh aplikace... 24 4. Implementace... 26 4.1 Struktura adresáře projektu... 26 4.2 Životní cyklus formuláře... 27 4.3 Bezpečnost... 28 4.4 Implementace spojení s databází... 30 4.5 Komunikace mezi stránkami... 31 4.6 Implementace usecase... 32 4.6.1 Zobrazení, přidávání a rozesílání aktualit... 32 4.6.2 Uživatelské účty... 34 4.6.3 Vyhledávání a zobrazování zboží... 36 4.6.4 Funkce košíku... 37

4.6.5 Správa zboží a kategorií... 40 4.6.6 Správa objednávek... 42 4.7 Použité javascripty... 44 4.8 Stránkování... 44 4.9 Validace html a css... 45 5. Testování tabulka regresivních testů... 47 6. Instalace... 49 6.1 Výběr serveru... 49 6.2 Samotná instalace... 49 6.3 Bezpečnost na úrovni webového serveru... 49 7. Závěr... 50 8. Seznam zkratek... 52 9. Seznam tabulek, obrázků a ukázek kódů..... 53 9.1 Tabulky... 53 9.2 Obrázky... 53 9.3 Ukázky kódů... 54 10. Seznam použité literatury... 55

Úvod 1. Úvod Úkolem bakalářské práce je vytvořit webovou aplikaci eshop, pro využití v obchodně výrobní organizaci Eurocontract s.r.o., která umožní zkvalitnění a urychlení hospodářské a administrativní činnosti organizace, zvýší efektivnost kontaktu se zákazníky, a tím zvýší i příjmy organizace. Tento typ aplikace je v dnešní době velmi rozšířený, jeho jednoznačnou výhodou je rychlá a přehledná informovanost zákazníka, možnost jeho okamžité reakce na nabídku organizace, promptní uzavření transakce, a tím celkové zefektivnění obchodního vztahu. Zároveň tato webová aplikace umožní ucelenou nabídku zboží a služeb organizace, jakož i přehledně prezentovat základní technické parametry nabízeného zboží a tím dává možnost zákazníkovi se rychle zorientovat v nabidce organizace. V první části je popsána problematika eshopu a výběr vhodného programovacího jazyka. Dále je zde rozebrán výběr modelu a metodiky vývoje softwaru. Druhá část se zabývá konkrétním řešením sběru požadavků, analýzy, návrhu aplikace. Dané diagramy byly vytvořeny pomocí nástroje Enterprise Architect. V třetí části je popsána konečná implementace a testování. Dané řešení bylo navrženo tak, aby bylo v souladu s moderními OOP nároky na aplikaci a tedy aby nebyl problém aplikaci rozšířit. Aplikace je navržena tak, aby byla bezpečná a zárověň výkonná. Implementace obsahuje jak veřejnou tak administrační část. V průběhu řešení práce byly porovnávány jednotlivé způsoby implementace a diskutovány jejich výhody. Závěr práce vyhodnocuje celkový způsob řešení této aplikace. 9

Rešerše aplikace 2. Rešerše aplikace 2.1 Problematika eshopu Mezi internetovými aplikacemi patří eshop v současné době mezi nejčastější. Slouží zákazníkovi k vyhledávání zboží a jeho objednání. Majiteli eshopu slouží k nabídce produktů a následně k příjmu objednávky od zákazníka. Existuje několik způsobů jak takovou aplikaci vytvořit. První je aplikaci naprogramovat v některém programovacím jazyce, což je i obsahem této bakalářské práce. Většinou se jedná o skriptovací jazyk. Druhým způsobem je použít CMS systém či opensource eshop. Zde bývá problém vybrat ten správný, protože některé CMS systémy jsou primárně jen redakční systémy a buď velmi špatně nebo vůbec nepodporují funkce eshopu. Také záleží na výběru toho, jestli je CMS systém opensource nebo komerční. Z opensource patří mezi nejznámnější Joomla, WordPress. Komeční CMS systém je např. JPublisher. Třetím způsobem je využít již naprogramovaného opensource eshopu. Tato varianta se může zdát v tomto ohledu nejlepší alternativou, avšak mohou při práci s nimi být problémy např. obtížná práce s tabulkami, nízká výkonnost. Výhoda eshopu oproti klasickému kamennému obchodu je zřejmá. Zákazník nemusí opustit práh domu a může si objednat cokoli nalezne v nabídce eshopu. Stále více uživatelů využívá tento potenciál internetu. Eshop může také vydělávat sám o sobě z reklam, které může obsahovat. 2.2 Výběr vhodného programovacího jazyka V dnešní době existuje velké množství programovacích jazyků a různých frameworků, které je vylepšují a jsou efektivní. Každý z těchto jazyků se však hodí jen na vývoj některých aplikací. K nejznámějším jazykům patří C, C++, Java, C#, Visual Basic, PHP. Na obr. 1 je znázorněno rozdělení programovacích jazyků podle úrovně. 10

Výběr vhodného programovacího jazyka Obr. 1: Rozdělení programovacích jazyků C je jazyk, který se používá převážně pro psaní systémových sofwarů, převážně unixových. Jedná se o kompilovaný jazyk, který někdo řadí mezi nízkoúrovňové a někdo mezi vysokoúrovňové jazyky. Oproti ostatním nižším jazykům jako např. Assembler je nezávislý na platformě a oproti ostatním vyšším jazykům zde neexistují objekty, ale jen datový typ struct. Většina ostatních jazyků přejímá syntax od jazyku C. Také zde není žádný garbage collector, takže programátor musí sám uvolňovat místa v paměti, které již nebude používat, aby nevznikly memory leaky. C++ je objektově orientovaný vyšší jazyk. Jedná se o rozšíření jazyka C. Podporuje nejen naivní a procedurální programování jako jazyk C, ale také objektově orientované a generické programování. Není však určen pro psaní webových aplikací. Java je velmi rozšířený moderní objektově orientovaný programovací jazyk. Je velmi podobná C++, avšak je pomalejší. Výhodou tohoto jazyku je garbage collector, který se stará o správu paměti. Zde se webový projekt dá vytvořit jako jeden velký aplet, který bude umístěn do html stránky. Avšak nevýhodou oproti klasickému webu tvořeném html a javascriptem je pomalé načítání apletů. Na druhou stranu mají velký potenciál ve vývoji. Druhá cesta vývoje je přes Enterprise Edition Java (Java EE). Ta se však používá spíše pro větší projekty. 11

Výběr vhodného programovacího jazyka C# a Visual Basic jsou programovací jazyky vytvořené firmou Microsoft. V současné době si většina programátorů oblíbila C#. Důvod je jednoduchý, Visual Basic má svoji vlastní syntax, ale C# syntax se odvíjí od jazyka C. C# je velmi podobný jazykům jako Java nebo C++. Visual Basic však má své výhody jako např zápisu XML přímo do kódu. Oba tyto jazyky nejsou přímo určeny pro vývoj webových aplikací. PHP je skriptovací jazyk, který je určen pro tvorbu dynamických webových stránek. Skripty vytvořené v PHP se nemusí překládat. PHP je podporováno u většiny webhostingových serverů a syntaxe PHP je podobná jako u jazyka C. Dá se velmi rychle naučit a v současné době se většinou využívá ve webových aplikací. Nevýhodou tohoto jazyka je, že programátor může snadno vytvořit velmi chaotický kód, ve kterém se ostatní lidé, kteří kód nevytvářeli, nevyznají. Z těchto jazyků se na webové aplikace hodí nejvíce Java EE, a PHP. V ostatních jazycích by byl vývoj buď zdlouhavý a náročný (jazyk C) nebo tento jazyk není přizpůsoben pro vývoj webových aplikací. Z těchto dvou jazyků jsem vybral PHP. Jeho další výhodou je, že velmi dobře komunikuje s databází MySQL a je multiplatformní. Na základě mnoha jazyků vznikly frameworky, které usnadňují práci programátorům. Z C# nebo Visual Basicu vznikl ASP.NET. Z PHP vzniklo řada frameworků jako Zend, Nette, Smarty. Každý z těchto frameworků má své výhody. Smarty odděluje aplikační vrstvu od zobrazovací (prezentační), což je velmi výhodné pro velké projekty, na kterých pracuje více lidí. Aplikační vrstvou jsou myšleny PHP skripty a zobrazovací vrstva je klasická html část webu. Nette a Zend obsahují MVC komponenty, které řeší například autorizaci a autentifikaci. V této bakalářské práci jsem se rozhodl vybrat jazyk PHP pro programování na straně serveru. Na klientské straně jsou vybrány technoogie html, css a javascript. Výsledná aplikace bude komunikovat jak je ukázáno na obr. 2. Tomuto typu aplikace se říká Dynamický web. Jakýkoli framework by byl pro tuto aplikaci zbytečný, frameworky se lépe využijí na větších projektech, kdy na jednom projektu pracuje více lidí. Další zpomalení ve vývoji aplikace by představovalo nastudovat jak daný framework funguje. Problémy u frameworků také bývají v tom, že chyby v aplikaci mohou být na straně frameworku. Tyto chyby se mnohem hůře hledají. 2.3 Výběr vhodného databázového systému Ze všech databázových systémů, které jsou v současnosti k dispozici jsem zvolil MySQL. Je pro tento projekt výhodný, protože podporuje standarty SQL, není placený a ve spojení s PHP je rychlý. Také jako PHP je podporovaný u většiny webhostingů a je multiplatformní. Jedním z velkých konkurentů MySQL je Oracle, který ovšem placený je. 12

Výběr modelu, metodiky vývoje softwaru Obr. 2: Dynamický web (převzato z lit. 1) 2.4 Výběr modelu, metodiky vývoje softwaru U softwarových projektů je dobré promyslet, jestli nebude vyvíjen podle nějakého modelu či metodiky. Velmi záleží na velikosti projektu. U malých projektů, které se dají naprogramovat např. do týdne, není potřeba tyto postupy používat. U větších projektů se tyto postupy však osvědčí. Model nám určuje jednotlivé fáze SW projektu, zatímco metodika nám definuje co v jednotlivých fázích dělat a jaké mají být výstupy k dané fázi. Modelů a metodik existuje mnoho, v této bakalářské práci jsem zvolil spirálový model. Spirálový model má výhodu např. oproti modelu vodopádu, že se v jednotlivých fázích můžeme vracet. Princip spirálového modelu je, že iterujeme postupně všechny fáze viz obr. 3. Když při konzulaci se zákazníkem zjistíme nedostatky, tak je v další iteraci opravíme. Obr. 3: Spirálový model (převzato z lit. 2) 13

Plán vývoje 2.5 Plán vývoje Celý projekt byl naplánován od počátku podle spirálového modelu viz kapitola 2.4. Schůzky se zadavatelem z firmy Eurocontracts s.r.o. se konaly většinou jednou za 14 dnů, během kterých se řešily podrobnosti jednotlivých částí v projektu. Na začátku bylo těchto schůzek méně, avšak později kdy přibývaly use casy, byly tyto schůzky pravidelnější. Výsledný plán vývoje softwarovu je znázorněn na obr.4. Obr. 4: Plán vývoje softwaru 14

Sběr požadavků, analýza, návrh 3. Sběr požadavků, analýza, návrh 3.1 Vize Jak již bylo řečeno v úvodu této práce, systém bude sloužit jako webová aplikace (e shop) pro využití v obchodně výrobní organizaci, který umožní zkvalitnění a urychlení hospodářské a administrativní činnosti organizace, kontakt se zákazníky, a tím může zvýšit obrat a zefektivnit činnost organizace. Návrh systému se soustředí na tyto body: základní informace a prezentaci firmy přehlednost nabízených produktů a služeb vytvoření základních funkcí eshopu (dle katalogu požadavků níže) zajistit celkovou funkčnost aplikace rozdělení aplikace na veřejnou a administrační část, implementována bude jak veřejná tak administrační část použití vhodného programovacího jazyku/frameworku pro vývoj webových aplikací 3.2 Uživatelé Systém bude podporovat tři typy uživatelů: neregistrovaný zákazník registrovaný zákazník administrátor (admin) Neregistrovaný zákazník neregistrovaný zákazník se může registrovat, prohlížet zboží podle kategorií, prohližet stránky eshopu, vyhledávat zboží podle názvu nebo popisu. Registrovaný zákazník registrovaný zákazník může vše co neregistrovaný zákazník. Navíc se může přihlásit se, přidávat zboží do košíku, objednat obsah celého košíku, měnit údaje vlastního účtu nebo jej smazat. Admin admin může dělat vše co zákazník, ale navíc si může prohlížet veškeré objednávky, mazat je, změnit stav objednávky na vyřízenou, může prohlížet faktury k objednávkám, změnit oprávnění uživatele (zákazník, admin), smazat účet, přidat, upravit zboží z kategorie, odebrat zboží z kategorie, přidat novinky na stránky a zárověň tyto novinky rozeslat registrovaným uživatelům. 15

Katalog požadavků 3.3 Katalog požadavků Katalog požadavků zachycuje požadavky zadavatele. Požadavky se dělí na funkční a nefunkční (někdy též obecné) viz obr. 5. Většinou obsahují co nejméně informací o implementaci. Funkční požadavky obsahují co daný systém bude umět. Nefunkční požadavky definují systém jako celek. Většinou se jedná o požadavky na hardware. Obr. 5: Rozdělení požadavků (převzato z lit. 3) 3.3.1 Funkční požadavky Evidence uživatelů registrace uživatele přihlášení uživatele změna vlastních údajů smazání vlastního účtu změna oprávnění uživatele (pouze Admin) smazání uživatele (pouze Admin) Evidence zboží přidání zboží do košíku smazaní zboží z košíku změna počtu zboží v košíku vysypání celého košíku přidání zboží do kategorie (pouze Admin) úprava informací o zboží do kategorie (pouze Admin) odebrání zboží z kategorie (pouze Admin) přidání nové kategorie (pouze Admin) přejmenování kategorie (pouze Admin) 16

Nefunkční požadavky odebrání staré kategorie (pouze Admin) objednání zboží vyhledání zboží přes kategorii vyhledání zboží přes název nebo popis s využitím vyhledavače Evidence objednávek uložení objednávky výpis všech objednávek výpis nevyřízených objednávek generování faktur k dané objednávce 3.3.2 Nefunkční požadavky Grafické uživatelské rozhraní Provoz na osobním počítači Program bude vyvíjen v programovacím jazyce PHP Software bude kompatibilní s OS Windows 7, Vista a XP s nainstalovaným prohlížečem Firefox verze 8.0 a výše Bude podporováno uložení dat v DB Systém by měl být intuitivní a uživatel by neměl mít problémy s užíváním aplikace K užívání aplikace pro uživatele bude nutná klávesnice a myš K provozu aplikace na straně serveru bude potřeba server s nainstalovaným Apachem, s podporou PHP a MySQL Aplikace by měla chránit svá data před nahráním nesprávných dat (jak na straně klienta tak na straně serveru) Systém nebude vyžadovat pro klienty kromě osobního počítače s OS Windows 7, Vista nebo XP s nainstalovaným prohlížečem Firefox verze 8.0 nebo výší verze žádné další HW vybavení jako databázový server apod. Pro server bude vyžadován databázový server. 17

Use case diagram 3.4 Use case diagram Use case diagram se používá na zachycení funkčních požadavků. Obsahuje aktéry, use cases (případy užití), hranice systému a relace. Na obr. 6 je znázorněn use case diagram eshopu. Obr. 6: Use case diagram eshopu 18

Stavový diagram uživatelů 3.5 Stavový diagram uživatelů Stavový diagram se používá na zachycení stavů, které se mění v čase. Jedná se o dynamický diagram chování. Obsahuje stavy (jako např. počáteční, koncový) a přechody. Každý přechod může být popsán událostí, podmínkou a akcí. Na obr. 7 je znázorněn stavový diagram eshopu pro stavy uživatelů. Obr. 7: Stavový diagram eshopu 19

Diagram nasazení 3.6 Diagram nasazení Diagram nasazení zachycuje hardwarové komponenty a procesy mezi nimi a softwarem. Zde se používají uzly, spojení mezi nimi a artefakty. Artefakty bývají zdrojové kódy, tabulky v databázi. Tento typ diagramu patří mezi implementační diagramy. Na obr. 8 je znázorněn tento diagram pro eshop, je na něm vidět, že databáze je na jiném stroji než server nebo klient (tři různé uzly grafu). Obr. 8: Diagram nasazení eshopu 20

Doménový model 3.7 Doménový model Doménový model patří do části analýzy. Jeho cílem je zachytit model systému nezávislý na použité technologii. Na obr. 9 je znázorněn tento doménový model pro eshop, datové typy proměnných a metody by zde neměly být zobrazeny, ale v EA jsem přímo z tohoto modelu vycházel pro analytický model tříd v návrhové části, kde již mají být. Obr. 9: Doménový model eshopu 21

ER model 3.8 ER model ER model znamená Entityrelationship model. Tento typ modelu patří již do návrhové části. Vytváří ucelený obrázek o tom, které tabulky budeme mít v databázi. Na obr. 8 je znázorněn tento ER model pro eshop, avšak neobsahuje jen entity a relace, ale přímo tabulky s datovými typy jako INTEGER, VARCHAR a integritními omezeními jako NOT NULL, PRIMARY KEY a UNIQUE. Jak je na obr. 9 vidět entita Zboží se zde vyskytuje 2x. Jednou jako tabulka Zboží, která reprezentuje zboží v nabídce v určité kategorii. A podruhé jako Zboží objednávka, aby zboží, které již někdo objednal, zůstalo v objednávce při smazání zboží z kategorie. SQL dotazy najdete v php stránce, která vytvoří tyto tabulky i s uživatelem administrátorem. Z obr. 10 je vidět, že používáme cizí klíče, takže nemůžeme použít engine MyISAM. Engine, který jsme použily, je InnoDB. Tento engine podporuje cizí klíče. Obr.10: ER model eshopu 22

Analytický model tříd 3.9 Analytický model tříd Analytický model tříd je diagram, který zachycuje celkový statický pohled na aplikaci. Účelem je znázornit typy objektů, proměnných a jejich vztahy. Část tohoto diagramu vychází z doménového modelu. Na obr. 11 je znázorněn tento diagram pro eshop. Neobsahuje všechny soubory z důvodu přehlednosti, ale vždy je zde alespoň balíček, který reprezentuje funkcionalitu souborů. Obr.11: Analytický model tříd eshopu 23

Grafický návrh aplikace Perzistentní vrstva na obr.11 bude mít v aplikaci důležitou roli. Bude oddělovat databázovou vrstvu od prezentační, zlepšovat bezpečnost aplikace a zjednodušovat práci s databází. Při změně databáze z MySQL např. na Oracle postačí vyměnit třídy DBConnection a DB. Je tedy výhodná při změnách. 3.10 Grafický návrh aplikace Grafický návrh aplikace je jedna z částí, kterou se zadavatel projektu nejvíce vnímá. Požaduje, aby vzhled byl takový, aby mu co nejvíce vyhovoval. Proto často nestačí pouze jeden návrh, který by byl dokonalý a postačil. V případě eshopu byly postupně vytvořeny dva výsledné návrhy (viz obr. 13 a obr. 14), ze kterých si zadavatel vybral druhý (viz obr. 14). Je výhodou, že byla použita spirálová metodika vývoje softwaru, jak bylo popsáno v kapitole 2.3, protože se návrhy mohly měnit v průběhu vývoje. Nejprve byla vytvořena šablona grafiky jen pro úvodní stránku a pak u každého use case se podle ní udělala grafika dalších stránek. Určité aspekty na grafice museli být dodrženy jako barvy firmy, což je odstín modré. Vzhledem k teorii barev byla zvolena jedna komplementární barva a jedna barva doplňková k naší základní barvě modré (viz obr. 12). Oranžová a modrá jsou přirozené komplementární barvy vůči sobě. Doplňková barva se může vzít jak ze strany oranžové tak ze strany modré, v našem případě z obou. Obr. 12 Kruh barev (převzato z lit. 4) K těmto barvám, které jsme si již vybrali je potřeba vybrat ještě barvu písma, která musí být kontrastní vzhledem k pozadí dané oblasti. V prvním návrhu je pozadí střední části bílé, proto barva písma je černá. V druhém návrhu je pozadí navigace a středu modré, proto byla zvolena bíla barva písma. V horní části eshopu je zvolena barva písma tmavě modrá, protože u loga stránky je bílé pozadí. 24

Grafický návrh aplikace Obr. 13: Návrh GUI 1 Obr. 14: Návrh GUI 2 výsledná grafika 25

Implementace 4 Implementace Jak bylo popsáno v kapitole 2.2 pro implementaci eshopu byl zvolen jazyk PHP s databázovým dotazovacím jazykem MySQL. Na straně klienta byl použit jazyk Javascript a značkovací jazyk html 4.0 a css. 4.1 Struktura adresáře projektu Adresářová struktura tohoto eshopu obsahuje 4 hlavní adresáře (viz obr. 15). Jedná se o adresář classes, ve kterém jsou soubory php s definoványmi třídami použítých v eshopu. Obr. 15: Adresářová struktura projektu 26

Životní cyklus formuláře Druhý adresář se jmenuje faktury. Zde se budou ukládat faktury v pdf formátu, které se generují při přijetí objednávky od zákazníka. Třetí adresář se nazývá img. Jsou v něm všechny obrázky, které jsou použity v designu aplikace. Obsahuje jeden podadresář zbozi, kam se ukládají obrázky každého zboží eshopu, které admin uloží. Poslední adresář je js, který obsahuje javascriptové soubory. Tyto skripty jsou převážně pro kontrolování formulářů na straně klienta. Okolo těchto adresářů jsou ostatní php stránky. Adresář css jsem nezavedl pro lepší propojení css stylů s obrázky ve složce img. 4.2 Životní cyklus formuláře V eshopu jsou často používány formuláře od registrace až po odeslání objednávky. Formuláře bývají často bezpečnostním rizikem celé aplikace. Životní cyklus formuláře obecně obsahuje několik kroků. Nejprve se zobrazí. Pokud existují předvyplněná data z databáze tak se zobrazí s nimi, jinak je prázdný. V dalším kroku uživatel vyplní nebo upraví data ve formuláři a odešle je. Zde ještě na straně klienta existuje kontrola dat pomocí javascriptu, která buď odešle formulář nebo ne podle korektnosti vyplněných dat. Pokud uživatel má vypnuté javascripty, to znamená, že kontrola na straně klienta není, je formulář odeslán na server. Na straně serveru se nejprve zkontrolují data ve formuláři. Pokud jsou chybná, tak se vygeneruje stejný formulář s předvyplněnými daty. Pokud jsou správná, tak systém provede činnost požadovanou formulářem. Například uloží nového uživatele do databáze a pošle zpět zprávu, že uživatel byl vytvořen. Celý proces je znázorněn na obr. 16. V našem eshopu je tento postup dodržován. Obecně všechny soubory s formuláři jsou nazvány profilxxx.php jako např. profiluzivatele.php. Tento formulář je kontrolován javascriptem. Formulář odesílá data na Controllerxxx.php, např. ControllerUzivatele.php. Zde je automat, který vykoná danou funkci jako je např. přihlášení, registrace. 27

Bezpečnost Obr. 16: Životní cyklus formuláře U formulářů se setkáváme s dalším problémem, jak zabránit dvojímu odeslání dat. Tento problém bývá způsoben chybou uživatele (2x stiskl tlačítko odeslat) nebo se někdo snaží napadnout naší aplikaci. Tento problém byl vyřešen tím, že vždy po odeslání se stránka přesměruje na Controllerxxx.php (viz obr. 16). 4.3 Bezpečnost Obecně každá aplikace by měla být bezpečná. U webových aplikací se na bezpečnost dbá o to více, protože na internet se dostane dnes každý. A když někdo nalezne nezabezpečenou aplikaci na internetu, tak může způsobit velké škody od smazání celé databáze až po nahrání škodlivého souboru na server. Před desítkami let musel útočník mít velké znalosti, aby mohl něco takového udělat. Žádně softwary na provedení útoku neexistovaly. Dnes je situace opačná. Softwarů na různé útoky existuje hodně a útočník často nepotřebuje mít ani základní znalosti o programování či počítačové síti. Druhů útoků na webovou aplikaci existuje hodně. Jedná se o SQL injection, Crosssite scripting (XSS), CrossSite Request Forgeries (XSRF), nahrání škodlivého kódu na server a jiné. Útočníkovi také mohou velice pomoci v útoku chybová hlášení, které mohou obsahovat pro něj zajímavé informace. V navrženém eshopu neobsahují chybové hlášky žádné přidané informace pro útočníka. Poslední velmi důležitou věcí je ochrana hesla. V následujících odstavcích této kapitoly jsou popsány jednotlivé druhy útoků a způsoby ochrany navržené aplikace eshopu proti výše zmíněným nežádoucím útokům. 28

Bezpečnost Jednou z důležitých ochran je přímo chránit vstup od uživatele z textového pole formulářů pomocí funkce mysql_real_escape_string(). Tato funkce zaručuje přidání zpětných lomítek před nebezpečné znaky jako apostrof (viz obr. 17). Takto bezpečně upravené znaky pak můžeme použít pro dotazování k databázi. Když tyto uložené znaky poté chceme zobrazit uživateli je potřeba lomítka odstranit pomocí funkce stripslashes() (viz ukázka kódu 1). Obr. 17: Převedení nebezpečných znaků na bezpečné SQL injection je technika útoku, kdy útočník vloží do neošetřeného uživatelského vstupu sql dotaz. Díky tomu může vkládat, měnit a mazat informace v databázi. Obranou je ošetření uživatelských vstupů pomocí funkce mysql_real_escape_string(), jak je uvedeno v předešlém odstavci. XSS je útok, kdy útočník vloží do stránky škodlivý html kód nebo javascriptový kód. To může využít k znefunkčnění stránek, změnění vzhledu nebo k získávání informací od uživatele. Ochrana proti takovému typu útoku je filtrovat informace od uživatele, které zobrazujeme funkcí htmlspecialchars(). Tato funkce převádí znaky jako < > na html entity (viz obr. 18). V eshopu se jedná např. o zobrazení informací o uživateli v horní části stránky (viz ukázka kódu 1). Obr. 18 Převedení nebezpečných znak na html entity Položek: <?php echo stripslashes(htmlspecialchars($kosik>getpocet()));?><br> Cena: <?php echo stripslashes(htmlspecialchars($kosik>getcena()));?>, Kč Ukázka kódu 1: Užití funkcí stripslashes() a htmlspecialchars() ve výpisu informací košíku 29

Bezpečnost XSRF útok je založen na neočekávaném požadavku uživatele. Tento požadavek však není legitimní. Některé stránky se dají často lehce odhadnout jako i v našem případě admin.php. Ochrana proti přítupu někoho neautorizovaného je znázorněna v ukázce kódu 2. Další ochranou je, že všechny důležitá data jsou přenášena pomocí metody post. Vyjímku tvoří jen informace přenášené o aktuální stránce ve výpise zboží a při vyhledávání. if (isset($uzivatel)) { if ($uzivatel>getrole() > 1) { /*administrační stránka*/ }} Ukázka kódu 2: Zabezpečení proti vstupu do administrační části Dalším typem útoku je nahrání škodlivého kódu na server. V tom případě by na straně serveru mohl škodlivý kód způsobit velké škody. Řešením je kontrolovat upload souboru od typu po velikost souboru (viz ukázka kódu 3). V našem eshopu je toto ošetřeno také tím, že nahrát obrázek může pouze admin. $current_image=$_files['image']['name']; $typ = substr(strrchr($current_image, '.'), 1); if (!(($typ == "jpg") ($typ == "png"))) {} if($typ=="jpg"){$im=imagecreatefromjpeg($_files['image']['tmp_name']);} if($typ=="png"){$im=imagecreatefrompng($_files['image']['tmp_name']);} if(imagesx($im)>180 imagesy($im)>70){ /*ošetření*/} Ukázka kódu 3: Zabezpečení nahrávaného souboru Ochrana hesla je jednou z nejdůležitějších věcí. Ukládat heslo jako čistý text je velká chyba. Sice je jednoduché zjistit heslo uživateli při zapomenutí a poslat mu ho, ale přinejmenším heslo uživatele bude znát administrátor a vývojář aplikace. Jedná se tedy o bezpečnostní riziko. Správnou možností je tedy z hesla vytvořit pouze hash a ten uložit. Existují funkce, které tyto hashe vytváří. V této aplikaci jsem zvolil funkci sha1(), která vždy vrací 40 znaků. Z tohoto hashe se poté původní řetězec nedá zjistit. 4.4 Implementace spojení s databází Spojení aplikace a databáze je velmi důležité. Jak bylo řečeno v kapitole 2.2 PHP dobře podporuje propojení s MySQL. Důležitým aspektem je také, aby aplikace mohla být rozšířitelná např. při přechodu z MySQL na Oracle. Proto byly vytvořeny třídy DB a DBConnection, které implementují toto spojení pomocí MySQL API. Postačila by i jedna třída, ale zde byly zvoleny 30

Komunikace mezi stránkami dvě, aby měly vyšší cohesion (účelovost). Jde o to, aby třídy nedělali moc odlišných věcí. Třída DBConnection se stará o připojení k databázi, výběr databáze, příkaz query, zavření spojení. Na ní je závislá třída DB. Ta obsahuje již implementace funkcí select, selectlimit, insert, update, delete, fetch_array, free_result, getid. Pro prvních pět funkcí jsou potřebné údaje předány v parametru. Při přechodu např. na Oracle by tedy stačilo vyměnit pouze tyto dvě třídy. V celé aplikaci se tedy vytváří objekt DB, když je potřeba spojení s databází. Jedná se především o header.php, všechny stránky Controllerxxx.php. 4.5 Komunikace mezi stránkami K udržení stavu aplikace můžeme v PHP použít 4 možnosti: skrytá pole, obohacování odkazů, cookies a sessions. Skrytá pole jsou použita u některých formulářů Profilů jako např. ProfilObjednavek.php, když jsou potřeba další údaje pro Controllerxxx.php, které ve formuláři nejsou. V případě našich objednávek se jedná o IDU. IDU je unikátní ID uživatele, podle kterého si Controller najde správného uživatele v databázi, který objednávku vytvořil. Obohacování odkazů již není nejlepší možnost předání proměnné. Proměnné jsou totiž vidět v adrese stránky. Tento typ přenášení proměnných se většinou používá pro filtrování dotazů a věcí, které nemohou ohrozit bezpečnost aplikace. Výsledné proměnné se poté nachází v poli $_GET[ ]. V eshopu je tato technika použita jen pro vyhledávání, filtrování zboží podle kategorií a stránkování. Důvod je jednoduchý, nejedná se o nebezpečná data. Veškeré formuláře v eshopu používají metodu post, kvůli bezpečnosti. Cookies je technologie, která je založena na tom, že server ukládá informace přímo na klientovi. Využít se dají např. na počitadlo návštěv, ale je zde hrozba toho, že kdokoli si vypůjčí Váš počítač, tak tyto informace vidí a může je i použít. Cookies na klientovi totiž nejsou nijak chráněné. Tato varianta předávání proměnných v eshopu nebyla použita. Pro udržování stavu aplikace je velmi vhodná poslední varianta a to pomocí sessions. Jedná se o kombinaci cookies a lokální databáze. Přístup k těmto proměnným je poté přes pole $_SESSION[ ]. Nejprve server přidělí session identifikátor (PHPSESSID) a vyhradí si v databázi místo pro tyto session proměnné. Výhodou oproti jiným metodám je, že se posílá pouze tento identifikátor session (viz obr. 19). 31

Komunikace mezi stránkami Obr. 19: Sessions v PHP (převzato z lit. 1) V navrhovaném eshopu jsou sessions použity na přenášení nejen proměnných jako řetězce $_SESSION['upozorneni']. Tato proměnná slouží k přenášení řetězců jako špatně vyplněný formulář, nepovolený přístup, objednávka přijata apod. Pomocí sessions se dají také přenášet celé objekty. Rozdíl oproti proměnným je, že se objekt musí serializovat před uložením do session. A když tento objekt chcete použít musí se deserializovat. V eshopu jsou takto přenášeny nejčastěji objekty košik a uživatel. 4.6 Implementace usecase 4.6.1 Zobrazení, přidávání a rozesílání aktualit Novinky může uživatel vidět na hlavní stránce index.php (viz obr. 20). Jedná se o klasický výpis z tabulky Novinky (viz ukázka kódu 4). Obr. 20: Novinky 32

Zobrazení, přidávání a rozesílání aktualit echo '<div class="novinky">'; $co = "*"; $odkud = "Novinky"; $podminka = '0=0'; $db>select($co, $odkud, $podminka); echo '<div class="shadow">novinky<hr></div>'; if ($db>pocet_radku() == 0) { echo '<h2>momentálně neexistují žádné novinky.</h2>'; } else { while ($row = $db>fetch_array()) { echo '<div class="novinkynadpisy">'. stripslashes($row['predmet']). ' [' stripslashes($row['datum']).. ']</div> '. stripslashes($row['obsah']).''; }$db>free_result();}echo '</div>'; Ukázka kódu 4: Výpis novinek Novinky může vkládat pouze administrátor. Každá novinka se poté objeví nejen na hlavní stránce, ale také se rozešle jako email všem uživatelum eshopu. Administrátor se dostane na tuto funkčnost přes odkaz Správa serveru. Tento use case je implementován přes admin.php, kde admin napíše aktualitu, předmět a formulář odešle (viz obr. 21). Data se odešlou na ControllerNovinky.php. Tam se Novinka uloží a odešle všem uživatelům jako mail (viz ukázka kódu 5). V této ukázce je použit příkaz header("location: ". $_SESSION['ref']), tato funkce přesměruje stránku jinam. V našem případě a to i v případě všech funkcí košíku, jak bude vidět v dalších kapitolách, přesměruje na stránku předešlou. V proměnné $_SESSION['ref'] je uložena adresa předchozí stránky. Uložení se provádí při každé návštěvě stránky, kdy v header.php je vytvořen objekt URL a zavolána metoda selfurl(). Ta uloží adresu do session. 33

Zobrazení, přidávání a rozesílání aktualit Obr. 21: Administrační část novinek $co = "*"; $odkud = "Uzivatel"; $podminka = "0=0"; $db>select($co, $odkud, $podminka); while($row = $db>fetch_array()) { mail($row['email'], $_POST['predmet'], $_POST['novinky']);} $db>free_result(); $datum = date('ymd H:i:s'); $kam = "Novinky"; $co = "predmet, obsah, datum"; $hodnoty = '"'.$_POST['predmet'].'","'.$_POST['novinky'].'","'.$datum. '"' ; $db>insert($kam,$co,$hodnoty); header("location: ". $_SESSION['ref']); exit(); Ukázka kódu 5: Uložení a rozesílání novinek 4.6.2 Uživatelské účty Funkce s uživatelskými účty zahrnuje registraci, přihlášení, odhlášení, změnu vlastních údajů a smazání účtu. Admin poté může ještě měnit ostatní účty (kromě hesel) a mazat je. Registraci nového účtu je možné pod odkazem Registrace na hlavní stránce. Ten nás odkáže na profiluzivatele.php. Po vyplnění a odeslání formuláře na controlleruzivatele.php je formulář nejprve zkontrolován pomocí javascriptové kontroly a poté ještě na serverové části. Jak již bylo zmíněno v kapitole 4.2 je to kvůli tomu, že javascript lze v prohlížeči vypnout. Controller účet vytvoří, přihlásí uživatele a pošle na email uživatele zprávu o vytvoření účtu. 34

Uživatelské účty Přihlášení je realizováno podobně. Formulář se zobrazuje pod odkazem Přihlásit. Vstupní údaje jsou zkontrolovány jak na klientské straně tak na straně serveru. To znamená, že uživatel neposílá prázdná pole. Kontrola hesla by vyžadovala spojení s databází. Na straně serveru kontrola probíhá v controlleruzivatele.php. Controllery poznají co mají udělat podle hodnoty submit tlačítka v tomto případě value= Přihlásit. Controller porovná údaje (u hesla si převede zadané heslo na hash a porovná s hashem v databázi) a buď přihlásí uživatele nebo ne. Vždy vrací nějaké upozornění v session proměnné pro uživatele co se stalo. Odhlásit se uživatel může pomocí tlačítka Odhlásit. Přenese nás na stránku controlleruzivatele.php. Zde controller smaže obsah session, zničí je a přesměruje na hlavní stránku (viz ukázka kódu 6). Odlášený uživatel totiž nepotřebuje objekt košíku, který je uložen v session, takže je vše v pořádku. session_unset(); session_destroy(); header('location: index1.php'); exit(); break; Ukázka kódu 6: Odhlášení uživatele Při změně údajů je potřeba klinout na odkaz Profil. Znova se ocitneme na stránce profiluzivatele.php, ale jsme již přihlášeni, takže textboxy jsou vyplněny údaji ze session objektu uživatele kromě hesla. Heslo je totiž stejně zahashováno a zpětná cesta neexisuje. Pro úpravu těchto údajů je povinné vyplnit staré heslo. Toto je bezpečnostní opatření proti tomu, kdyby někdo odešel od počítače a někdo k němu přišel a chtěl měnit údaje. V tomto formuláři je nejen možnost úpravy údajů, ale také je zde tlačítko na smazání účtu. Zde javascript vždy zobrazí kontrolní hlášku, jestli se náhodou uživatel nepřeklikl (viz obr 22). Obr. 22: Javascriptové upozonění před smazáním účtu 35

Uživatelské účty Administrátor navíc může měnit nejen vlastní účet, ale hlavně může měnit roli uživatelů. Avšak nemůže měnit heslo uživatelů. Změna údajů uživatele se nachází na odkazu Správa serveru, kde na admin.php v sekci Správa uživatelů vybere uživatele, kterého bude měnit. Tato část se musí kontrolovat, jestli je uživatel přihlášen a jestli má roli adminitrátora. 4.6.3 Vyhledávání a zobrazování zboží Každý uživatel má možnost nalézt zboží nejen podle kategorie v levém menu každé stránky (viz obr. 14), ale také podle zadaného názvu nebo části textu v popisu zboží do textboxu s tlačítkem vyhledat (viz obr. 23). Výpis kategorií a vyhledávací textbox se nachází v hlavičce (header.php) každé stránky php, které uživatel vidí. Obr. 23: Vyhledávací textbox Při výběru kategorie z levého menu eshop uživatele odkáže na stránku view_kategorie.php, kde se zobrazí zboží z této kategorie. Protože může být v jedné kategorii hodně zboží, je zde naimplementováno stránkování v rozsahu deseti zboží (viz obr. 24). Proměnnou page si předáváme pomocí obohacování odkazů. Nejedná se o citlivou informaci, takže to neoslabuje bezpečnost aplikace. Obr. 24: Stránkování Vyhledávání zboží je naprogramováno tak, že při zadání textu do vyhledávacího textboxu je uživatel přesměrován do search.php, kde je vstup ošetřen pomocí funkce mysql_real_escape_string() a použita metoda select třídy DB k dotazu na databázi a výsledek je vypsán uživateli. Dotaz na databázi vypadá jako ukázka kódu 7. Při kliknutí na odkaz na zboží je přenesen na stránku view_zbozi.php, která zboží zobrazí. 36

Vyhledávání a zobrazování zboží $hledaneslovo = mysql_real_escape_string($_get['keywords']); $co = "*"; $odkud = "Zbozi"; $podminka = 'nazev LIKE "%'. $hledaneslovo. '%" OR popis LIKE "%'. $hledaneslovo. '%"'; $db>select($co, $odkud, $podminka); Ukázka kódu 7: Dotaz na vyhledání zboží Podle tohoto dotazu by se mohlo zdát, že asymptotická složitost je lineární. Avšak sloupce název a popis v databázi jsou označeny jako index (viz obr 25). Index je pomocná datová struktura, která urychluje hledání dat v tomto sloupci. Většinou se používá datová struktura halda, takže asymptotická složitost je logaritmická. Přirozeně v databázích jsou takto uloženy primární klíče, protože podle nich se většinou dotazujeme. Je ale pravdou, že toto uspořádání v databázi obecně zpomaluje operace insert, update a delete. Naproti tomu je výhodou, že engine InnoDB podporuje cizí klíče. Existovala zde ještě jedna možnost a to použít fulltextové vyhledávání. Bohužel engine InnoDB toto nepodporuje. Pro fulltextové vyhledávání by se musel použít engine MyISAM. Fulltextové vyhledávání je více optimalizované než běžné, které jsme použili v ukázce kódu 7, ale poté bychom neměli cizí klíče (MyISAM je nepodporuje) a museli bychom při smazání kategorie ošetřit mazání všech zboží ručně, které v této kategorii byly. Tato varianta by byla však pracnější a náročnější. Obr. 25: Důležité sloupce označny jako index 4.6.4 Funkce košíku Všechny funkce košíku u eshopu jsou velmi důležité. Mezi tyto funkce patří: přidání zboží do košíku, odstranění zboží z košíku, změnu počtu zboží, vyprázdnit celý košík, odeslat objednávku i s vytvořením faktury. 37

Funkce košíku Přidání zboží do košíku je možné pomocí tlačítka Přidat do košíku u každého zboží v dané kategorii. Každé zboží je formulář, při kliknutí na tlačítko Přidat do košíku se tento formulář odešle na controllerkosiku.php i s informacemi o zboží. Controller nejprve zkontroluje, jestli vůbec objekt košíku v session existuje a deserealizuje ho. Pokud neexisuje, tak ho vytvoří. Poté vytvoří objekt zboží a zkontroluje, zda již zboží není v košíku. V objektu košík je pole $seznamzbozi, které uchovává objekty zboží. Pokud se zboží v poli $seznamzbozi nachází (porovnávají se ID objektů), tak se jen přičte počet zboží ke stávajícímu počtu. Pokud se objekt v poli nenachází tak se do něj uloží. Objekt košíku se uloží do session a také se do session uloží zpráva 'Zboží přidáno do košíku!', aby byl uživatel informován co se děje. Poté pomocí funkce header se přesměrujeme na poslední stránku, která byla uložena v session. Ve výsledku uživatel přidá zboží a ani neví, že navštívil stránku controllerkosiku.php. Pro další funce je potřeba kliknout na odkaz košík. Ten nás přesměruje na stránku profilkosiku.php. Zde jsou vypsány všechny položky košíku (viz obr. 26). V implementaci to znamená, že každé vypsané zboží je formulář, které odesílá informace o zboží metodou POST na controllerkosiku.php. Také se v session přenáší objekty uživatel a košík. Jak je na tomto obr. 26 vidět, košík si explicitně uchovává počet položek a celkovou cenu, kterou může uživatel vidět neustále v horní části stránky. Všechny funkce jsou založeny na komunikaci s controllerkosiku.php, který komunikuje s databází a přesměruje uživatele zpět. Obr. 26: Košík eshopu a jeho funkce 38

Funkce košíku Tlačítko Odebrat u daného zboží v košíku odešle formulář na controllerkosiku.php, kde controller najde objekt zboží podle ID v poli $seznamzbozi v objektu košíku a smaže ho. Funkce tlačítka Změnit u daného zboží je velmi podobná. Controller najde zboží v poli a změní počet. Dále také opraví celkovou cenu a celkový počet zboží v košíku. Tlačítko Vyprázdnit celý košík je implementováno v controlleru tak, že přepíše celý objekt košíku na null a uloží ho do session, viz ukázka kódu 8. $_SESSION['kosik'] = null; $_SESSION['upozorneni'] = 'Košík byl vyprázdněn!'; header("location: ". $_SESSION['ref']); exit(); Ukázka kódu 8: Vyprázdnění celého košíku Objednání zboží v košíku je implementováno v controlleru tak, že nejprve vytvoří záznam v tabulce objednávky, který odkazuje cizím klíčem na záznam uživatele v databázi. Tento záznam objednávky je poté spojen se záznamem v tabulce ZboziHistorie přes tabulku Obsahuje. Stav u objednávky je nastaven na nevyřízená. Controller nyní ještě vytvoří fakturu instanční metodou vytvorfakturu() objektu košíku. Třída Košík pro vytváření faktury v pdf formátu využívá knihovnu fpdf. Metoda vytvorfakturu() byla rozdělena na několik částí. První část vytvoří objekt FPDF, vytvoří stránku a nastaví font, který byl překonvertován na správné kódování a to windows cp1250. Zde je dobré podotknout, že veškerý obsah stránek, tabulky v databázi i jejich sloupce jsou kódovány v utf8. Problém s touto knihovnou je, že nepodporuje utf8 a pro češtinu si musíte překonvertovat font do správného kódování. Řešení v navrženém eshopu tedy je, aby všude fungovala čeština, že jen ta část stránky generující fakturu je v kódování windows cp1250. Druhá část obsahuje hlavičku faktury, třetí tělo a čtvrtá zavře dokument a uloží fakturu do souboru typu pdf s názvem jeho id. Ukázka kódu 9 ukazuje nejdůležitější příkazy a to pro vepsání textu a nakreslení rámečku do pdf. $pdf>setxy(450, $x); $pdf>write(24,'faktura '.$IDO.'/'.date("Y")); $zpusobrameceky = 600; $pdf>setxy($ramecek, $zpusobrameceky); $pdf>cell(270,80,'',1,1,'c'); Ukázka kódu 9: Ukázky práce s knihovnou fpdf 39

Funkce košíku Na závěr controller odešle email administrátorům o nové objednávce a uživateli o tom, že objednávka byla přijata. 4.6.5 Správa zboží a kategorií Správu zboží a kategorií může dělat pouze administrátor. Kategorie může přidávat, přejmenovávat a mazat. U mazání celé kategorie smaže i všechno zboží v té kategorii. Zboží může přidat, měnit údaje i nahrát jiný obrázek a mazat. Tyto use cases se nachází pod odkazem Správa serveru. U kategorií je jednoduší postup než u zboží. Funkce jsou přímo zde a nemusíme tedy být nikam přesměrováni (viz obr 27). Zde přímo uživatel zadá název nové kategorie pro její přidání a odešle pomocí tlačítka Přidat novou kategorii. Název kategorie je poslán na controllerkategorii.php, který vytvoří novou kategorii v databázi. Pro přejmenování kategorie uživatel vybere existující kategorii, zadá nový název a odešle pomocí tlačítka Přejmenovat kategorii. Pro smazání stačí jen vybrat existující kategorii a smazat pomocí tlačítka Smazat kategorii. K zpracování těchto dvou akcí slouží znovu controllerkategorii.php. Obr. 27: Správa kategorií U zboží je situace trochu komplikovanější. U zboží je více položek, které můžeme měnit. Proto v této části jsou dvě možnosti: přidat nové zboží a upravit (viz obr 28). Při změně musí uživatel vybrat zboží z rolovací lišty, které bude upravovat. 40

Správa zboží a kategorií Obr. 28: Správa zboží Obě možnosti uživatele přesměrujou na profilzbozi.php (viz obr. 29). Když upravujeme zboží tak jsou hodnoty přednastaveny. Při vytváření nového zboží jsou prázdné. Zde je navíc možnost smazání existujícího zboží pomocí tlačítka Smazat zboží, při vytváření zboží zde toto tlačítko není. Obr. 29: Úprava zboží Zde je velmi důležité ošetřit vstup nahrávání obrázku. Sice je pravda, že nahrávat může jen administátor, u kterého se nepředpokládá útok na vlastní server, ale přesto není zaručena 100% bezpečnost toho vstupu. Existují dvě řešení tohoto problému. Buď uložit obrázek na server do připravené složky a do databáze si uloží jeho název. Nebo druhou možností je uložit 41

Správa zboží a kategorií obrázek do databáze do sloupce typu blob jako binární data. Výhodou prvního řešení je menší režie databáze a také je načítání souboru rychlejší. Proto jsem v této práci zvolil první možnost. Ošetření takového nahrávání obsahuje kontrolu nejprve typu souboru, která pustí jen obrázky typu png a jpg. Obrázek typu gif schválně nechceme nahrávat, aby eshop působil seriózněji. Gif animace by příliš odváděly pozornost zákazníka od výběru zboží. Další věc, která se kontroluje je velikost souboru a jeho rozměry. Poté obrázek zkopíruje do adresáře img/zboží s unikátním názvem, vytvořeného podle času a datumu. Tento název se uloží do databáze ke zboží. 4.6.6 Správa objednávek Spravovat objednávky může pouze administrátor. Nachází se pod odkazem Správa serveru. Na obr. 30 je vidět, že jsou zde dva výpisy: Vypsat všechny objednávky a vypsat nevyřízené objednávky. Obr. 30: Úprava zboží Obě dvě tlačítka tlačítka stránku přesměrují na profilobjednavek.php. V obou případech je výsledkem výpis objednávek (viz obr. 31). V prvním případě všech objednávek a v druhém jen nevyřízených. Obr. 31: Výpis objednávek Pro prohlédnutí objednávky ji stačí vybrat kliknutím na tlačítko Prohlédnout. To nás přenese na stránku profilobjednavky.php (viz obr. 32). 42

Správa objednávek Obr. 32: Ukázka výpisu objednávky Tlačítko Smazat smaže danou objednávku z databáze a tlačítko Nastavit jako vyřízená nastaví stav objednávky na vyřízenou. Tyto akce jsou provedeny přes controllerobjednavek.php. Poslední tlačítko Faktura otevře fakturu ve formátu pdf pro danou objednávku, která je znázorněna na obr. 33. Obr. 33: Ukázka faktury 43

Použité javascripty 4.7 Použité javascripty Kromě všech javascriptových ošetření formulářů, byl vytvořen ještě jeden skript. Jedná se o nadpis.js. Při najetí kurzoru na logo firmy změní obrázek ve formátu png za animovaný obrázek ve formátu gif. A při přejetí kurzoru pryč zase vrátí původní obrázek, viz ukázka kódu 10. Tento efekt zviditelní funkcionalitu loga jako odkaz na hlavní stránku. Také upoutá pozornost uživatele, ale efekt zde není napořád, aby uživatele nerušila (např. při výběru zboží). function mouseoverimage1() { document.getelementbyid("nadpisimg").src = "img/nadpisotacejici.gif"; } function mouseoutimage1() { document.getelementbyid("nadpisimg").src = "img/nadpis.png"; } <a href="index1.php" title="eshop Eurocontracts"> <img id="nadpisimg" src="img/nadpis.png" alt="eshop Eurocontracts" onmouseover="mouseoverimage1()" onmouseout="mouseoutimage1()"></a> Ukázka kódu 10: Javascriptový efekt loga 4.8 Stránkování Stránkování zde můžeme implementovat dvěma způsoby. První možnost by byla uložit si všechny záznamy z databáze a na straně serveru je poté filtrovat. Nevýhoda tohoto řešení je patrná, u většího počtu záznamů zatěžuje databázi. Druhá možnost je filtrovat výběr přímo u dotazu na databázi. V této aplikaci byla použita druhá možnost. Stránkování je implementováno v rozsahu 10 zobrazených položek. Nejprve je potřeba zjistit, jestli nějaká stránka je nastavená (viz ukázka kódu 11). ($page1)*10 znamená, že potřebujeme na první stránce začínat zbožím s indexem 0, na druhé stránce indexem 10. Index zde představuje index v poli zboží v objektu košík. if (isset($_get["page"])) { $page = $_GET["page"]; } else { $page=1; } $start_from = ($page1) *10; Ukázka kódu 11: Zjištění stránky pro výpis Poté se musí upravit dotazový příkaz (viz ukázka kódu 12). Je zde vidět, že vybíráme přesný rozsah z databáze. Výpis je stejný jako na jiných stránkach, změna přichází na dolní části stránky, kde je výpis stránek (viz ukázka kódu 13). 44

Stránkování $co = "*"; $odkud = "Zbozi"; $podminka = 'IDKategorie = "'. $IDKategorie. '"'; $limit = $start_from.', 10 '; $db>selectlimit($co, $odkud, $podminka, $limit); Ukázka kódu 12: Dotaz na databázi pro data již v určeném rozsahu pomocí klíč. slova limit $co = "COUNT(IDZ)"; $odkud = "Zbozi"; $podminka = 'IDKategorie = "'. $IDKategorie. '"'; $db>select($co, $odkud, $podminka); $row = $db>fetch_array(); $pocetudaju = $row[0]; $pocetstranek = ceil($pocetudaju / 10); echo '<div class="center">'; for ($i=1; $i<=$pocetstranek; $i++) { if($i==$page){ echo "<span class='vetsi'> ".$i."</span> "; }else{ echo "<a class='stredoveodkazy' href='view_kategorie.php?idkat=". $IDKategorie."&kat=".$Kategorie."&page=".$i."'>".$i."</a> "; } } echo '</div>'; Ukázka kódu 13: Výpis stránek 4.9 Validace html a css Aplikace této práce prošla validací jak html validátoru tak css validátoru (viz obr. 34). Obr. 34: Výsledky validátorů html a css 45

Validace html a css Validátor css našel pouze některé varování a to se týkalo použitých css3, které zatím tento validátor ne zcela podporuje (viz obr. 35). Stránky byly spouštěny pod různými prohlížeči a grafický výsledek byl vždy velmi podobný. Jediná odlišnost je stín pod prostředním prvkem stránky. Tento css3 styl podporuje zatím jen prohlížeč firefox. Obr. 35: Varování ohledně použitých css3 stylů 46