Bankovní institut vysoká škola Praha. diplomová práce

Transkript

1 Bankovní institut vysoká škola Praha Tvorba webového redakčního systému pomocí technologie ASP.NET diplomová práce Bc. Roman Oujezdský Duben

2 Prohlášení: Prohlašuji, ţe jsem esej zpracoval samostatně a s pouţitím uvedené literatury. V Praze dne Roman Oujezdský - 2 -

3 Poděkování: Chtěl bych touto cestou poděkovat panu docentovi Stanislavu Hornému za odborné vedení diplomové práce, poskytování rad a informačních podkladů

4 Anotace práce: Cílem projektu je vytvoření webového systému, který usnadní uţivatelům editaci webových stránek. V tomto případě bereme uţivatele jako osobu, která nemá ţádné nebo minimální zkušenosti s psaním webových stránek. Proto musí být navrhovaný systém co nejjednodušší a uţivatelsky přívětivý a přehledný. Systém musí umět vytvářet články a umisťovat je to jednotlivých rubrik, vést databázi autorů, kteří budou mít moţnost vkládat a editovat jednotlivé články, umoţnit čtenářům jednotlivé články okomentovat a ohodnotit. Dále musí umoţnit šéfredaktorovi schválení jednotlivých článků před samotným zobrazením na stránkách. Backend systému bude zabezpečovat SQL databáze. Redakční systém musí být obsluhován pomocí webového rozhraní a musí být konstruován pro bezproblémový provoz na jakémkoliv prohlíţeči. The goal of this project is to set up a web system that would simplify web pages edition. In this case it is consernig a user as someone who has no or just little experience with coding of web pages. That s why the designed sytem must as simple as possible, use friendly and well-arranged. The system must be able to create articles and locate them into detached sections, administer the database of authors who will be allowed to enter and then edit individual articles, which will be lately commented and evaluated by the readers. It also has to allow the general editor to authorise all the articles before they are featured on websites. Backend systému bude zabezpečovat SQL databáze. The editorial systém must be operated via web interface and it must provide trouble free operating on any browser

5 Obsah 1 Úvod Srovnání technologií vývoj HTML/XHTML CGI - Common Gateway Interface Nástup serverových skriptovacích jazyků ASP.NET PHP PHP vs ASP.NET SQL Základní Pojmy UML - Unified Modeling Language CSS CSS reset Charakteristika projektovaného systému Specifikace požadavků na redakční systém Návrh UML diagramů Popis k jednotlivým usecase: Vývoj samotné aplikace Rozvržení databáze Membership DB CSS Master page Menu

6 4.6 WYSIWYG - FCKEditor Web.config Login ADO.NET - Active Data Objects for.net SEO - Search Engine Optimalization Katalogové vyhledavače Fulltextové vyhledavače SEO v praxi Bezpečnost SQL injection Bezpečnostní opatření Skript injection Nasazení na web-hostingový server Závěr Terminologický slovník Zdroje

7 1 Úvod V posledních letech se internet stal všudy přítomnou sloţkou nejen v osobním ţivotě, ale i v profesním. Firma, která nemá svojí webovou stránku, stejně tak jako běţný občan ovou schránku, jako by neexistovala. Prostřednictví webového rozhraní se nyní dozvídáme například o chystaných změnách územního plánu, sledujeme oblíbený pořad, nebo čteme noviny. Bohuţel ne všichni mají dostatečné technické znalosti, aby mohli sami přispívat do tohoto virtuálního prostředí. Proto jsem se rozhodl vytvořit redakční systém, který by umoţnil zveřejňování informací na webových stránkách v úhledné podobě a jehoţ by byl schopen obslouţit i uţivatel neznalý technických náleţitostí. Pro tento projekt jsem si vybral technologii ASP.NET s podporou databáze SQL. V úvodu práce bych se chtěl zaměřit nejen na pouţité technologie, ale i na technologie, které s internetem souvisejí a také s moţnostmi jejich vyuţití. V následující části se chci zabývat návrhem systému, jednotlivých případů uţití a v neposlední řadě i návrhem samotné databáze. Následující část bude zaměřena na samotný vývoj redakčního systému. Tady chtěl bych popsat pouţité metody, postupy v kódování a konfigurace jednotlivých komponent. Pokud má být aplikace nasazena na hostingový server třetí strany, musí být i řádně zabezpečena. V další kapitole bych chtěl probrat zabezpečení aplikace a představit některé z nejběţnějších typů útoků jako je například SQL injection. Pokud má redakční systém ambice získat si své příznivce, musí být k nalezení minimálně přes nejznámější internetové vyhledavače jako je například Google.com. Tedy optimalizace webových stánek právě pro tyto vyhledavače nesmí v této práci chybět. Chtěl bych podotknout, ţe navrhovaný systém nemá slouţit jako blog, nebo jemu podobné webové aplikace. Cílem projektu je vytvoření webového systému, který usnadní uţivatelům editaci webových stránek. V tomto případě bereme uţivatele jako osobu, která nemá ţádné nebo minimální zkušenosti s psaním webových stránek. Proto musí být navrhovaný systém co nejjednodušší a uţivatelsky přívětivý a přehledný. Systém musí umět vytvářet články a umisťovat je to jednotlivých rubrik, vést databázi autorů, kteří budou mít moţnost vkládat a editovat jednotlivé články, umoţnit čtenářům jednotlivé články okomentovat a ohodnotit. Dále musí umoţnit šéfredaktorovi schválení jednotlivých článků před samotným zobrazením na stránkách. Správce stránek by pak měl mít mimo jiné i moţnost mazání nevhodných či vulgárních komentářů. Backend systému bude zabezpečovat SQL databáze. Redakční systém - 7 -

8 musí být obsluhován pomocí webového rozhraní a musí být konstruován pro bezproblémový provoz na jakémkoliv prohlíţeči

9 2.1 Srovnání technologií V této kapitole bych se chtěl věnovat bliţšímu seznámení s jednotlivými technologiemi, které pouţiji a které by mohli být pouţity k tvorbě redakčního systému. Jak je jiţ z názvu patrno, konečný systém bude tvořen za pomoci technologie ASP.NET. Samozřejmě to není jediná moţnost a nabízí se další alternativy jako je například populární PHP nebo JSP. Nicméně neţ začneme porovnávat konkrétní technologie, rád bych nastínil chronologický vývoj webových technologií a webu jako takového vývoj HTML/XHTML Historie webu začala vývojem hypertextů jiţ ve 40. letech minulého století, kdy Vannevar Bush představil hypertextový systém Memex (název vzniknul spojením anglických slov memory a index ). Nicméně první neoficiální verzi HTML (hypertext markup language) vyvinuli aţ Tim Berners-Lee a Robert Caillau v roce 1989 při spolupráci na propojení informačního systému pro výzkumné středisko CERN. V roce 1991 pak vzniká oficiální verze jazyka HTML v 0.9, která je jiţ propojena s jednoduchým protokolem HTTP (HyperText Transfer Protokol), ovšem bez podpory grafického reţimu. První prohlíţeč s grafickým rozhraním vzniká o dva roky později v NCSA (National Centre for Supercomputer Applications) pod jménem Mosaic. Následují verze 2.0, 3.2 a 4.0, které přinesly podporu grafiky, formulářů, tabulek, rámů, zarovnání textu či stylových elementů pro ovlivňování vzhledu. HTML postupně začal odpovídat syntaxi SGML (Standard Generalized Markup Language), coţ je univerzální značkovací META jazyk, který je platným standardem ISO. Mezi zajímavosti patří fakt, ţe verze HTML 3.0 nebyla nikdy přijata jako standard, protoţe byla příliš sloţitá a ţádná firma nebyla schopna naprogramovat její podporu. Dne 24. prosince byla vydána verze 4.01, která opravovala některé chyby předchozích verzí, nicméně dle původního předpokladu se mělo jednat o verzi poslední. Jejím nástupcem se pak měl stát jazyk XHTML (Extensible Hypertext Markup Language), jehoţ specifikací byla například podpora XML (Extensible Markup Language) dokumentů se zpětnou kompatibilitou. V roce 2007 však došlo k zaloţení pracovní skupiny, která měla za cíl vytvořit novou verzi HTML, - 9 -

10 jenţ ponese označení HTML 5, a její XML variantu XHTML 5. Dnes vedle toho paralelně pokračuje i vývoj XHTML CGI - Common Gateway Interface Ruku v ruce s jazykem HTML vznikají i protokoly neboli standardy, dle kterých probíhá elektronická komunikace a přenos dat mezi koncovými body. Hlavní internetové protokoly jsou například TCP (Transmition Control Protokol) nebo IP (Internet Protokol). Nicméně můţeme se setkat i s aplikačními protokoly jako jsou známé POP3 (Post Office Protocol v. 3), SSH (Secure Shell), FTP (File Transfer Protocol), DHCP (Dynamic Host Configuration Protocol) a mnohé další. Zaměřme se ale na Common Gateway Interface neboli CGI, který vzniká kolem roku 1993 za účelem propojení externích aplikací (označovanou jako CGI skript) s webovým serverem. Toto rozhraní ve své době vlastně představovalo jediný způsob dynamického zobrazování obsahu. Princip fungování CGI nejlépe znázorní tento příklad Borka Bernarda s názvem Vyuţití webových technologií při vývoji webových aplikací: Srovnání PHP s ASP.NET. Klient zaţádá o určitou stránku, web server zjistí, ţe tento poţadavek má zpracovávat CGI skript, a pomocí standardního rozhraní CGI předá případné vstupní parametry od klienta příslušnému programu. Tento program svůj výstup předává zpátky webovému serveru opět pomocí rozhraní CGI. Web server případně přidá chybějící HTTP hlavičky a vše pošle zpátky klientovi. Obsluţný program můţe být jak kompilovaná aplikace napsaná třeba v jazyce C, tak interpretovaný skript napsaný např. v Perlu. Jedinou podmínkou, kterou musí CGI skript splňovat, je schopnost komunikovat s webovým serverem. Jednou z vlastností CGI byla moţnost nezávislosti na programovacím jazyku a to díky tomu, ţe CGI pouze definuje rozhraní. Podobné moţnosti nabízí aţ o mnoho let mladší technologie DOT.NET o které bude řeč později. Na druhé straně, zásadní nevýhodou CGI byla pomalá odezva. Při kaţdém poţadavku se program musel znovu zavádět do paměti, coţ bylo problémem při velkém mnoţství nebo frekvenci poţadavků (to řeší o něco mladší

11 nástupce FastCGI). Další výtkou bývá nepřehlednost kódu, která můţe být u větších projektů váţným problémem Nástup serverových skriptovacích jazyků Slabé stránky CGI nebo některých dalších běţných skriptovacích jazyků (např. neschopnost vytváření komunikačních spojení s ostatními počítači a aplikacemi pomocí protokolu TCP/IP) se snaţí vyřešit technologie jako PHP, nebo ASP a to tím, ţe je do HTML vkládají části určitého kódu, které jsou zpracovávány na straně serveru, ale které nejsou odesílány klientovi. Samozřejmě kaţdá z technologií můţe k problému přistupovat svou vlastní cestou a tím se výrazně lišit od ostatních, nicméně lze najít určité společné znaky, díky kterým si je vývojáři oblíbili. Začněme například jednoduchým zápisem kódu. Vývojář nemusí řešit předávání poţadavku ve vstupním streamu ani generování streamu výstupního, naopak velmi jednoduchým a transparentním způsobem píše jak HTML kód, tak určitou funkčnost v místech, kde je potřeba výstup generovat dynamicky. Z dalších výhod můţeme jmenovat například jednoduché zavádění do systému. Například instalace PHP je otázkou přesunutí několika málo souborů a pár konfiguračních zásahů do webového serveru. Také ovšem existuje mnoho balíků, které obsahují webový server (například Apache) spolu s PHP tak, aby bylo vše předpřipraveno k okamţitému pouţívání. Taktéţ u operačního systému Microsoft Windows je dnes instalace vlastního serveru otázkou několika kliknutí v ovládacích panelech. Poté stačí doinstalovat Framework.NET a jeden z mnoha vývojových nástrojů (například zdarma distribuovaný Visual Web Developer Express 2008) a pro vývoj dynamických webových aplikací je vše připraveno. Další nespornou výhodou těchto serverových skriptovacích technologií je také značná rozšířenost na trhu. Začínající vývojář má dnes téměř neomezené moţnosti dostat se ke kvalitním materiálům popisujícím různé postupy a metody jak psát aplikace. Na internetu můţeme najít nespočet webů, které se zaměřují na vývoj webových aplikací. Mnohé z příkladů neboli tutoriálů jsou uváděny v několika různých jazycích. Dokonce mnohé z

12 dostupných tutoriálů nabízejí moţnost stáhnutí kódu a jeho pouţití ve vlastní aplikaci. To samozřejmě značně usnadňuje celý proces psaní aplikace, jelikoţ vývojář jiţ nemusí tolik času trávit hledáním dokumentace k jednotlivým postupům. Nicméně, nic není dokonalé a vše má svoji druhou stranu mince. Stránky psané v ASP se občas zobrazují pomaleji, protoţe kód je na straně serveru pouze interpretován a nikoli kompilován. V mnoha případech se také stává, ţe se soubory ASP nelehce udrţují, protoţe nejsou strukturalizovány do jednotlivých částí jak je to například u novějších ASP.NET. (části kódu ASP určené pro stranu serveru a pro stranu klienta jsou vzájemně promíchány). Omezená podpora ošetření chyb a typové kontroly jsou jen jedním z dalších pojmů, které komplikují samotný vývoj aplikace ASP.NET V roce 2002 představuje Microsoft technologii ASP.NET 1, která má být přímou konkurencí JSP. ASP.NET má oproti svému předchůdci ASP několik zásadních inovací a to především: Díky kompilovanému kódu běţí aplikace rychleji a více chyb je zachyceno uţ při vývoji Uţivatelsky definované ovládací prvky lze pouţít jako šablony, čímţ se významně redukuje duplicitní kód Podobný přístup jako k aplikacím pro Windows zjednodušuje přechod od jednoho prostředí k druhému Bohatý výběr ovládacích prvků a knihoven tříd velmi zrychluje vývoj aplikací Programátoři mají na výběr velké mnoţství programovacích jazyků Schopnost cachovat celou stránku nebo pouze její části podstatně zvyšuje výkon serveru Lze jej provozovat na různých operačních systémech i webových serverech, např. IIS (Windows), Apache (Windows, Linux s open source implementací.netu Monem) 1 Ačkoliv název ASP.NET je odvozen od starší technologie pro vývoj webů ASP, obě technologie jsou velmi odlišné

13 Počínaje verzí 2 generuje ASP.NET validní HTML 4.0 / XHTML 1.0 / XHTML 1.1 kód a JavaScript. Aplikace zaloţené na ASP.NET jsou rychlejší, neboť jsou překompilovány do jednoho či několika málo DLL souborů (programový modul, který obsahuje procedury, funkce, datové typy, třídy nebo zdroje). Oproti tomu u skriptovacích jazyků, jak uţ jsem zmínil v předchozí kapitole, jsou stránky při kaţdém přístupu znovu a znovu překompilovány. Architekturu.NET Freamworku můţeme najít pěkně popsanou v publikaci pana Jeff Prosise, Programování v Microsoft.NET..NET Framework je určen k vytváření a provozování aplikací. Jeho zásadními komponenty jsou společný jazykový běhový modul (Common Language Runtime - CLR) a knihovna tříd rámce.net (Framework Class Library - FCL). CLR abstrahuje sluţby operačního systému a slouţí jako vykonávající jádro pro řízené aplikace, jejichţ všechny akce podléhají schválení u CLR. FCL poskytuje objektově orientované rozhraní API (Application Programming Interface), do něhoţ se řízené aplikace zapisují. Kdyţ píšeme aplikace rámce.net, vypouštíme API Windows 2, MFC (Microsoft Foundation Class Library) 3, a další nástroje a technologie, a místo nich pracujeme s FCL. Samozřejmě lze zavolat funkci API Windows nebo objekt COM (Component Object Model 4 ), ale není to ţádoucí, protoţe pak je zapotřebí přechod z řízeného kódu (kódu běţícího pod CLR) na kód neřízený (nativní strojový kód, který běţí bez pomoci runtimového modulu). Takové přechody omezují výkonnost a správce systému je dokonce můţe zakázat. 2 Application Programming Interface je sbírka procedur, funkcí či tříd nějaké, kterou můţe programátor vyuţívat. API určuje, jakým způsobem se funkce knihovny volají ze zdrojového kódu programu. Všechny programy v Microsoft Windows musí nezávisle na pouţitém programovacím jazyce komunikovat prostřednictvím Windows API. 3 Microsoft Foundation Class Library je knihovna, která zabaluje části Windows API do ucelených C++ tříd, které zajišťují pouţití a plnou kompatibilitu s většinou platforem OS Windows. Třídy spravují většinu objektů ve Windows a tedy předdefinovávají například okna nebo kontrolní panely. 4 Component Object Model není jazyk ani soubor objektů, ale pouze standard či programovací technika - nezávislá na programovacím jazyku a operačním systému. COM určuje základní vlastnosti objektů a pravidla pro práci s nimi

14 Obrázek č.1 Architektura.NET Frameworku PHP Hypertext Preprocessor (původně Personal Home Page) je skriptovací programovací jazyk, určený především pro programování dynamických internetových stránek. Nejčastěji se začleňuje přímo do struktury jazyka HTML nebo XHTML, coţ lze vyuţít při tvorbě webových aplikací. PHP lze pouţít i k tvorbě konzolových a desktopových aplikací. Poslední roky začíná narůstat síla PHP frameworků, které programátorům uzpůsobují a mnohdy ulehčují jejich programátorský styl. Z těch nejznámějších zmíním Zend Framework, CakePHP, nebo český Nette Framework. PHP frameworky jsou nejčastěji psané v objektovém kódu a zaloţené na MVC architektuře (Model-View-Controller). Při tvorbě PHP projektu, který vyuţívá některý z objektově psaných frameworků, je kód projektu psaný objektově, nicméně je ale důleţité si uvědomit, ţe pokud je objektový kód, nemusí být objektová i logika. V objektově strukturálním přístupu aplikace logiku postrádá a z pohledu architektury je stále strukturální. Aplikace pouze plní za sebou seřazené a do tříd obalené metody. Takovýmto přístupem jsou koncipovány středně sloţité projekty, které

15 vyţadují sloţitější komponenty (například z knihovny frameworku) a usnadňují práci programátorovi, mnohdy bohuţel na úkor perzistence PHP vs ASP.NET Protoţe v mnoha internetových diskuzích vře téma zda-li je lepší pro vývoj webových aplikací technologie PHP či ASP.NET, myslím si, ţe aspoň letmé srovnání těchto dvou rivalů do práce s tímto zaměřením rozhodně patří. Jelikoţ jsem se s PHP setkal pouze okrajově, omezím srovnání na výčet jednotlivých pozitivních bodů. ASP.NET Prostředí Windows + IIS.NET Framework jazykově neutrální lze pouţívat libovolný jazyk, který vyhovuje určitým pravidlům (Common Language Specification). Je moţno vyuţívat z nabídky více neţ 25 jazyků Postavena na principech OOP Oddělení skriptového kódu od HTML kódu Způsob konfigurace aplikace pomocí souborů Web.config a Machine.config PHP Platformová nezávislost Open Source Cena hostingu Jednoduchá syntaxe Nové objektově psané frameworky Některé další ze srovnání nabízí přiloţená tabulka:

16 Obrázek č. 2 Srovnání technologií ASP.NET a PHP SQL Databáze se staly běţným základem systémů, které poskytují úloţiště dat pro různé druhy aplikací. Programovací jazyky, jako např. C či VB, nebo skriptovací jazyky, jako např. VBScript nebo JavaScript, musí často provádět přístup k datovému zdroji za účelem načtení nebo úpravy dat prostřednictvím aplikace. Mnohé z těchto datových zdrojů jsou spravovány systémy pro řízení relačních databází (RDBMS), které pouţívají SQL (Structured Query Language) pro vytváření a změny objektů databáze a přidávání, načítání a změny dat této databáze. Relační databázový model sdruţuje data do tzv. relací (tabulek), které obsahují n-tice (řádky). Tabulky (relace) tvoří základ relační databáze. Tabulka je struktura záznamů s pevně

17 stanovenými poloţkami (sloupci - atributy). Kaţdý sloupec má definován jednoznačný název, typ a rozsah neboli doménu. Záznam se stává n-ticí (řádkem) tabulky. Pokud jsou v různých tabulkách sloupce stejného typu, pak tyto sloupce mohou vytvářet vazby mezi jednotlivými tabulkami. Tabulky se poté naplňují vlastním obsahem - konkrétními daty. Kolekce více tabulek, jejich funkčních vztahů, indexů a dalších součástí tvoří relační databázi. Relační model přináší celou řadu výhod, zejména mnohdy přirozenou reprezentaci zpracovávaných dat, moţnost snadného definování a zpracování vazeb apod. Relační model klade velký důraz na zachování integrity dat Základní Pojmy referenční integrita - definuje cizím klíčem, a to pro dvojici tabulek, nebo nad jednou tabulkou, která obsahuje na sobě závislá data (například stromové struktury). Tabulka, v niţ je pravidlo uvedeno, se nazývá podřízená tabulka (pouţívá se také anglický termín slave). Tabulka, jejíţ jméno je v omezení uvedeno je nadřízená tabulka (master). Pravidlo referenční integrity vyţaduje, aby pro kaţdý záznam v podřízené tabulce, pokud tento obsahuje data vztahující se k nadřízené tabulce, existoval odpovídající záznam v nadřízené tabulce. To znamená, ţe kaţdý záznam v podřízené tabulce musí v cizím klíči obsahovat hodnoty odpovídající primárními klíči nějakého záznamu v nadřízené tabulce, nebo NULL. cizí klíč - umoţňuje definovat akce, které mají nastat při pokusu o změnu nebo mazání záznamů v cizí tabulce. Například po smazání záznamu z cizí tabulky budou ve zdrojové tabulce řádky s odpovídající hodnotou cizího klíče taktéţ smazány, nebo budou jejich odkazy nastaveny na určitou (neutrální) hodnotu, nebo se smazání řádků v cizí tabulce zabrání. Omezení cizích klíčů tak představuje mechanismus pro udrţení referenční integrity databáze. primární klíč - Primární klíč je jednoznačný identifikátor záznamu, řádku tabulky. Primárním klíčem můţe být jediný sloupec či kombinace více sloupců tak, aby byla zaručena jeho jednoznačnost. Pole klíče musí obsahovat hodnotu, tzn. nesmí se zde vyskytovat nedefinovaná prázdná hodnota NULL. V praxi se dnes často pouţívají umělé klíče, coţ jsou číselné či písmenné identifikátory - kaţdý nový záznam dostává

18 identifikátor odlišný od identifikátorů všech předchozích záznamů (poţadavek na unikátnost klíče), obvykle se jedná o celočíselné řady a kaţdý nový záznam dostává číslo vţdy o jednotku vyšší (zpravidla zcela automatizovaně) neţ je číslo u posledního vloţeného záznamu (číselné označení záznamů s časem stoupá). normální tvar neboli kanonický tvar (případně kanonická forma nebo normální forma) objektu označuje forma, ve které můţe být objekt jednoznačně prezentován. Obrázek č.3 Příklad rozvrţení databáze. SQL je nejrozšířenějším jazykem pro relační databáze. Umoţňuje nejen správu dat v databázi, ale také správu samotné databáze. Pomocí příkazů SQL můţeme provádět přístup do databáze SQL přímo pomocí interaktivní klientské aplikace nebo skrze programovací jazyk aplikace či skriptovací jazyk. SQL patří mezi tzv. deklarativní programovací jazyky, coţ v praxi znamená, ţe kód jazyka SQL nepíšeme v ţádném samostatném programu (jako by tomu bylo např. u jazyka C nebo Pascal), ale vkládáme jej do jiného programovacího jazyka, který je jiţ procedurální. Se samotným jazykem SQL můţeme pracovat pouze v případě, ţe se

19 terminálem připojíme na SQL server a na příkazový řádek bychom zadávali přímo příkazy jazyka SQL. SQL se skládá z několika částí. Některé části jsou určeny pro administrátory a návrháře databázových systémů, jiné pak pro koncové uţivatele a programátory. První částí jazyka SQL je jazyk DDL - Data Definition Language. Jedná se o jazyk pro vytváření databázových schémat a katalogů. Způsob ukládání tabulek definuje jazyk SDL - Storage Definition Language. Třetí částí pro návrháře a správce je jazyk VDL - View Definition Language, určující vytváření pohledů (pohled si lze představit jako virtuální tabulku sloţenou z různých jiných tabulek). Poslední částí je jazyk DML - Data Manipulation Language, který obsahuje základní příkazy INSERT, UPDATE, DELETE a nejpouţívanější příkaz SELECT. S jazykem DML pracují nejvíce koncoví uţivatelé a bude vyuţit i v této práci UML - Unified Modeling Language Jazyk UML (v překladu unifikovaný modelovací jazyk) je v poslední době stále populárnější a to zejména díky tomu, ţe dává moţnost nahlédnout na navrhovaný systém pomocí diagramů s různou mírou podrobnosti. Tedy lze poměrně snadno začlenit do vývoje i zákazníka, který nemá značné znalosti v oboru. Je to zejména proto, ţe na rozdíl od převáţně textově orientovaných programovacích jazyků, vlastní grafickou syntaxi (tj. pravidla pro sestavování jednotlivých elementů jazyka do větších objektů) a sémantiku (tj. jednoznačná pravidla určující jednotlivým syntaktickým výrazům jejich význam). V současné době má jazyk UML největší význam při návrhu softwarových systémů, protoţe objektově orientovaný návrh kaţdé sloţitější aplikace je nezbytným předpokladem pro její úspěšnou a rychlou implementaci. Pro objektově orientovaný návrh je samozřejmě moţné pouţít různé podpůrné prostředky, zejména další odlišné typy diagramů, UML je však významné také v tom ohledu, ţe přesně specifikuje, co má daný diagram obsahovat, coţ je velmi důleţité zejména při sdílení informací mezi jednotlivými analytiky a vývojáři. Dále je jiţ z principu UML nutné, aby vytvářené grafy měly vnitřní konzistenci a přesně danou sémantiku, coţ u jiných typů grafů nemusí být obecně zaručeno. UML diagramů existuje

20 několik typů lišících se podle toho, jaké se pomocí nich plánují či zpracovávají úlohy. Tyto diagramy se od sebe odlišují především repertoárem pouţitých značek, způsobem jejich vzájemného propojení a s nimi související sémantikou. Mezi velké přednosti jazyka UML i na něm postavených UML diagramů patří existence otevřeného a rozšiřitelného standardu, podpora celého vývojového cyklu aplikace či jiného (ne nutně programového) systému a velká podpora pro různé aplikační oblasti. Pro širší vyuţití jazyka UML v praxi mluví také významný fakt, ţe je podporován celou řadou vývojových nástrojů, ať uţ samostatných aplikací určených pouze pro práci s UML, nebo i integrovaných vývojových prostředí (IDE), které v některých případech dovolují provádět převod informací mezi UML diagramem a algoritmem zapsaným v programovacím jazyce (a samozřejmě i opačným směrem, ten je však z pochopitelných důvodů sloţitější a ne vţdy uskutečnitelný). Obrázek č.4 Příklad pouţití jazyka UML

21 2.1.8 CSS Jestli má konečný produkt obstát v široké konkurenční nabídce na webu, musí si získat své zájemce nejen jednoduchým a intuitivním ovládáním, ale také vizuální přívětivostí. Statistiky říkají, ţe pokud uţivatele nezaujme webová stránka v prvních třech sekundách, odchází jinam. Technologie CSS nám v tomhle nabízí velice kvalitní moţnosti jak vdechnout webové prezentaci ţivot. Pouţívání kaskádových stylů ve srovnání se samotným HTML v praxi přináší výhody jako: Rozsáhlejší možnosti formátování. Například pro formátování bloku textu tj. určení vzdálenosti od jejich elementu či okraje stránky nenabízí HTML nic. CSS má vlastnosti padding 5 a margin 6. V HTML by bylo potřeba vytvořit sloţitou konstrukci vnořených tabulek. Jednodušší údržba webové prezentace. Pokud chceme změnit nějaký detail, jako třeba barvu nadpisu, nemusíme sloţitě procházet HTML kód nebo různé HTML šablony, ale můţeme změnit pouze jednu vlastnost v CSS souboru, který je přilinkován ke všem stránkám. Oddělení struktury a stylu. V jednom (HTML) dokumentu budeme mít pouze sémanticky označen obsah a v druhém (CSS) dokumentu máme definice vzhledu stránek. Tím dosáhneme snadnějšího strojového zpracování samotného obsahu stránek, do kterého se nám nepletou prvky definující vzhled. Cachování stylů webový prohlíţeč si můţe soubor se styly uloţit do cache paměti, čímţ můţe být dosaţeno zrychlení načtení stránky. CSS vlastnosti jednotlivých elementů můţeme dynamicky měnit pomocí Javascriptu 7. Z pomocí CSS můţeme jednoduše formátovat i jakýkoliv jazyk XML. Mohou také existovat různé styly pro různá výstupní zařízení. Jednoduše tak můţeme nadefinovat různý styl pro tisk, projekci, mobil, PDA. Běţný prohlíţeč či dokonce pro 5 vlastnost padding určuje šířku vnitřního okraje prvku. 6 vlastnost margin určuje šířku vnějšího okraje prvku. 7 Javascriptu je multiplatformní, objektově orientovaný skriptovací jazyk, který se zpravidla pouţívá jako interpretovaný programovací jazyk pro WWW stránky

22 kaţdý prohlíţeč jiný styl. Specifikace CSS nezapomínají ani na zrakově postiţené je moţno napsat styly pro hlasový syntetizátor nebo hmatovou čtečku Braillova písma CSS reset Jedním z problémů, se kterými se vývojář potýká při psaní webových stránek, je značná rozdílnost internetových prohlíţečů. V zásadě platí, co prohlíţeč - to jiná interpretace elementů. Například Internet Explorer má nastavený větší padding u samotného elementu body neţ Firefox nebo Opera. Dalším příkladem mohou být rozdílné okraje (margin) u odstavců. Výsledkem tedy je, ţe kaţdý prohlíţeč nahlíţí na webovou stránku jinak a logicky ji i bude zobrazovat odlišně. Řešením je všechny známé elementy, které se chovají různě v prohlíţečích, resetovat na společné hodnoty. Například vynulovat border, margin nebo padding. Na internetu se dají najít volně ke staţení osvědčené a uţivateli vyzkoušené CSS resety. Údajně nejpouţívanější je CSS reset od Erica Meyerse, jehoţ aktuální verzi lze nalézt na adrese Obrázek č.5 Ukázka CSS reset kódu

23 3.1 Charakteristika projektovaného systému Cílem projektu je vytvoření webového systému, který usnadní uţivatelům editaci webových stránek. V našem případě bereme uţivatele jako osobu, která nemá ţádné nebo minimální zkušenosti s psaním webových stránek. Proto musí být navrhovaný systém co nejjednodušší a uţivatelsky přívětivý a přehledný. Systém musí umět vytvářet články a umisťovat je to jednotlivých rubrik, vést databázi autorů, kteří budou mít moţnost vkládat a editovat jednotlivé články, umoţnit čtenářům jednotlivé články okomentovat a ohodnotit. Dále musí umoţnit šéfredaktorovi schválení jednotlivých článků před samotným zobrazením na stránkách. Správce stránek by pak měl mít mimo jiné i moţnost mazání nevhodných či vulgárních komentářů. Backend systému bude zabezpečovat SQL databáze. Redakční systém musí být obsluhován pomocí webového rozhraní a musí být konstruován pro bezproblémový provoz na jakémkoliv prohlíţeči. Specifikace požadavků na redakční systém Uţivatelé: Administrátor, šéfredaktor, redaktor, VIP uţivatel, standardní uţivatel. Specifika: Databáze rubrik, článků, redaktorů, čtenářů, komentářů, statistik hodnocení/návštěvnosti. 3.2 Návrh UML diagramů V této kapitole bych se chtěl věnovat návrhu systému v grafické podobě, tedy konkrétněji v podobě UML diagramů. Jazyk UML je v poslední době stále populárnější a to zejména díky tomu, ţe dává moţnost nahlédnout na navrhovaný systém pomocí diagramů s různou mírou podrobnosti. Tedy lze poměrně snadno začlenit zákazníka do vývoje systému i přesto, ţe nemá poţadované znalosti v oboru. Cílem je zaznamenat kompletní návrh či

24 kompletní realizaci. Při kreslení návrhu by měly být obsáhnuty všechny prvky tak, aby programátor byl schopen vytvořit program bez velkého přemýšlení nad věcnou oblastí (tedy pro programátora by neměla vzniknout potřeba konzultace s uživatelem). Při kreslení detailních návrhů můţeme pouţít specializované programy CASE (Computer-aided software engineering), které jsou schopny sdílet informace mezi jednotlivými modely a kontrolovat konzistenci návrhu. Pro tuto práci jsem zvolil nástroj SmartDraw od stejnojmenné firmy. Při výběru jsem se zaměřil na dobré recenze od kolegů a relativní dostupnost. Aplikace je volně ke staţení na stránkách výrobce v několika denním trial modu. Mezi přednosti aplikace patří fakt, ţe nabízí velké mnoţství ukázkových diagramů, které nezkušené uţivatele mohou snáze navézt. Nicméně po funkční stránce mě aplikace příliš nenadchla. Manipulace s jednotlivými objekty byla v některých situacích namáhavá a výsledný export diagramu obsahoval grafické chyby. SmartDraw mě tedy i přes počáteční nadšení zklamal a jelikoţ zbylé nástroje, které pro tuto práci pouţívám, jsou od firmy Microsoft, rozhodl jsem se vyuţít i její další produkt s názvem Visio Na stránkách výrobce se můţeme dočíst, ţe MS Visio 2007 je univerzální kreslicí nástroj pro libovolný typ technického diagramu nebo diagramu pro IT firmy. Pouţíváním aplikace Visio lze omezit nebo dokonce eliminovat potřebu dokoupit si pro konkrétní úkoly speciální grafický software. Tedy pro potřeby této práce by měl být tento produkt dostačující. Struktura samotného jazyka UML je dobře popsaná v diplomové práci Michala Beneše s názvem Přehled OO metodik a notací. Strukturu jazyka UML je moţné rozdělit do více vrstev. Nejniţší vrstvou je vrstva uţivatelských objektů. Obsahuje konkrétní instance (výskyty) jednotlivých konkrétních prvků (např. dané objekty), které jsou zachyceny v další vrstvě. Druhou vrstvou je modelová vrstva, která obsahuje konkrétní prvky modelované oblasti (např. konkrétní třídy). Třetí vrstva definuje jazyk pro specifikaci modelu (např. co jsou třídy a asociace). Nazývá se metamodelová vrstva. Poslední, čtvrtá vrstva (metametamodelová) definuje, co patří do metamodelu. Tato vrstva tedy určuje, co (jaké obecné prvky) do daného modelu patří (např. se jedná o třídu). Vrstvu metamodelu můţeme popsat pomocí tří balíčků, a to základ, prvky chování a správa modelu. Balíček základ se skládá z jádra, datových typů, mechanismů rozšíření a doplňkových prvků. Jádro definuje prvky potřebné pro sestavení modelu v UML

25 Kaţdá z definovaných poloţek je buď abstraktní (nelze vytvořit její instanci), nebo konkrétní (lze vytvořit její instanci). Začněme tedy od začátku. Do systému bude přistupovat pět rolí se základními vlastnostmi: a) Uživatel přistupuje k základním datům (článkům) b) VIP Uživatel po registraci získá moţnost komentovat jednotlivé články a přístup do neveřejných sekcí c) Redaktor moţnost vytváření a editaci nových článků a okomentování článků d) Šéfredaktor schvaluje články od redaktorů, moţnost vymazání komentářů e) Administrátor můţe přistupovat do všech sekcí a editovat je, nicméně nemá pravomoc schvalovat jednotlivé články Na základě těchto informací jsem vytvořil usecase diagramy (popisy chování z hlediska uţivatele), které jsou snadno srozumitelné i pro laika. 8 8 Do usecase modelu nebyli zahnuty tyto role: Administrátor, redaktor a šéfredaktor

26 Obrázek č.6 Usecase model pouţití systému pro uţivatele a VIP uţivatele. Popis k jednotlivým usecase: Registrace do systému: Slouţí k zaregistrování nového zákazníka do systému. Zákazník otevře úvodní stránku webového portálu, klikne na odkaz Registrace nového uţivatele. Systém zobrazí stránku registrace, kde uţivatel vyplní základní údaje jako je přihlašovací jméno, heslo, a zabezpečující otázku v případě ztráty či zapomenutého hesla. Po úspěšném zaregistrování bude uţivateli zaslán informační mail a systém zobrazí stránku s přihlášením do systému. Přihlášení do systému: Slouţí k přihlášení registrovaného zákazníka do systému. Pro úspěšné přihlášení do systému je úspěšné splnění poţadavků předchozí registrace

27 Zákazník otevře úvodní stránku webového portálu, Poté je uţivatel přesměrován do VIP sekce a zároveň je mu umoţněna moţnost okomentování jednotlivých článků. V opačném případě je nutno opakovat scénář. Úprava údajů: Slouţí k úpravě či doplnění údajů uţivatele. Vstupní podmínkou je přihlášení do systému. Uţivatel klikne na odkaz Změna údajů a je automaticky přesměrován na stránku s moţnostmi úpravy údajů uţivatele. Uţivatel provede příslušné změny a vyplní heslo v poli Původní heslo. V případě byla-li součástí úprav změna hesla, zde je nutno uvést původní heslo. Pak uţivatel stiskne tlačítko Potvrdit změny. Systém zobrazí informativní stránku o výsledku úpravy. Výstupem je, ţe údaje jsou úspěšně změněny. Odhlášení ze systému: Slouţí k odhlášení uţivatele. Vstupní podmínkou je přihlášení do systému. Uţivatel klikne na odkaz Odhlásit. Systém provede odhlášení uţivatele a zobrazí úvodní stránku s informací o odhlášení ze systému. Komentáře: Dovoluje vytvoření komentářů k jednotlivým článkům. Podmínkou je přihlášení uţivatele do systému. Uţivatel si klikne na poţadovaný článek, který se mu zobrazí v úvodním okně a po najetí na konec článku uvidí moţnost přidání komentáře. Tato moţnost je pro neregistrované uţivatele blokována. Výstupem je pak zobrazený komentář umístněný pod článkem. Komentáře jsou řazeny dle data od nejnovějšího. RSS: Umoţňuje uţivateli být informován o nových článcích, změnách webu, či jiných informacích prostřednictvím kanálu RSS. Vstupní podmínkou je úspěšné přihlášení do systému. Moţnost zapnutí či vypnutí RSS kanálu uţivatel nastaví ve vlastním nastavení svého účtu. Odkaz na vlastní nastavení nalezne po přihlášení do systému. Neveřejné sekce: V neveřejných sekcích můţe mít registrovaný uţivatel přístup například do fotogalerií, k nezveřejněným článkům nebo ke kontaktním údajům jednotlivých redaktorů. Také získá moţnost odesláním svého vlastního článku ke zveřejnění. To ovšem podléhá schválení šéfredaktora

28 Vytvoření článku: Umoţňuje roli redaktora vkládat články do jednotlivých sekcí. Podmínkou je úspěšné přihlášení do systému. Role redaktora je přiřazována administrátorem webu nebo šéfredaktorem. Článek po vloţení čeká na schválení šéfredaktorem před zveřejněním. Tím se zamezí vkládáním neautorizovaného textu. Schválení článku: Umoţňuje roli šéfredaktora schvalování článků vloţných redaktory. Šéfredaktor v tomto bodě také můţe stanovit datum a čas zveřejnění. Podmínkou je úspěšné přihlášení do systému. Role redaktora je přiřazována pouze administrátorem webu. Communication diagram neboli komunikační diagram zobrazuje datový tok mezi objekty v objektově orientované aplikaci a zároveň aplikuje základní asociace mezi jednotlivými třídami. Obdélníky jsou značeny pouţité objekty, ze kterých se skládá samotná aplikace a linky mezi nimi znázorňují asociace, závislosti, nebo dědičnosti. Komunikační diagram pouţívá pro třídy stejné označení jak sekvenční diagram. Obrázek č.7 Communication diagram Přihlášení do systému

29 Diagram činností (activity diagram) znázorňuje postupný průběh činností v systému. Vzniká na základě stavového diagramu, který dále rozšíří. Činnosti znázorňujeme jako obdélníky se zaoblenými rohy. Po dokončení kaţdé činnosti následuje automatický přechod na další činnost, coţ je znázorněno šipkou. Začátek a konec diagramu činností je znázorněn podobně jako u stavového diagramu pomocí krouţků. Občas je ovšem nutné rozhodnout, jaká činnost se bude vykonávat na základě určitých podmínek a tím dochází k takzvanému větvení diagramu. Nastalá situace se obvykle znázorňuje dvěma způsoby. Buď vychází moţné cesty přímo z některé činnosti, nebo se větvení znázorní pomocí malého kosočtverce (viz obrázek č.xxx), ze kterého pak větvené šipky vychází. Podmínky se pak uvádějí u větví (šipek) v hranatých závorkách. Obrázek č.8 Aktivity diagram Práce s daty

30 4.1 Vývoj samotné aplikace V této kapitole bych se chtěl zaměřit na jednotlivé části, z kterých se skládá navrhovaný redakční systém. Jak uţ jsem v předchozí kapitole, rozhodl jsem se vyuţívat nástrojů a technologií dodávaných firmou Microsoft. Konkrétně se jedná o: IIS Internet Information Service MS SQL Express 2005 MS Visual Studio 2008.NET Framework Pro 2007 MS Visio (pouţit pro návrh UML diagramů) ASP.NET MS Visual Basic 4.2 Rozvržení databáze V dnešní době se málokterá webová aplikace obejde bez databáze. Ať uţ v ní uchovává registrované uţivatele, informace o nabízeném zboţí, komentáře, či záznamy o návštěvnosti. Tento redakční systém nebude výjimkou. Pro náš systém potřebujeme uchovávat údaje rubrik, článků, redaktorů, čtenářů, komentářů, statistik hodnocení/návštěvnosti. Například tabulka pro udrţování informací o autorech bude obsahovat jméno a příjmení autora, jeho , heslo pro přístup do redakčního systému a poznámky o autorovi

31 Tuto tabulku lze vytvořit například zadáním SQL příkázu: CREATE TABLE [dbo].[redaction_autori] ( [ID_Autor] [int] IDENTITY (1, 1) NOT NULL, [Jmeno] [nchar] (10) COLLATE Czech_CI_AS NULL, [Prijmeni] [nchar] (50) COLLATE Czech_CI_AS NULL, [ ] [nchar] (50) COLLATE Czech_CI_AS NULL, [Poznamka] [nchar] (300) COLLATE Czech_CI_AS NULL ) ON [PRIMARY] Tabulky lze také vytvářet prostřednictvím programu MS SQL Server Management Studio Express, jak znázorňuje následující obrázek. Obrázek č.9 příklad vytvořené tabulky pomocí aplikace SQL server Management Studio Express

32 Podobným způsobem vytvoříme i další tabulky, které jsou důleţité pro náš redakční systém. Po vytvoření jednotlivých tabulek musíme tabulky ještě vhodně indexovat. Pokud bychom indexaci neprovedli, výkon celé aplikace bude značně omezený. Tabulku je vhodné indexovat alespoň podle unikátního klíče a podle poloţek pouţívaných ke třídění nebo ke spojování s dalšími tabulkami. Kromě poloţek "identity", které jsou jako primární klíče v kaţdé tabulce, je vhodné indexovat poloţky Datum_vydani,ID_autor,ID_rubrika Jednotlivé tabulky budou mezi sebou logicky svázané a společnými silami budou poskytovat informace nutné pro provoz redakčního systému. Na následujícím obrázku je vidět předběţné rozvrţení databáze. Obrázek č.10 Předběţné rozvrţení databáze

33 4.2.1 Membership DB Abychom mohli pouţití autentifikaci za pouţití forms společně s SqlMembership providerem musíme nejprve mít databázi, která bude obsahovat informace o uţivateli stejně tak jako informace o členství. Poté budeme moct autentizovat uţivatele a poskytnout přístup zaloţený na členství ve specifických rolích. Abychom zjednodušili aplikaci co nejvíce, nebudeme vytvářet novou DB, ale pouţijeme jiţ stávající s CMS.dtb, kterou jsme uloţili do appdata adresáře. Především potřebujeme vytvořit schéma neboli layout, které bude obsahovat informace od členství uţivatele. Naštěstí Microsoft nám ke splnění tohoto úkolu poskytuje jednoduchý nástroj pod názvem - aspnet_regsql.exe. Tento nástroj lze nalézt v: C:\WINDOWS\Microsoft.NET\Framework\v \aspnet_regsql.exe Podmínkou pro pouţívání tohoto nástroje je nainstalovaný.net framework. Nástroj lze také spustit z příkazové řádky, kde mu můţeme nastavit různé parametry. To se můţe hodit například při vytváření skriptů. Pokud spustíme aspnet_regsql.exe bez parametrů zobrazí se nám jednoduché GUI menu, které se nás nejprve zeptá, zda chceme nakonfigurovat existující databázi, aby obsahovala data o členstvích uţivatelů, či jestli chceme odebrat tyto data z jiţ existující DB. Poté zvolíme úloţiště databáze a také vybereme moţnost přihlášení se k ní. Je moţné se autentifkovat proti účtu ve Windows nebo oproti SQL serveru. Pokud bychom chtěli pouţít ke stejnému kroku příkazový řádek, náš příkaz by vypadal nějak takto:

34 Obrázek č.11 Ukázka tvorby membership databáze za pouţití příkazové řádky Dalším krokem by bylo nastavení konfigurace aplikace v souboru web.config, nicméně tuto část proberu podrobněji v některé z nadcházejících kapitol. 4.3 CSS Jestli má konečný produkt obstát v široké konkurenční nabídce na webu, musí si získat své zájemce nejen jednoduchým a intuitivním ovládáním, ale také vizuální přívětivostí. Statistiky říkají, ţe pokud uţivatele nezaujme webová stránka v prvních třech sekundách, odchází jinam. Technologie CSS nám v tomhle nabízí velice kvalitní moţnosti jak vdechnout webové presentaci ţivot. Pro základní rozvrţení stránek jsem pouţil techniku zvanou CSS Grid 940. Základem je tedy, jak název můţe napovídat, mříţka o celkovém rozměru 940 bodů. V CSS souboru si

35 nadefinuji jednotlivé rozměry mezi danými sloupci mříţky, stejně jako šířku jednotlivých sloupců. Tyto sloupce pak slouţí jako oddělovače jednotlivých částí, ve kterých se nalézá samostatný obsah stránky. Viz. Následující obrázek. Z důvodu lepší čitelnosti kódu jsem byl nucen oříznout pravou část screenshotu, tedy pokud by byl kód doslovně přepsán, nebude funkční. Nicméně pro nastínění jak prvek menu pouţití gridů je ukázka postačující. Následné začlenění do stránky

36 - 36 -

37 A výsledek co vidí uţivatel ve svém prohlíţeči. Obrázek č.11 Ukázka pouţití CSS stylů

38 4.4 Master page Aby výsledný produkt vypadal, co nejlépe musíme zajistit sjednocený design, tedy jednotný vzhled kaţdé stránky, na kterou je uţivatel odkázán. Místo překopírování jiţ napsaného kódu do kaţdé stránky zvlášť nám ASP.NET dovoluje kód napsat jen jednou a zbylý obsah elegantně a dynamicky vkládat z jiných souborů. Vytvoříme tedy jakousi šablonu, která bude obsahovat prvky jako hlavička, menu nebo patička a jen určíme v této šabloně místo, kam budeme vkládat dynamicky měnící se obsah v závislosti na poţadavku klienta. Toto nám dovoluje stránka nazvaná Master Page, která se od normální ASP.NET stránky liší direktivou: 9 namísto stránky druhé která na master page odkazuje: Master page je tedy obyčejná ASP.NET stránka, jenom místo direktivy Page začíná direktivou Master, má příponu master a je potomkem třídy MasterPage. Master page se volí pomocí parametru MasterPageFile v direktivě Page. Dále je zde moţné zadat titulek stránky (z tohoto důvodu má master page u tagu head uvedeno runat="server"). Stránky, které pouţívají master pages obsahují všechny ovládací prvky v prvcích asp:content a z nich jsou ovládací prvky vkládány při renderování do master stránek. 9 Languge VB znamená ţe aplikace bude psaná v jazyce Visual Basic

39 4.5 Menu Kaţdá webová aplikace by měla uţivateli umoţnit přehlednou navigaci mezi jednotlivými stránkami. Obvykle je tato navigace zprostředkována pomocí prvků, jako je menu, mapa stránky a další. V nové verzi obsahuje ASP.NET také několik základních ovládacích prvků, které umí prezentovat strukturu stránek uţivateli. Zmiňované ovládací prvky pracují s obecnou strukturou stránky, takţe kdokoli můţe vytvořit objekt, který bude tato data načítat a předávat ovládacím prvkům. Tvorba navigace pro stránku je tak rozdělena do dvou částí. První část načítá strukturu a druhá je tvořena ovládacími prvky, které strukturu prezentují. V současné verzi obsahuje ASP.NET objekt pro načítání struktury stránky z XML souboru (XmlSiteMapProvider). Pokud pouţijeme výchozí nastavení, bude se načítat soubor Web.sitemap v kořenovém adresáři aplikace, ve kterém je strukturovaně uloţena mapa stránky. U kaţdé stránky se ukládá odkaz, titulek a popis stránky (jediný povinný atribut je adresa stránky). Ovládací prvek SiteMapPath pak slouţí k zobrazování cesty od hlavní stránky aplikace aţ k aktuálnímu dokumentu. Po pouhém přidání tohoto ovládacího prvku na stránku bude prvek fungovat, protoţe si všechna potřebná data (včetně aktuální stránky) můţe získat z mapy stránek. Ovládací prvek je samozřejmě šablonovatelný, takţe lze jeho podobu výrazně ovlivnit. Další ovládací prvek, který je přímo určen pro navigaci na stránkách (a který jsem pouţil i já), je ovládací prvek Menu. Jak je ze jména patrné, tento prvek umoţňuje z dat dodaných z mapy stránek generovat menu. Navíc lze Menu pouţít i samostatně, v takovém případě se struktura píše přímo do kódu stránky (respektive uvnitř tagu Items v samotném ovládacím prvku). Zde se poloţky menu vkládají pomocí tagu asp:menuitem, ve kterém lze nastavit text poloţky, zobrazovanou ikonu a odkaz (pokud není uveden v poloţce odkaz, provede se po kliknutí na poloţku menu postback a kliknutí lze zpracovat jako serverovou událost)

40 Obr.xxx. Ukázka menu 10 V ukázce můţeme vidět i pouţití stylů, které dodají menu přívětivější a přehlednější vzhled. V přiloţeném obrázku můţete vidět výsledek, který se zobrazí uţivateli. Obrázek č12 Ukázka menu které se zobrazí uţivateli v prohlíţeči. 10 Z důvodu lepší čitelnosti kódu jsem byl nucen oříznout pravou část screenshotu, tedy pokud by byl kód doslovně přepsán, nebude funkční. Nicméně pro nastínění jak prvek menu v ASP.NET funguje je ukázka postačující

41 4.6 WYSIWYG - FCKEditor Základem kaţdého redakčního systému je textový editor, jenţ dovolí uţivateli vkládat naformátovaný text do webových stránek. Jelikoţ vypisování HTML tagů před kaţdé slovo, které chceme ztučnit, nebo psát jiným fontem, by bylo příliš zdlouhavé a neefektivní, rozhodl jsem se pouţít jeden z mnoha editorů, který základní práci s textem umoţňuje a který zároveň generuje validní HTML kód pouţitelný ve výsledném systému. Tyto editory se nazývají WYSIWYG coţ je akronym anglické věty What you see is what you get, česky co vidíš, to dostaneš. Tato zkratka označuje způsob editace dokumentů v počítači, při kterém je verze zobrazená na obrazovce vzhledově totoţná s výslednou verzí dokumentu. Nejčastěji se jako WYSIWYG označují některé textové procesory, ve kterých se editovaný text zobrazuje tak, jak bude vytištěn na papír. Kvůli obtíţnosti tohoto úkolu dochází ovšem často k drobným chybám, kdy uţivatel nedostane, co vidí. Příkladem editorů pracujících v reţimu WYSIWYG je např. Microsoft Word, nebo WYSIWYG editory WWW stránek. Ty ovšem sebou nesou jistá úskalí jelikoţ, přidávají do kódu spousty značek, které jsou zbytečné a které akorát zvětšují samotnou velikost stránek, coţ má negativní vliv například na rychlost načítaní. MS Visual studio také nabízí WYSIWYG editor. Ve vývojářském okně aplikace lze překliknout do okna design viz obr.xxxx kde by měla být vidět stránka tak jak se zobrazí v běţném prohlíţeči. Obrázek č.13 Moţnost volby WYSIWYG editoru v aplikaci MS Visual Studio Nicméně finální verze stránky je poměrně vzdálená od té, kterou vidí uţivatel ve svém prohlíţeči. Osobně jsem design mode pouţíval spíše pro rychlé nadefinování vzhledu tabulek, které jsem si později upravil dle svého estetického cítění

42 Jelikoţ vytvoření vlastního textového editoru by přesáhlo rámec této diplomové práce, rozhodnul jsem se pouţít volně dostupný FCKEditor jenţ nabízí jednoduché prostředí připomínající vzhled (v tomto případě) staršího Wordu nebo jakéhokoli textového editoru. Na výběr jsou k dispozici i novější design v podobě zakulacených rámečků či vydmutým efektem, nicméně jsem dal přednost klasickému jednoduchému designu starého MS Wordu. Aktuální verze funguje ve všech běţně pouţívaných webových prohlíţečích. Podporuje formátování pomocí CSS, jeho výstup je validní XHTML, dovede automaticky zjistit vkládání textu z Wordu (nebo jiného richtext editoru), obsahuje správce souborů pro snadný výběr obrázků a jiného vkládaného obsahu. Dovede pracovat s tabulkami, formuláři atd. Editor také nabízí českou lokalizaci, bez které by byl pro tento projekt nepouţitelný. Samotné začlenění editoru do projektu je jednoduché. Soubory stačí stáhnout na adrese a rozbalené soubory vloţit do sloţky s projektem. Viz obr. Editor pak na samostatné stránce (v našem případě insert.aspx ) zaregistrujeme přidáním direktivy: A poté jiţ stačí vloţit samotný editor

43 V uvedeném příkladu zobrazíme text, který je jiţ obsaţen v první kategorii tabulky content a následně jej i pomocí FCKEditoru pozměníme a uloţíme zpět do databáze. Aby editor věděl kam správně ukládat data, musíme mu nejrve pomocí SQL příkazů určit správnou cestu. V ukázce jsem pouţil jednoduché příkazy SELECT a UPDATE. Jak názvy napovídají, SELECT vybírá data z databáze, umoţňuje výběr podmnoţiny a řazení dat.a UPDATE mění data v databázi. Uţivateli se následně vygeneruje tato stránka

44 Obrázek č.14 Ukázka FCKeditoru, který se zobrazí uţivateli

45 4.7 Web.config Stránka by se ovšem nikdy nezobrazila správně, pokud bych nenastavil connection string v konfiguračním souboru samotného projektu, který je logicky pojmenován web.config. Soubory.config jsou zaloţeny na formátu XML. To v důsledku znamená, ţe při tvorbě těchto souborů musíte dodrţovat všechna pravidla pro tvorbu XML souborů. Projekt můţe obsahovat teoreticky nekonečné mnoţství těchto konfiguračních souborů, nicméně kaţdý soubor můţe obsahovat pouze jeden konfigurační soubor. Konfigurační model v ASP.NET je zaloţen na dědičnosti nastavení. Jiţ jsem řekl, ţe soubor web.config můţe být v kaţdém adresáři (nejvýše však jednou). Dědičnost nastavení v praxi znamená, ţe nastavení definovaná v souboru web.config jsou platná pro objekty aplikace v daném adresáři a jeho podadresářích. Co je důleţité je, ţe soubor musí být tzv. well-formed tedy špatné uzavírací tagy, malá nebo velká písmena mohou vyústit v chybové hlášení. Celá konfigurace aplikace se pak nachází mezi tagy a. Jak uţ název sekce napovídá, konkrétní nastavení aplikace se provádí právě v této sekci. Do této sekce umisťujeme datové poloţky aplikace, především však řetězce, které pouţíváme v rámci celé aplikace a pak také řetězec, který určuje spojení s databází, tedy jiţ výše zmíněný ConnectionString. V tomto projektu je nadefinován takto: 11 Výhodou nastavení connection stringu v souboru web.config je snadnější úprava i větší bezpečnost aplikace. Změním li databázi nebo jen její heslo, nemusím pak opravovat 11 Ukázka connection stringu odkazuje na databázi umístěnou na mém počítači. Po nasazení na hostingový server se hodnoty změní

46 připojení k této databázi v kaţdé stránce aplikace, ale stačí jen poupravit parametry v souboru web.config. Díky tomu, ţe na jednotlivých stránkách odkazuji pouze na údaj, sniţuji tím zároveň moţnost odhalení úloţiště dat. Sekce slouţí k nastavení autentizace (resp. autorizace) ASP.NET aplikací. Rozdíl mezi autentizací a autorizací spočívá v tom, ţe autentizace definuje, jakým způsobem má být uţivatel přihlášen, zatímco autorizace je rozhodnutí aplikace, má-li být uţivateli povolen přístup či nikoli. Například banka nejprve provede autentizaci (tedy ověří totoţnost) a na základě toho autorizuje (tedy oprávní uţivatele) manipulovat s kontem. Můţe ale například dojit k tomu, ţe proběhne autentizace, ale nikoliv autorizace, protoţe je konto zablokované. ASP.NET pouţívá 4 různé mechanizmy autentizace. Tyto mechanizmy popisuje Ondřej Kopp na adrese None Windows Passport Forms - Standardní nastavení. Nedochází k ţádné autentizaci a veškeré dotazy jsou prováděny buď v kontextu lokálního systémového procesu nebo v kontextu účtu - Veškerá autentizace je prováděna přímo v IIS a ASP.NET ji nijak neovlivňuje. Uţivatel zadává jméno a heslo do standardního okna Windows. IIS podporuje základní typy autentizace Anonymous, Basic, NTLM. Po úspěšné autentizaci se přístup k informacím provádí v kontextu autentizovaného uţivatele. Protoţe při tomto způsobu autentizace musí mít uţivatel účet buď na serveru nebo v doméně, není tento způsob vhodný pro rozsáhlá řešení na internetu. Své uplatnění najde zejména v intranetových řešeních ve firmách, kde je pouţíváno doménové prostředí firmy Microsoft. - ASP.NET při tomto způsobu autentizace předává řízení centrální sluţbě MS Passport, která zajistí ověření identity uţivatele. Údaje o uţivateli jsou uloţeny na centrálním serveru u firmy Microsoft. - Jde o reţim, který si můţe vývojář upravit k obrazu svému. Při ověřování identity uţivatele se nemusíme omezovat pouze na uţivatele

47 definované v doméně či na serveru, ale můţeme provádět ověřování vůči seznamu uţivatelů v souboru web.config. Reţim autentizace Form tímto vývojáři uvolňuje ruce a je jen na něm, vůči jaké databázi či jakému dalšímu zdroji dat provede ověření uţivatele. Tuto metodu jsem zvolil i pro navrhovaný redakční systém. To, který z mechanizmů bude pouţit, záleţí právě na nastavení v souboru web.config. V přiloţeném kódu můţeme vidět nastavení, které jsem provedl pro navrhovaný systém. I kdyţ struktura jazyka dává tušit význam jednotlivých parametrů, rád bych vysvětlil funkčnost některých z hlavních parametrů. Parametr loginurl určuje adresu, na kterou bude uţivatel přesměrován v případě, ţe není přihlášen (neexistuje autentizační cookie). V případě tohoto systému bude uţivatel přesměrován na login stránku, kde se bude moct přihlásit, případně zaregistrovat. Parametr name určuje jméno autentizačního cookie, pokud je tento parametr vynechán, je pouţito implicitní jméno.aspxauth. Pokud běţí na jednom serveru více web aplikací, je nutné v souboru web.config zajistit, aby pouţitá jména byla unikátní

48 Parametr DefaultProvider určuje, který provider bude poskytovat data. V našem případě jsme nadefinovali databázi uţivatelů do jiţ existující databáze s články, autory, apod. Další vcelku pouţívanou sekcí je <customerrors />, kde se definují vlastní chybová hlášení. Během vývoje aplikace je dobré nastavit atribut mode na Off, abyste viděli podrobné chybové hlášení, je-li aplikace hotova, měli byste atribut nastavit na On, abyste uţivatele nezatěţovali dlouhými chybovými hlášeními nebo neprozrazovali části kódu záškodníkům. Další moţností atributu mode je RemoteOnly. RemoteOnly se chová stejně jako Off, je-li ke stránce přistupováno z jiného místa, neţ ze serveru, který stránku hostuje. Je-li ke stránce přistupováno přímo z hostujícího serveru, zobrazí se kompletní chybové hlášení. K tagu <customerrors /> můţeme přidat ještě atribut defaultredirect, který specifikuje cestu k vaší vlastní stránce s chybovým hlášením. V sekci <customerrors /> můţeme také měnit chybová hlášení http (např. 403 access denied nebo 404 page not found). 4.8 Login ASP.NET obsahuje velice dobře vymyšlený model správy uţivatelských účtů a oprávnění, který se skládá ze tří částí. Tyto části zajišťují všechny běţné pouţívané potřeby a funkce, které bychom mohli potřebovat. První částí je Membership. Tato část se stará o samotné uţivatelské účty, jména a hesla, jejich vytváření, změny a mazání. Stará se tedy o identifikaci a autentizaci uţivatelů (zjištění, kdo uţivatel je, a ověření, jestli je to skutečně on)

49 Druhou částí jsou Roles, tedy role. Kaţdého uţivatele z Membershipu můţeme přiřadit do několika různých rolí, podle nichţ pak provádíme autorizaci (rozhodujeme, co uţivatel můţe a nemůţe udělat). Kaţdý uţivatel můţe být ve více rolích a kaţdá role můţe obsahovat víc uţivatelů. Třetí částí jsou Profiles. O kaţdém uţivateli si můţeme pamatovat mnoho různých dalších údajů (jméno, příjmení, adresu, telefon, ale např. i nastavení a přizpůsobení webu jeho poţadavkům, případně u e-shopů např. nákupní košík apod.). Aplikace MS Visual Studio také obsahuje velice povedený nástroj pro správu uţivatelů a rolí viz obrázek. Obrázek č.15 Ukázka moţností nástroje pro správu webu

50 4.9 ADO.NET - Active Data Objects for.net Co se práce s daty týče, máme v.netu velké mnoţství moţností. Pokud pomineme čisté řešení za pomocí ADO.NET, úplným základem je pak jednoduchá DAL (Data Access Layer) vrstva vytvořená pomocí DataSetu. DataSet nám uchová data z databáze formou silně typovaných objektů a umoţňuje objektovou práci s relačními daty na nejniţší úrovni. V našem případě nám DAL poslouţí jako abstraktní zdroj dat. To nám v budoucnu mimo jiné umoţňuje změnit zdroj dat (Oracle nebo MySQL databáze) s minimálním úsilím. DAL nám také dovoluje přistupovat k databázi s větším zabezpečením, jelikoţ aktuální stránka doopravdy nemá s databází kontakt. Dataset můţeme vytvořit pomocí aplikace MS Visual studio, kde můţeme najít průvodce, jenţ nás navede ke vloţení poţadovaných údajů. Nejprve vytvoříme nový Dataset soubor a uloţíme jej do sloţky App_Code. Jak ukazuje přiloţený obrázek. Poté se nám zobrazí tzv. Dataset designer, kde si nadefinujeme nový TableAdapter, vybereme připojení k naší databázi a zvolíme poţadované SQL dotazy. V tomto příkladu pouţijme adaptér pro tabulku s články tedy Articles. Pouţijeme následující dotaz

51 Poté rozklikneme nabídku s rozšířenými moţnostmi a vybereme Generate Insert, Update a Delete dotazy. Pokud dokončíme průvodce správně, měl by se nám zobrazit výsledek podobný tomuto: Obrázek č.16 Ukázka komponenty dataset Tím jsme vytvořili Dataset, který jsme připojili k tabulce Articles s korespondujícím ArticelsTable adaptérem, který obsahuje metody Fill a GetData. Nyní přidáme do stránky komponentu GridView společně se scriptem Page_load Z důvodu lepší čitelnosti kódu jsem byl nucen oříznout pravou část screenshotu, tedy pokud by byl kód doslovně přepsán nebude funkční. Nicméně pro nastínění jak prvek menu v ASP.NET funguje, je ukázka postačující

52 Uţivateli se pak v prohlíţeči zobrazí výsledek podobný tomuto: Obrázek č.17 Výsledný export článků, který se zobrazí uţivateli. Toto ovšem není jediný způsob jak připojit články z naší databáze do samotné aplikace. Jak jiţ bylo řečeno ASP.NET nám nabízí nejednu moţnost jak zobrazit data. V následujícím příkladu jsem pouţil komponentu repeater, u něhoţ jsem pomocí SQL dotazů a connection stringu docíli podobné funkčnosti jako v předchozím příkladu

53 Podobným postupem můţeme vytvořit například diskusní fórum, které se bude nacházet pod kaţdým z článků a do kterého budou moct přispívat pouze registrovaní uţivatelé

54 5.0 SEO Search Engine Optimalization Search Engine Optimalization neboli SEO se v dnešní době stává často diskutovaným tématem. Pokud náš web nenaleznou uţivatelé na síti, byly veškeré finanční prostředky vynaloţené k vytvoření toho webu zbytečné. V zásadě existují dva typy vyhledavačů, a to katalogové a fulltextové. 5.1 Katalogové vyhledavače U katalogových se stránka přidává registrací a většinou se čeká nějakou dobu, neţ je stránka editorem schválena. V Čechách se jedná například o Seznam, Centrum, Atlas. Ze zahraničí jsou to pak DMOZ nebo Yahoo. Optimalizace pro tuto skupinu vyhledávačů je docela jednoduchá. V podstatě záleţí jenom na třech věcech titulku, popisu a klíčových slovech (ta nejsou vţdy vyţadována). O to důleţitější je jejich řádná příprava. Katalogový vyhledávač totiţ při hledání prochází jenom tyto tři údaje. Některé katalogy uţ ale začínají zkoumat také obsah stránek, například editoři DMOZu ručně procházejí zadané stránky a přidávají jenom některé. 5.2 Fulltextové vyhledavače Fulltextový vyhledávač má svého robota, který prochází všechny stránky na internetu a přidává si je do indexu. To znamená, ţe kdyţ na vaši stránku nevede ţádný odkaz, tak ji robot (většinou) nenajde. Většina fulltextových vyhledávačů obsahuje příkaz "Přidat stránku", který by měl urychlit indexaci. U nás jsou nejvýznamnější Jyxo a Morfeo, v zahraniční pak nejlepší a nejkvalitnější fulltext vůbec Google. Optimalizace webu pro Google je mnohem sloţitější neţ u předchozí kategorie, ale vzhledem k tomu, ţe většina uţivatelů na internetu (Česko je v tomto výjimkou) pouţívá Google,vyplatí se do řádné optimalizace investovat. Princip vyhledávání, jenţ pouţívá Google, je vhodně popsán v článku Petra Weiss s názvem SEO Search Engine Optimalization a je k nalezení na webové stránce

55 Google pouţívá robota, který se jmenuje Googlebot. Ten prochází internet a pomocí odkazů se dostává na další a další stránky. A pokud narazí na novou nebo změněnou stránku, tak si ji uloţí. K hodnocení stránek pouţívá svoji vlastní technologii PageRank, která je ovlivněna více neţ stem faktorů. Kaţdá jednotlivá stránka má svůj vlastní PageRank (PR). Jeho přesný výpočet není znám a Google ho pro větší objektivitu často mění. V kostce záleţí na počtu stránek, které na vás odkazují, na velikosti jejich PR a počtu odkazů, které obsahují. Čím více zpětných odkazů, tím, samozřejmě, lépe. Pokud hodně kvalitních (s vysokým PR) webů odkazuje na určitou stránku, tak to pro Google znamená, ţe i ona stránka bude pravděpodobně něčím zajímavá. Kaţdý měsíc pak probíhá na Google velká aktualizace databáze, zvaná Google Dance. V tuto dobu můţete na svůj dotaz dostat kaţdých pět minut jiný výsledek záleţí to na tom, kterému serveru byl dotaz poloţen. Page rating našich stránek můţeme zvýšit přidáváním zajímavého obsahu, na nějţ budou ostatní rádi odkazovat. Nekomerční projekty mají v tomto do jisté míry zjednodušenou situaci, jelikoţ vzájemné odkazování probíhá o hodně jednodušeji. U komerčních projektů je důleţitá důkladná registrace do většiny katalogů, nejlépe ruční. Dobrým způsobem je na komerčních stránkách psát také nekomerční obsah. Například webdesignerská firma uvolní část svého know-how a na svých stránkách bude vydávat CSS příručku, tím zvýší svoji popularitu, PR svého webu a bude mít větší mnoţství zakázek. Existují také placené sluţby, jeţ za určitý poplatek budou na stránku odkazovat. To je ovšem proti základní myšlence PR a proto, se Google snaţí proti tomuto bojovat. Například vloţením stránky, kterou tuto sluţbu vyuţívá na tzv. black list. 5.3 SEO v praxi Nadpisy H1-H5: Obecně platí, ţe na kaţdou jednotlivou stránku by měla být pouţita jedna H1, ale nikdy jsem se nesetkal s tím, ţe by byl velký problém s pouţitím více H1. Důleţité je řazení nadpisů od H1 po H3 sestupně a nikoliv na přeskáčku

56 zdroj: Obsah webu ve správném pořadí: 1. hlavička webu (nadpis H1) 2. textový obsah 3. menu 4. ostatní prvky jako odkazy, formuláře, ankety loginy 5. flashové presentace Struktura URL adresy: Adresy pro SEO by měly být tvořeny jasně a přehledně s pouţitím klíčových slov, která jsou vhodná pro danou stránku. zdroj: Klíčová slova: Vyhledávače se mimo jiné zaměřuji i na přiměřenost klíčových slov. Pokud jich bude na stránce mnoho, vyhledavače stránku penalizují a vyhodnotí ji jako spam. Pokud, ale bude klíčových slov na stránce pro změnu málo, na stránku nebude brán velký zřetel, a tedy se sníţí i šance takto stránku

57 nalézt. Obecně platí, ţe počet klíčových slov by měl být na stránce v počtu přibliţně 3-6%. Text by měl být psán přirozeně a bez obratů, které se v běţném ţivotě moc nepouţívají. Zpětné odkazy: Mezi nejvýhodnější odkazy patří takzvané jednosměrné zpětné odkazy, tedy odkazy, které míří na naše stránky a nikoliv my na ně. Mezi způsoby získání těchto jednosměrných odkazů patří registrace do jiţ zmíněných katalogů. V zásadě platí, čím více jednosměrných zpětných odkazů, tím lépe, ale musíme si dát pozor na rychlý nárůst. Rychlý nástup můţe být pro vyhledávače podezřelý a mohou stránku automaticky zablokovat. Konkurence: Jako v kaţdém jiném odvětví i na internetu platí zákon sledování konkurence. SEO je nekončící proces a monitorováním nových trendů mnohdy získáme výhodu know-how a tím i lepší postavení na trhu. Robots.txt: Robots.txt je jednoduchý textový soubor, umístěný v kořenovém adresáři, ve kterém jsou uloţeny pokyny, jakým způsobem má vyhledávač procházet web. Přesný popis moţných příkazů se dá nalézt na adrese Ke kontrole správnosti zápisu pak můţe poslouţit některý z mnoha robot.txt validátorů dostupných na síti

58 6.0 Bezpečnost V následující kapitole bych se chtěl zaměřit na zabezpečení webových aplikací. V poslední době se všeobecně mnoţí útoky na webové aplikace, či útoky s vyuţitím webových aplikací. Obvykle jsou umoţněny nedostatečně bezpečnou prací uţivatelů s hostingovými sluţbami nebo nedostatečnou bezpečností jejich aplikací. Z toho vyplívají i moţnosti útoků, kterými jsou změna webové prezentace a zneuţití hostingových sluţeb. Změnou webové prezentace můţe být změna obsahu stránek, nebo přidání nějakého kódu do stránek (obvykle s vyuţitím javascriptu, nebo HTML tagu iframe). Tento kód se pak do počítače návštěvníka stránek snaţí stáhnout nějaký škodlivý program (vir, trojan, malware, apod. To se ovšem týká víceméně jenom uţivatelů operačních systémů z rodiny Microsoft). Běţné antivirové štíty či podobný bezpečnostní software by si s touto hrozbou měl poradit, nicméně ne všichni uţivatelé jsou dostatečně zodpovědní a bezpečnostní software pouţívají, nebo jej udrţují aktuální. Umístění takového kódu můţe mít ovšem přímý vliv i na doménové jméno - doména můţe být například ve vyhledávačích či prohlíţečích označena za nedůvěryhodnou, nebo dokonce můţe být registrátorem trvale suspendována. Dalším moţným útokem je zneuţití hostingových sluţeb díky tomu, ţe k nim má útočník přístup (SQL Injection). Zde se jedná například o rozesílání spamu, útoky na vzdálené sluţby (TCP flood), umístění škodlivého obsahu (např. phishingových stránek), nebo pokusy o narušení vnitřní bezpečnosti serveru. V tomto případě můţe být ohroţena vnitřní bezpečnost serveru, stabilita a plynulost sluţeb a neposlední řadě riziko zneuţití informací o uţivatelích. V následující podkapitole bych uvést pár příkladů jak zabezpečit náš navrhovaný systém a tím předejít moţným budoucím problémům. 6.1 SQL injection Databáze je srdcem mnoha webových aplikací jelikoţ se v ní ukládají data potřebná pro bezchybné fungování aplikace (autentizace uţivatelů) a samotný obsah webových stránek. Mohou obsahovat uţivatelské osobní údaje a citlivé finanční informace. Jsou zde skladovány

59 data z účetnictví, platby nebo inventurní data. A proto vy mělo být zabezpečení databáze základní prioritou. Jednou z nejpouţívanějších metod vniknutí do DB je takzvaný SQL injection. V podstatě se jedná o techniku napadení databázové vrstvy programu vsunutím (injection) kódu přes neošetřený vstup a vykonání vlastního, samozřejmě pozměněného, SQL dotazu. Toto nechtěné chování vzniká při propojení aplikační vrstvy s databázovou vrstvou (téměř vţdy se totiţ jedná o dva různé programy) a zabraňuje se mu pomocí jednoduchého escapování 13 potencionálně nebezpečných znaků. Příkladem SQL injection je například místo, kde vstup do formuláře obsahuje neočekávanou sadu znaků. Předpokládejme, ţe máme SQL příkaz, který přijal název produktu jako vstup a hledal ji v tabulce products naší databáze. SQL dotaz můţe vypadat například takto: Kdyţ uţivatel zadá proměnou Chair výsledný dotaz můţe vypadat takto: Databáze nám oproti tomuto příkazu vrátí všechny záznamy v tabulce Product, které obsahují hodnotu chair Ale co kdyţ uţivatel zadá hodnotu podobné této: Výsledný SQL dotaz pak bude vypadat takto: 13 Escapování je způsob kódování řetězcových literálů. V programovacích, skriptovacích, dotazovacích a dalších jazycích se řetězcové literály uvádějí většinou ve dvojitých, někdy téţ jednoduchých uvozovkách (aby se oddělily od ostatních lexikálních elementů jazyka). Pokud však uvozovky jsou samy o sobě součástí takového řetězce, syntaktický analyzátor by nedokázal rozlišit, kdy jde o uvozovku v řetězci a kdy o ukončení tohoto řetězce. Pro tento důvod existují tzv. escape sekvence

60 Tento dotaz bude vyhodnocen, aby vybral jakýkoliv záznam výrobku se jménem chair nebo kde x rovná x. A jelikoţ výrok x = x je pravdivý bude klausule WHERE vyhodnocena jako pravda. Parametr DROP TABLE pak neudělá nic jiného, neţ ţe vymaţe tabulku s výrobky. Poslední dotaz je přítomen pouze proto, aby byl výsledný SQL dotaz validní. Tímto způsobem můţeme přijít o veškeré data z naší databáze Bezpečnostní opatření Hlavní principy zabezpečení databáze je ošetření všech vstupních parametrů aplikace, které jakkoliv mohou ovlivnit podobu či obsah SQL příkazů. Můţe se jednat o konverzi, filtraci, parametrizaci apod. Nejlepším moţným řešením by mělo být pouţívání objektového programování. Tím bychom se vyhnuli vytváření SQL příkazů skládáním z několika částí doplněných parametry. Pouţíváním parametrizace pak všechny předávané hodnoty důsledně převáděli na konkrétní a správné datové typy. Jednoduché shrnutí základních praktik shrnuje Daniel Dočekal ve svém článku Na podceňovanou hrozbu SQL injection doplácí i řada českých webů, který je dostupný z Pokud je vstupem do webové aplikace text, který se má dostat do SQL příkazu, jedním ze základních ochranných kroků je záměna všech ['] (apostrof) za [''] (dvojice apostrofů). V lepším případě je ještě navíc vhodné pouţít regulární výrazy (regexp) a případně zamezit tomu, aby se do případného textu mohlo dostat cokoliv jiného, neţ povolené znaky (např. do PSČ opravdu patří jenom číslice a mezera). Pokud jde o netextové vstupy, tak je poměrně jasné, ţe čísla je více neţ vhodné nechat převést na čísla pomocí odpovídající konverzní funkce (např. int() nebo něco podobného) a vstupy s pevně daným výčtem (něco jako True/False, 0/1, on/off) prostě napevno testovat na správnou hodnotu. A nespoléhat se vůbec na nic

61 Webová aplikace by navíc rozhodně neměla nikdy zobrazovat ţádné detailní chybové hlášky. Nezamezí se tím sice SQL injection, ale alespoň se hodně znepříjemní případným pokušitelům jejich snahy. "SQL injection naslepo" není zrovna nejzábavnější. Přímo uvnitř SQL serveru bychom navíc měli zajistit, aby pro práci s SQL daty byly případně důsledně pouţívány uloţené procedury (Stored Procedures) a účet, pod kterým k SQL přistupuje webová aplikace, měl minimální práva (potřebná práva mohou mít uloţené procedury). 6.2 Skript injection Tento typ útoku není tak nebezpečný jako výše popisovaný SQL injection, nicméně dokáţe znepříjemnit ţivot jak mnoha webovým vývojářům, tak samotným uţivatelům přistupující k naší webové aplikaci. Pokud nejsme zabezpečení proti skript injection, stačí do diskusního fóra napsat následující příkaz: Návštěvník tohoto diskusního fóra pak bude automaticky přesměrován na stránky Nejjednodušším způsobem jak tomuto zabránit pouţít metodu HtmlEncode, tedy převod speciálních znaků na HTML entity. Znak < se tedy převede na < a znak > na >. Prohlíţeč tedy vědět, ţe to nejsou HTML značky, a vypíše je jako text. ASP.NET je ovšem proti těmto útokům připraveno a snaţí se webové aplikace chránit. Pokud vloţíme do fóra příspěvek uvedený v předchozím odstavci, prohlíţeč vypíše výjimku podobné této

62 Pokud ovšem chceme povolit HTML znaky, musíme kontrolu vypnout, a to přímo v direktivě Page. (prvního řádku ve stránce parametr ValidateRequest="false"). Tím se kontrola vypne a poţadavek se provede s tím, co uţivatel poslal