Na tomto míst bude ociální zadání va²í práce

Na tomto míst¥ bude ociální zadání va²í práce •

Toto zadání je podepsané d¥kanem a vedoucím katedry,

•

musíte si ho vyzvednout na studiijním odd¥lení Katedry po£íta£· na Karlov¥ nám¥stí,

•

v jedné odevzdané práci bude originál tohoto zadání (originál z·stává po obhajob¥ na kated°e),

•

ve druhé bude na stejném míst¥ neov¥°ená kopie tohoto dokumentu (tato se vám vrátí po obhajob¥).

i

ii

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Bakalá°ská práce

Softwarová podpora provozu poskytovatele internetu

Zuzana Vejraºková

Vedoucí práce:

Mgr. Jan Stoklasa

Studijní program: Softwarové technologie a management, Bakalá°ský

Obor: Softwarové inºenýrství

25. kv¥tna 2010

iv

v

Pod¥kování Ráda bych pod¥kovala v²em svým blízkým za podporu p°i psaní této práce, zejména svým rodi£·m za podporu p°i studiu a vedoucímu práce Mgr.Janu Stoklasovi za cenné p°ipomínky, rady a trp¥livost. Za spolupráci p°i °e²ení poºadavk· na systém bych cht¥la pod¥kovat administrátor·m rmy, pro kterou je systém vytvo°en.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

V Praze dne 25. 5. 2010

.............................................................

viii

Abstract This bachelor thesis deals with the analysis of requirements for a system for provider of web services like hosting, its design and own implementation. Result is information system for controlling the user accounts, server services and settings of provided services. The work contains both the user control panel and the administrator control panel, including solution of access privileges based on role based system. The nal system is supposed to be a basic utilizable version, with wide options for upgrades. Adding the solution for server part, which will automatize performing requests, it is planned in future.

Abstrakt Tato bakalá°ská práce se zabývá analýzou poºadavk· na systém pro podporu provozu poskytování internetových sluºeb (hostingu), návrhem a jeho vlastní implementací. Výsledkem je informa£ní systém slouºící pro správu uºivatelských ú£t·, sluºeb serveru a nastavení sluºeb uºivatel·. V práci je °e²eno uºivatelské i administrátorské rozhraní, v£etn¥ °ízení oprávn¥ní na základ¥ administrátorských rolí. Výsledný informa£ní systém má slouºit jako základní pouºitelná verze s ²irokými moºnostmi roz²i°ování a po£ítá se do budoucna s p°idáním °e²ení serverové £ásti pro automatizaci vykonávání poºadavk·.

ix

x

Obsah 1 Úvod

1

1.1

1

Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Popis problému, specikace cíle

3

2.1

Vymezení projektu

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Popis webhostingu a poskytovaných sluºeb . . . . . . . . . . . . . . . . . . . .

3

2.2.1

Webhosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2.2

Mailhosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2.3

Databáze

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2.4

FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2.5

Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3 Specikace poºadavk·

7

3.1

Denice pojm·

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2

Katalog poºadavk· na systém . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2.1

Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2.2

Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

3.4

3.5

Seznam aktér·

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 10

3.3.1

Neregistrovaný uºivatel (RandomUser) . . . . . . . . . . . . . . . . . .

10

3.3.2

Registrovaný uºivatel (RegisteredUser) . . . . . . . . . . . . . . . . . .

10

3.3.3

Administrátor (Administrator)

. . . . . . . . . . . . . . . . . . . . . .

11

3.3.4

Hlavní Administrátor (SuperAdministrator) . . . . . . . . . . . . . . .

11

3.3.5

Systém (Automat)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.3.6

Systém oprávn¥ní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

ásti systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.4.1

Uºivatelské osobní údaje a registrace . . . . . . . . . . . . . . . . . . .

11

3.4.2

Administrátorské osobní údaje a role . . . . . . . . . . . . . . . . . . .

12

3.4.3

Tarify a sluºby

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.4

Webové domény

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.5

Mailové domény

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.6

Databáze

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.4.7

Cron pravidla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.4.8

Dotazy a odpov¥di . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Seznam p°ípad· uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

xi

OBSAH

xii

4 Analýza a návrh 4.1

15

4.1.1

Správa tarif· a sluºeb

15

4.1.2

Správa zam¥stnanc· a oprávn¥ní

. . . . . . . . . . . . . . . . . . . . .

15

4.1.3

Správa zákazník· a registrace uºivatel· . . . . . . . . . . . . . . . . . .

16

4.1.4

4.2

4.3

15

Funk£nosti systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Vykonávání poºadavk· na zm¥ny . . . . . . . . . . . . . . . . . . . . .

18

4.1.4.1

Zp·sob ukládání a °e²ení poºadavk· na zm¥ny

19

4.1.4.2

P°idání sluºby

. . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.1.4.3

Zru²ení sluºby

. . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.1.4.4

Editace nastavení sluºby

. . . . . . . . . . . . . . . . . . . .

20

4.1.4.5

Zobrazování nastavení sluºeb . . . . . . . . . . . . . . . . . .

21

Architektura systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.2.1

Pouºité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.2.2

Interakce jednotlivých £ástí systému

. . . . . . . . . . . . . . . . . . .

25

4.2.3

Komponenty a struktura systému . . . . . . . . . . . . . . . . . . . . .

27

4.2.4

Modularita a roz²i°itelnost systému . . . . . . . . . . . . . . . . . . . .

27

Zabezpe£ení systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

. . . . . . . .

5 Realizace 5.1

5.2

29

Adresá°ová struktura a kongurovatelnost

. . . . . . . . . . . . . . . . . . . .

29

5.1.1

Adresá°ová struktura programu . . . . . . . . . . . . . . . . . . . . . .

29

5.1.2

Kongurovatelnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

Administrátorské rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.2.1

30

Role a zabezpe£ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1.1

Kontrola rolí p°i b¥hu programu

. . . . . . . . . . . . . . . .

31

5.2.1.2

Role a operace p°ipravené p°i instalaci . . . . . . . . . . . . .

32

5.2.1.3

P°idávání dal²ích rolí

. . . . . . . . . . . . . . . . . . . . . .

32

5.2.2

P°epnutí do role zákazníka . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.2.3

Uºivatelské rozhraní

34

5.2.3.1 5.2.4

5.2.5

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Kontrola operací a tarifu

. . . . . . . . . . . . . . . . . . . .

34

Vykonávání poºadavk· na serveru

. . . . . . . . . . . . . . . . . . . .

35

5.2.4.1

Fronta poºadavk·

. . . . . . . . . . . . . . . . . . . . . . . .

35

5.2.4.2

Vykonávání poºadavk· robot . . . . . . . . . . . . . . . . .

37

5.2.4.3

Synchronizace vykonávání poºadavk·

38

5.2.4.4

Zaji²t¥ní konzistence dat

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

38

Zabezpe£ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.2.5.1

Kontrola vstup· od uºivatele . . . . . . . . . . . . . . . . . .

38

5.2.5.2

SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.2.5.3

Ukládání hesel

39

. . . . . . . . . . . . . . . . . . . . . . . . . .

6 Testování

41

6.1

Obecné testování

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2

Testování pomocí nástroje Selenium

6.3

Testování na uºivatelích

41

. . . . . . . . . . . . . . . . . . . . . . .

41

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

OBSAH

xiii

7 Záv¥r

43

7.1

Zhodnocení

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

7.2

Budoucnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

Literatura

45

A Seznam pouºitých zkratek

47

B Funk£ní poºadavky a p°ípady uºití

49

B.1

Detailní funk£ní poºadavky

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

B.2

Diagramy p°ípad· uºití (Use Case) . . . . . . . . . . . . . . . . . . . . . . . .

51

C Analytické t°ídy

53

D Databáze - uloºení dat

55

E Obsah p°oloºeného CD

59

xiv

OBSAH

Seznam obrázk· 3.1

Základní p°ípady uºití systému podle £ástí systému . . . . . . . . . . . . . . .

9

3.2

Seznam aktér· - uºivatelé systému

4.1

Registrace - sekven£ní diagram

4.2

Settings - diagram aktivit

4.3

Proces nastavení sluºeb - sekven£ní diagram . . . . . . . . . . . . . . . . . . .

23

4.4

Stav poºadavk· v procesu nastavení sluºeb - stavový diagram . . . . . . . . .

24

4.5

Komponenty systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

5.1

Uloºení dat - Zam¥stnanec a role

31

5.2

Formulá° - p°idání role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.3

Uloºení dat - Fronta

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.4

Proces vykonávání poºadavk· na serveru . . . . . . . . . . . . . . . . . . . . .

37

C.1

Analytické t°ídy - £ást 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

C.2

Analytické t°ídy - £ást 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

D.1

Uloºení dat - £ást 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

D.2

Uloºení dat - £ást 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

. . . . . . . . . . . . . . . . . . . . . . . .

10

. . . . . . . . . . . . . . . . . . . . . . . . . .

17

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

. . . . . . . . . . . . . . . . . . . . . . . . .

xv

xvi

SEZNAM OBRÁZK

Seznam tabulek 3.1

Seznam p°ípad· uºití podle £ástí systému

xvii

. . . . . . . . . . . . . . . . . . . .

14

xviii

SEZNAM TABULEK

Kapitola 1

Úvod Tato bakalá°ská práce se zabývá problematikou webhostingu, návrhem a implementací informa£ního systému pro podporu jeho správy. Hlavním cílem projektu je vytvo°it takový informa£ní systém, který usnadní správu webhostingu administrátor·m a zp°íjemní vyºívání sluºeb i zákazník·m. V sou£asné dob¥ rma provozuje server a nabízí základní hostingové sluºby pro oby£ejné uºivatele a rmy. Detailní seznam poskytovaných sluºeb je popsán ve druhé kapitole. Server je spravován jedním administrátorem, který musí °e²it v²echny poºadavky. V sou£asné dob¥ je na serveru hostovaných jiº cca 150 domén druhého °ádu a mnoho domén t°etího °ádu. Server i v²echny poskytované sluºby jsou profesionáln¥ zabezpe£eny, ale nejv¥t²ím nedostatkem pro stávající klienty je nemoºnost spravovat a prohlíºet nastavení vlastního ú£tu p°es uºivatelsky p°ív¥tivé rozhraní. Hlavní p°ekáºkou pro zvý²ení po£tu domén je nemoºnost objednat si hostingové sluºby online na webových stránkách, coº zp·sobí, ºe noví potencionální zákazníci rad¥ji zvolí hosting konkurence, kde mají jednodu²²í zaloºení i následnou správu hostingu. Jako °e²ení se jeví vytvo°ení takového informa£ní systému, který by tyto dva zmín¥né nedostatky °e²il. Výsledkem projektu by m¥la být zejména v¥t²í spokojenost stávajících uºivatel· a p°ípadn¥ p°iliv nových klient·. To, ºe je webhosting provozován bez jakéhokoli podp·rného informa£ního systému znamená, ºe v²echny poºadavky zákazník· (zm¥ny nastavení sluºeb, p°idání sluºby apod.) jsou °e²eny ru£n¥ administrátorem serveru. Zákazníci poºadavek na zm¥nu nastavení sluºby komunikují administrátorovi prost°ednictvím e-mailu, pop°ípad¥ telefonu. Tento zp·sob je velice nepohodlný pro ob¥ strany. Pro administrátora proto, ºe kaºdý poºadavek musí nastavovat a °e²it zvlá²´, coº zabírá hodn¥ £asu, a je zde i v¥t²í riziko, ºe zp·sobí nepozorností chybu. Také nemá moºnost prohlíºet jednodu²e souhrnné údaje a nastavení sluºeb jednotlivých zákazník·. Pro zákazníky je tento zp·sob £asto velice frustrující z toho d·vodu, ºe sami nem·ºou prohlíºet nastavení svých sluºeb a ani toto nastavení m¥nit. Nep°íjemností je pro n¥ i n¥kdy dlouhé £ekání na provedení zm¥n, které pot°ebují.

1.1 Struktura práce Jednotlivé £ásti systému se zdánliv¥ prolínají, coº je pro usnadn¥ní práce se systémem pro uºivatele. (Nap°. zaloºení webu a FTP probíhá v jednom kroku, a£koli se z pohledu serveru

1

KAPITOLA 1. ÚVOD

2

jedná o dv¥ rozdílné sluºby.) Text práce je uspo°ádán chronologicky, podle jednotlivých fází projektu. V kapitole 2 najdete úvodní studii s vymezením práce a detaily o provozovaných sluºbách. Kapitola 3 se v¥nuje sb¥ru poºadavk· na vyvíjenou aplikaci a detailnímu popisu provozovaných sluºeb. Kapitola 4 obsahuje analýzu a návrh systému - návrh uloºení dat, architekturu systému a popis sloºit¥j²ích proces· probíhajících v systému. Kapitola 5 popisuje realizaci sloºit¥j²ích £ástí systému, kapitola 6 shrnuje výsledky testování a zhodnocení celé práce najdete v záv¥ru, v kapitole 7. V p°íloze práce najdete detailní popis n¥kterých £ástí sysému, nap°. detailní seznam poºadavk·, analytické t°ídy, UML diagramy a dal²í specikace. Na p°ílohy se budeme odkazovat postupn¥ z textu práce. Obsahem p°iloºeného CD je vlastní program, skripty pot°ebné k nasazení programu, programátorská dokumentace a dal²í diagramy a specikace, které nejsou obsaºeny v p°ílohách textu. Webové rozhraní je moºné vyzkou²et na

http://test-hosting.mujserver.org/.

Kapitola 2

Popis problému, specikace cíle 2.1 Vymezení projektu Informa£ní systém by m¥l pokrývat n¥kolik kategorií. Za prvé by m¥l slouºit pro správu tarif· a sluºeb (moºnost výb¥ru tarif· pro zákazníka) a osobních údaj· zákazník· (oby£ejné údaje o adrese, p°ihla²ovací údaje do informa£ního systému atd.) Dále by m¥l uchovávat ve²keré nastavení v²ech poskytovaných sluºeb, od webové domény, p°es e-mailové domény, e-mailové ú£ty, aliasy k doménám, databáze, hesla do databáze, na FTP, k e-mailovým ú£t·m atd. Ve²keré nastavení by m¥lo být p°ístupné zákazník·m, kte°í by m¥li mít moºnost ho i editovat. Zárove¬ je pot°eba v rámci projektu navrhnout zp·sob provád¥ní poºadavk· skute£né nastavování sluºeb na serveru. To bude provád¥no skripty spou²t¥nými na serveru, jejichº tvorba jiº sou£ástí této práce nebude. Sou£ástí bude je²t¥ jednoduchý systém pro vkládání dotaz· registrovaným i neregistrovaným uºivatel·m a moºnost administrátor· na dotazy odpovídat. Správa plateb a reprezenta£ní webová prezentace, zobrazující v²echny tarify a nabídky hostingu, sou£ástí této práce jiº nebude. Systém by m¥l být vhodn¥ zabezpe£ený. Administrátorské a uºivatelské rozhraní informa£ního systému by m¥ly být odd¥leny. Dále je pot°eba kontrolovat vstupy z formulá°· a syntaktickou správnost (nap°. p°i zadávání domény, e-mailové adresy atd).

2.2 Popis webhostingu a poskytovaných sluºeb Tato podkapitola obsahuje stru£ný popis jednotlivých poskytovaných sluºeb.

2.2.1 Webhosting Jedná se o poskytování prostoru pro jednotlivé domény. Parametry, které je moºné nastavit, jsou popsány níºe. Velikost poskytovaného prostoru je sou£ástí tarifu. Popis parametr· a sluºeb:

po£et domén

jedná se o maximální po£et domén druhého a vy²²ího °ádu obsluho-

vaných na serveru

3

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

4

po£et alias·

maximální celkový po£et alias· ke v²em obsluhovaným doménám

prostor na disku

po£ítá se celkový prostor pro v²echny domény, nezapo£ítává se

velikost databáze nebo mailboxu

m¥sí£ní p°enos dat

jedná se o limit p°enesených dat, který je v cen¥ tarifu, vy-

po£ítává se z logu na serveru

po£et ftp ú£t·

k jedné domén¥ je v¥t²inou pot°eba jeden FTP ú£et, ale uºivatel

bude mít moºnost vytvo°it si dal²í FTP ú£et pro p°ístup do podadresá°e

po£et databází v¥t²ina dynamických web· pot°ebuje mít ke svému b¥hu databázi, zde má uºivatel moºnost pouºít ºádnou nebo jednu a více MySQL databází

prostor pro databázi jde o poskytovaný prostor pro databázi, tento prostor zahrnuje indexy, strukturu i data

php umoº¬uje uºivateli vytvá°et dynamický web, pomocí skriptovacího jazyka PHP webalizer

umoº¬uje uºivateli sledovat náv²t¥vnost svých stránek na základ¥ zpra-

cování logu webového serveru

po£et SSL (certikát)

uºivatel m·ºe vyºadovat v¥t²í zabezpe£ení p°enosu dat ze

svých stránek, a pro správnou funk£nost je pot°eba mít pro kaºdou stránku IP adresu, po£et SSL tedy znamená po£et pronajatých IP adres

po£et pravidel v tabulce Cron

dynamický web m·ºe vyºadovat ke svému b¥hu

pravidelné spou²t¥ní akcí, v na²em p°ípad¥ se pro spou²t¥ní vyuºívá sluºeb Cronu, po£et pravidel odpovídá po£tu °ádk· v crontabu

WinSCP

pro náro£n¥j²í uºivatele se nabízí i ²ifrovaný p°enos dat na server, tato

sluºba ho umoº¬uje

htaccess mod_rewrite a omezení p°ístupu je nabízeno v²em uºivatel·m automaticky

2.2.2 Mailhosting Jedná se o samostatnou sluºbu pro zaji²t¥ní b¥hu mailových schránek pro danou doménu. Zde mailhosting automaticky poskytuje kontrolu na p°ítomnost vir· a ltrování spamu. U sluºby rozli²ujeme po£et mailbox· a velikost vyuºitého prostoru. Popis parametr· a sluºeb:

po£et mailových schránek

jedná se o po£et mailbox·, po£ítá se dohromady p°es

v²echny domény, nezapo£ítávají se aliasy, do celkového po£tu se po£ítá i mailbox postmater

po£et domén jedná se o maximální po£et obsluhovaných domén mail serverem po£et alias· k doménám

jedná se o celkový maximální po£et alias· k doménám

po£et alias· k mailbox·m jedná se o celkový maximální po£et alias· k mailbox·m

2.2. POPIS WEBHOSTINGU A POSKYTOVANÝCH SLUEB

5

velikost prostoru jedná se o celkový vyuºitý prostor daným uºivatelem pro mailové sluºby, ve vyuºitém prostoru jsou zahrnuty nap°. i indexy k IMAPu

POP3

zákazník m·ºe ke svému p°ístupu k email·m vyuºívat protokol POP3

IMAP

zákazník m·ºe ke svému p°ístupu k email·m vyuºívat protokol IMAP,

protokol IMAP je náro£n¥j²í neº POP3, protoºe umoº¬uje vyhledávání ve zprávách, uloºených na serveru, a vytvá°ení sloºek pro zprávy

SMTP

poskytovány jsou i sluºby odesílání e-mail·, k tomuto ú£elu m·ºe uºivatel

pouºít zde spravovaných SMTP server· (namísto SMTP serveru svého poskytovatele)

2.2.3 Databáze Pro dynamické weby jako jsou nap°. e-shopy, diskusní fóra atd. pot°ebuje zákazník (programátor) ukládat nová data do svého webu, k £emuº vyuºije databázi. Zákazník má k dispozici po£et databází a DB uºivatel· dle svého tarifu. Podle toho je zákazníkovi poskytováno místo na disku, které zahrnuje strukturu, data i indexy. Parametry sluºby:

prostor na disku po£et uºivatel·

po£ítá se nad v²emi databázemi daného zákaznického ú£tu

po£et uºivatel· s právem p°ipojit se k n¥které z databází, u uºi-

vatel· rozli²ujeme práva pro pouze £tení, £tení a zápis nebo modikace struktury

po£et databází

jedná se o maximální po£et databází, které je moºné vytvo°it k

danému tarifu

zálohování na poºádání

zákazník pot°ebuje zálohovat svou databázi, ale kv·li

omezení maximální doby PHP skriptu se mu nemusí poda°it vytvo°it zálohu databáze p°es webové rozhraní, tato sluºba vytvo°í poºadavek na vytvo°ení zálohy databáze

2.2.4 FTP Zákazník, který si spravuje web sám, pot°ebuje mít p°ístup do ko°enového adresá°e webu, aby mohl nahrávat data nebo skripty. K tomu slouºí sluºba FTP. Zákazník navíc m·ºe mít více FTP ú£t·, nap°íklad pro své pod°ízené, s omezeným p°ístupem. Mezi parametry sluºby pat°í:

velikost dat na disku

po£ítá se v²e v základním adresá°i zákazníka rekurzivn¥,

velikost je omezena tarifem

po£et uºivatel·

jedná se o po£et uºivatel·, který je omezen dle tarifu

p°enesená data

objem p°enesených dat na server i ze serveru, omezeno dle tarifu

WinSCP

jedná se o zabezpe£ený (SSL) p°ístup do základního adresá°e FTP

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

6

2.2.5 Cron Jedná se o program spu²t¥ný na serveru, který zaji²úje pravidelné spou²t¥ní úloh. Zákazníkovi je umoºn¥no spou²t¥t nap°íklad program wget pro nastartování PHP skriptu na své domén¥. Zde se zatím nabízí pouze spou²t¥ní programu wget. U sluºby se ur£uje:

Po£et pravidel jedná se o celkový po£et pravidel v crontabu.

Kapitola 3

Specikace poºadavk· 3.1 Denice pojm· Následujících pár °ádku denuje dále pouºité pojmy a jejich p°esný význam v této práci.

webová doména

obsluha domény na serveru pouºívaná pro webové sluºby

mailová doména

obsluha domény na serveru pouºívaná pro mailové sluºby

Pozn. Jedna doména se v¥t²inou pouºívá pro oba typy sluºeb. Rozd¥lení zde je jen z d·vodu zvýrazn¥ní odli²nosti sluºeb a £ástí systému.

uºivatel systému

zde máme na mysli roli Registrovaný uºivatel, tedy zákazník,

který pouºívá informa£ní systém

administrátor

zde máme na mysli zam¥stnance, který má p°istup do adminis-

tra£ního rozhraní a m·ºe provád¥t n¥které z operací (dle role)

3.2 Katalog poºadavk· na systém 3.2.1 Funk£ní poºadavky Na základ¥ popisu systému v kapitole 2 byly vytvo°eny funk£ní poºadavky. Systém by m¥l podporovat:

•

moºnost registrace pro neregistrované uºivatele

•

vkládání dotaz· pro registrované i neregistrované uºivatele, prohlíºení odpov¥dí pro registrované uºivatele

•

administrátor·m umoº¬uje odpovídání na dotazy a správu v²ech dotaz·

•

administrátor·m i uºivatel·m umoº¬uje správu vlastních osobních údaj·

•

administrátor·m umoºní správu osobních údaj· uºivatel·

7

KAPITOLA 3. SPECIFIKACE POADAVK

8

•

správu vlastních webových domén pro uºivatele a v²ech webových domén pro administrátory

•

správu vlastních mailových domén pro uºivatele a v²ech mailových domén pro administrátory

•

správu vlastních databází a databázových ú£t· pro uºivatele a správu v²ech pro administrátory

•

správu vlastních pravidel tabulky cron pro uºivatele a správu v²ech pro administrátory

•

uºivatel·m umoº¬uje výb¥r vlastního tarifu a nastavení sluºeb

•

adminitráto°i mají moºnost spravovat v²echny tarify a sluºby

•

hlavnímu administrátorovi umoº¬uje p°idávání rolí a administrátor· do systému

3.2.2 Nefunk£ní poºadavky •

systém bude naprogramován v jazyce PHP

•

systém bude zaloºen na systému rolí, které budou p°id¥lovány administrátor·m

•

systém bude mít alespo¬ jednoho super-administrátora, který bude mít oprávn¥ní p°i°azovat role ostatním uºivatel·m

•

p°íkazy pro zm¥nu nastavení serveru/systému budou ukládány do fronty (nebudou spou²t¥ny ihned)

•

p°ístupové údaje/hesla budou zabezpe£eny ²ifrováním (nikoli hashem)

•

kaºdá tabulka bude obsahovat následující poloºky: £as vloºení záznamu (Created At)

•

kaºdá tabulka, kde má informace smysl, bude obsahovat i následující poloºky: id uºivatele který záznam do tabulky p°idal (Created By), datum/£as poslední editace (Last Edited At) a svislítkem odd¥lený seznam uºivatel·, kte°í poloºku editovali (History)

•

v systému se pokud moºno nebude provád¥t p°íkaz

DELETE

v databázi, ale vlastnost

smazáno (nap°. nastavení poloºky ValidTo a nebo p°idání p°íznaku ºe poloºka jiº není platná)

•

systém musí brát v úvahu, ºe fyzicky existuje více server·

Následující obrázek 3.1 znázor¬uje základní p°ípady uºití informa£ního systému, které odpovídají vý²e zmín¥ným poºadavk·m, podle jednotlivých £ástí systému.

3.2. KATALOG POADAVK NA SYSTÉM

9

uc UC-Main-2

Informacní systém Tarif a služby

Správa vlastního tarifu a služeb

Správa všech tarifu a služeb

Webové domény

Správa vlastních Webových domén a služeb

Správa všech Webových domén a služeb

Mailové domény

Správa vlastních Mailových domén a služeb

Správa všech Mailových domén a služeb

Správa vlastních Databází a DB úctu

Správa všech Databází a DB úctu

Databáze

RegisteredUser (from Actors)

Administrator (from Actors)

Cron pravidla

Správa vlastních pravidel Cronu

Správa všech pravidel Cronu

Uživatelské osobní údaje a registrace

Registrovat se

Správa uživatelských osobních údajù

Správa platnosti úètù Automat (from Actors)

Dotazy a odpovìdi

RandomUser

Vložit dotaz

Prohlížet vlastní dotazy a odpovedi

Správa všech dotazù a odpovìdí

(from Actors)

Administrátorské osobní údaje a role

Správa Administrátoru a Rolí

SuperAdministrator (from Actors)

Obrázek 3.1: Základní p°ípady uºití systému podle £ástí systému


10

3.3 Seznam aktér· Se systémem bude pracovat n¥kolik typ· uºivatel·. Tato podkapitola stru£n¥ charakterizuje jednotlivé typy uºivatel· (aktéry) a jakou roli v systému mají.

uc Actors

SystemUser

Automat

RegisteredUser

RandomUser

Administrator

SuperAdministrator

Obrázek 3.2: Seznam aktér· - uºivatelé systému

3.3.1 Neregistrovaný uºivatel (RandomUser) Jedná se o náhodného náv²t¥vníka webové stránky. Systém mu dovolí pouze prohlíºení obsahu stránek, kde není pot°ebné p°ihlá²ení. Má moºnost zaregistrovat se do systému, po úsp¥²né registraci získá p°ihla²ovací údaje a pat°í do skupiny Registrovaný uºivatel. Má moºnost p°es webový formulá° odeslat dotaz na administrátory systému (odpov¥¤ mu administrátor za²le na vypln¥nou e-mailovou adresu).

3.3.2 Registrovaný uºivatel (RegisteredUser) Jedná se o uºivatele, který má v systému jiº vytvo°ené p°ihla²ovací údaje a tedy vyuºívá n¥které ze sluºeb hostingu. Po p°ihlá²ení do informa£ního systému má p°ístup ke svým osobním údaj·m a nastavení tarifu, které m·ºe m¥nit. Má právo prohlíºet a editovat v²echno nastavení svých sluºeb (podle toho, co povoluje tarif ). Má moºnost vkládat dotazy na administrátora a po p°ihlá²ení prohlíºet stav dotaz· a odpov¥di.

3.4. ÁSTI SYSTÉMU

11

3.3.3 Administrátor (Administrator) Jedná se o uºivatele, který se stará o správu webhostingu. Po úsp¥²ném p°ihlá²ení do systému smí, podle role, kterou má p°id¥lenou, vykonávat ur£ité operace se systémem. Mezi tyto funkce pat°í zobrazování a editace informací o uºivatelích, o tarifech, moºnost odpovídat na dotazy, zobrazení a editace ve²kerého nastavení v²ech poskytovaných sluºeb (zobrazení nastavení pro jednotlivé uºivatele i celkových souhrn·).

3.3.4 Hlavní Administrátor (SuperAdministrator) Je abstraktní role, jedná se o typ administrátora. Rozdíl mezi Hlavním Administrátorem a

Administrátorem je pouze v tom, ºe Hlavní Administrátor má právo na v²echny operace. Jeho hlavním úkolem je p°i°azení práv v²em ostatním administrátor·m.

3.3.5 Systém (Automat) N¥které úlohy (nap°. r·zné kontroly nebo rozesílání e-mail· s upozorn¥ním) bude systém spou²t¥t automaticky v ur£ité £asy (dle nastavení v Cronu).

3.3.6 Systém oprávn¥ní Systém práv je zaji²t¥n p°es RBAC. Existuje seznam operací, které jsou seskupeny do r·zných rolí (kde kaºdá operace m·ºe pat°it i do více rolí). Kaºdému administrátorovi je potom p°i°azena jedna nebo více rolí, podle toho, na jaké operace má administrátor oprávn¥ní. Hlavní administrátor je pouze dal²í typ administrátora, který má právo na v²echny operace, tedy smí vytvá°et role a p°i°azovat je ostatním administrátor·m.

3.4 ásti systému Celý systém by se dal rozd¥lit na n¥kolik £ástí z n¥kolika r·zných pohled·. Zde se budu zabývat rozd¥lením podle poºadavk· na systém, tedy podle p°ípad· uºití, jak znázor¬uje obrázek 3.1. Systém zaji²úje mnoho r·zných sluºeb, které m·ºeme jednodu²e rozd¥lit do následujících skupin:

3.4.1 Uºivatelské osobní údaje a registrace Tato £ást systému obstarává uºivatelské osobní údaje a s nimi spojené operace. Jedná se o registraci zaloºení uºivatelského ú£tu, zm¥nu osobních údaj· a zm¥nu hesla. Administráto°i mohou prohlíºet a editovat jednotlivé ú£ty a zobrazit ty, kterým brzy vypr²í platnost. Systém by mohl dále automaticky odesílat e-mail s upozorn¥ním t¥m uºivatel·m, kterým brzy vypr²í platnost uºivatelského ú£tu (dobu na kterou m¥li objednaný tarif ). Tuto £ást vyuºívají Administráto°i, Registrovaní uºivatelé, Neregistrovaní uºivatelé i Au-

tomat.


12

3.4.2 Administrátorské osobní údaje a role Tato £ást systému °e²í p°ihlá²ení a osobní údaje administrátor·. Je moºné administrátory p°idávat, editovat a p°edev²ím jim p°i°adit roli. Role je také moºné p°idat, upravit i smazat, a kaºdá role seskupuje operace, které smí administrátor s touto rolí vykonávat. Je moºné i zm¥nit heslo do informa£ního systému. Administrátorské rozhraní je odd¥lené od uºivatelského, a v p°ípad¥, ºe by administrátor cht¥l vyuºívat sluºby jako zákazník, musí mít dva odd¥lené ú£ty. Tuto £ást vyuºívají pouze Administráto°i a Hlavní Administrátor.

3.4.3 Tarify a sluºby Tato £ást systému °e²í tarify a nastavení sluºeb. Kaºdý zákazník má p°i°azený práv¥ jeden tarif, pop°ípad¥ roz²í°ený o dal²í sluºby, které m·ºe m¥nit. Administráto°i, krom¥ prohlíºení a editace tarif· zákazník·, obstarávají správu tarif· p°idání, editace, smazání (= ukon£ení platnosti) tarifu. P°i zm¥n¥ tarifu se ale zákazníkovi zachovává tarif, který vybral p°i zaloºení hostingového ú£tu. P°i zakládání jednotlivých sluºeb se pokaºdé kontroluje oproti nastavenému tarifu, zda si daný uºivatel smí danou sluºbu zaloºit, pop°ípad¥ se kontrolují povolené po£ty (nap°. po£et domén v rámci tarifu). Tuto £ást vyuºívají Administráto°i a Registrovaní uºivatelé.

3.4.4 Webové domény Jedná se správu webové domény a s tím v²ech spojených sluºeb. e²í se zde p°idání domény, vytvo°ení FTP ú£tu, zm¥na hesla na FTP ú£et, p°idání a mazání aliasu k webové domén¥. Dále p°ehledy v²ech domén a v²ech alias·. P°i vkládání první domény se automaticky vytvo°í FTP ú£et a p°ihla²ovací údaje se uºivateli ode²lou na e-mail. Aliasy jdou p°idávat aº k zaloºeným doménám. Tuto £ást vyuºívají Administráto°i a Registrovaní uºivatelé.

3.4.5 Mailové domény Tato £ást systému bude vyuºita t¥mi, kdo cht¥jí vyuºívat sluºeb mail serveru. Uºivatelé mohou p°idat mailovou doménu, p°idat k ní alias, p°idávat mailové schránky a aliasy ke schránkám. Dále mohou prohlíºet domény, schránky i aliasy. Alias jde p°idat aº po p°idání domény a nebo mailové schránky. Schránka jde p°idat pouze k domén¥ a nikoli k doménovému aliasu. Dále je moºné k mailovým schránkám p°idat pravidla pro p°eposílání e-mail·. P°i p°idání mailové domény se automaticky vytvo°í e-mailový ú£et postmaster, který má defaultn¥ nastaveno zachytávání po²ty odeslané na neexistující mailové schránky v rámci dané domény. Tuto £ást vyuºívají Administráto°i a Registrovaní uºivatelé.

3.4. ÁSTI SYSTÉMU

13

3.4.6 Databáze V této £ásti je moºné p°idávat i mazat databáze a databázové uºivatele, kte°í mohou mít r·zná oprávn¥ní. Je moºné zm¥nit heslo a i prohlíºet seznamy databází a uºivatel·. P°i p°idání první databáze se automaticky vytvo°í i první databázový ú£et a p°ihla²ovací údaje se ode²lou uºivateli na e-mail. Uºivatel by m¥l mít moºnost provést zálohu databáze (v omezeném po£tu za den). Tuto £ást vyuºívají Administráto°i a Registrovaní uºivatelé.

3.4.7 Cron pravidla Jednoduchá £ást systému umoº¬uje p°idávání pravidel do tabulky Cron. Pravidla je moºné zobrazit a smazat. Poºadavky na nové nastavení cron pravidel p°ípadn¥ mohou být zaslány na speciální email administrátora pro dodate£nou kontrolu £innosti zákazníka. Tuto £ást vyuºívají Administráto°i a Registrovaní uºivatelé.

3.4.8 Dotazy a odpov¥di Neregistrovaným uºivatel·m systém umoºní vloºit dotaz na administrátory. Odpov¥¤ se neregistrovanému uºivateli ode²le na vypln¥nou e-mailovou adresu. Registrovaní uºivatelé, pokud dotaz vloºí po p°ihlá²ení do systému, dostanou odpov¥¤ také na e-mail, ale zárove¬ mohou prohlíºet v²echny dotazy a odpov¥di k nim a vloºit i dopl¬ující dotaz. Administráto°i mají moºnost v²echny dotazy zobrazit a odpov¥d¥t na n¥. Tuto £ást vyuºívají Administráto°i, Registrovaní uºivatelé a Neregistrovaní uºivatelé.


14

3.5 Seznam p°ípad· uºití Následující tabulka 3.1 zobrazuje p°ípady uºití systému, rozd¥lené nikoli podle aktér· (uºivatel· systému), ale podle vý²e zmín¥ných sluºeb systému. Jedná se pouze o hrubé d¥lení, detailní seznam v²ech poºadavk· na systém se nachází v p°íloze B, detailní diagramy p°ípad· uºití (Use Case ) najdete v p°íloze na CD.

Uºivatelské osobní údaje a registrace

Zaregistrovat se Zobrazit / editovat / deaktivovat osobní údaje Zm¥na hesla Zobrazit brzy expirující uºivatelské ú£ty/ Odeslat e-mail

Administrátorské osobní údaje a role

P°epnout se do role konkrétního zákazníka Vloºit / smazat / zobrazit / editovat administrátora Vloºit / smazat / zobrazit / editovat roli Zobrazit operace Zm¥na hesla

Tarif a sluºby

Vloºit / smazat / zobrazit tarif Pouºít tarif (p°i°adit tarif k uºivateli) / Zru²it pouºití tarifu (deaktivovat)

Webové domény

Upravit tarif zákazníka Vloºit / smazat / zobrazit / editovat webovou doménu Vloºit / smazat / zobrazit alias k webové domén¥

Mailové domény

Zm¥na hesla na FTP Vloºit / smazat / zobrazit mailovou doménu Vloºit / smazat / zobrazit alias k mailové domén¥ Vloºit / smazat / zobrazit / editovat mailovou schránku (MailBox) Vloºit / smazat / zobrazit alias k mailové schránce Vloºit / smazat / zobrazit pravidlo pro p°eposílání po²ty

Databáze

Vloºit / smazat / zobrazit databázi Vloºit / smazat / zobrazit / editovat databázový ú£et Zm¥na hesla k databázovému ú£tu

Cron pravidla Dotazy a odpov¥di

Provést zálohu databáze Vloºit / smazat / zobrazit pravidlo tabulky Cron Vloºit dotaz / odpov¥¤ na dotaz Zobrazit dotazy / odpov¥di

Tabulka 3.1: Seznam p°ípad· uºití podle £ástí systému

Kapitola 4

Analýza a návrh 4.1 Funk£nosti systému Tato podkapitola má za úkol popsat d·leºité funk£nosti systému probíhající procesy v systému a navrhnout jejich °e²ení. Vychází z poºadavk·.

4.1.1 Správa tarif· a sluºeb Hosting poskytuje mnoho sluºeb, ale ne v²ichni uºivatelé je cht¥jí v²echny vyuºívat. P°irozen¥ tedy necht¥jí platit za sluºby, které nevyuºívají, a tak je pot°eba dát zákazník·m moºnost si zvolit jaké sluºby cht¥jí pouºívat, proto je pot°eba vytvo°it n¥kolik tarif·, ze kterých bude mít uºivatel na výb¥r. Na kaºdý tarif m·ºeme nahlíºet jako na mnoºinu poskytovaných sluºeb, kde u kaºdé sluºby bude nastaven parametr, který p°edstavuje bu¤to po£et (nap°. po£et domén), nebo velikost (nap°. velikost prostoru na disku), nebo p°íznak, zda uºivatel sluºbu vyuºívá £i nikoli (true / false). Tarify se mohou v budoucnu zm¥nit, ale zákazník·m musí vºdy z·stat takové podmínky, za kterých si tarif objednali. Dále by administrátor m¥l mít moºnost upravit tarif jednotlivým zákazník·m podle jejich poºadavk·. Aby byla spln¥na moºnost úpravy tarifu administrátorem, systém tarif· bude vy°e²en následovn¥: Kaºdý uºivatel si po registraci do systému zvolí jeden tarif, který chce vyuºívat. V databázi se neuloºí ID tarifu, který zvolil, ale p°ekopíruje se do zvlá²tní tabulky nastavení tarifu, který zvolil (tedy parametry tohoto tarifu). Tímto zp·sobem tedy kaºdý zákazník bude mít individuální tarif, který bude odvozený od n¥jakého z nabízených tarif·. Tento zp·sob °e²ení dává jednodu²e prostor pro individuální zm¥ny parametr· tarifu jednotlivým zákazník·m (tyto zm¥ny bude moci provád¥t pouze administrátor a krom¥ zm¥n v nastavení sluºeb bude moci m¥nit i cenu tarifu). Toto °e²ení spl¬uje i poºadavek, ºe p°i zm¥n¥ podmínek tarifu musí z·stat zákazníkovi takové podmínky a cena, p°i kterých tarif objednal.

4.1.2 Správa zam¥stnanc· a oprávn¥ní Krom¥ uchování osobních údaj· a p°ihla²ování pot°ebujeme v p°ípad¥ zam¥stnanc· rozli²it i r·zná oprávn¥ní, protoºe i kdyº v sou£asné dob¥ je jeden nebo dva spolehliví administráto°i,

15

KAPITOLA 4. ANALÝZA A NÁVRH

16

kte°í smí mít kompletní p°ístup ke v²emu, o£ekává se, ºe v budoucnu by se systémem pracovalo více zam¥stnanc·, kde ne v²ichni by mohli mít práva na v²echny funk£nosti systému. Nap°. sekretá°ka by nem¥la mít moºnost m¥nit nastavení sluºeb domén, mailových sluºeb, databáze, atd. ale pouze by sm¥la nahlíºet na osobní data uºivatel·. Jako °e²ení práv se nabízí systém RBAC (Role Based Access Control). Bude moºné vytvo°it role a zam¥stnanci potom p°i°adit jednu nebo více rolí. Kaºdá role bude obsahovat jistou mnoºinu operací. Administrátor tedy bude mít práva na operace podle p°id¥lených rolí. Vºdy p°ed vykonáním n¥jaké funkce se zkontroluje, zda daný zam¥stnanec má na provedení dané funkce oprávn¥ní. Administrátor (který na to bude mít právo) bude mít moºnost do systému p°idat roli a p°i°adit k ní operace. V²echny operace musí být do databáze vloºeny v rámci p°ípravy systému, SQL skript pro vloºení operací a vytvo°ení n¥kolika základních rolí (o které se jedná je popsáno v kapitole 5) je sou£ástí p°ílohy na CD.

4.1.3 Správa zákazník· a registrace uºivatel· Správa zákazník· je velice jednoduchá £ást systému, která se bude skládat pouze z tabulek v databázi, které ukládají osobní údaje o uºivatelích, které smí uºivatel po p°ihlá²ení editovat, a p°ihla²ovací údaje, které slouºí pro autentizaci uºivatele p°i p°ihla²ování. Dle poºadavk· v kapitole 3 musí systém umoºnit registraci novým uºivatel·m. Zde je detailní popis, jak proces registrace funguje. Aby se zamezilo vysokému po£tu registrací a vytvá°ení ú£t·, které by nikdy nebyly pouºité, proces registrace se skládá ze dvou krok·: vypln¥ním osobních údaj· a potvrzením registrace. V databázi budou t°i tabulky (v²e je znázorn¥no v realizaci, kapitola 5). Jedna tabulka ukládá osobní data uºivatele, druhá data pro p°ihla²ování a t°etí bude pomocná pro registraci/potvrzení. Uºivateli se nejprve zobrazí stránka s formulá°em, kde vyplní osobní údaje. Po úsp¥²ném uloºení dat do databáze se uºivateli zobrazí dal²í formulá°, kde má moºnost si zvolit uºivatelské jméno ke svému ú£tu, které musí být unikátní a pomocí toho se bude p°ihla²ovat do systému. Pokud uºivatel nezvolil unikátní uºivatelské jméno, zobrazí se mu stránka s formulá°em pro zadání uºivatelského jména znovu, dokud nevybere takové, které je²t¥ nikdo nepouºívá. Uloºením uºivatelského jména do systém· je dokon£en první krok registrace. Osobní údaje se uloºí do tabulky s osobními údaji, uºivatelské jméno do pomocné tabulky pro registraci, spolu s registra£ním kódem a platností kódu. Druhým krokem je potvrzení registrace. Systém ode²le na vypln¥nou emailovou adresu email s registra£ním kódem ve form¥ odkazu, na který musí uºivatel kliknout. Po kliknutí na odkaz se dokon£í proces registrace, systém vygeneruje p°ihla²ovací údaje (heslo) do systému a po²le je nov¥ registrovanému uºivateli na vypln¥nou e-mailovou adresu. Tímto je dokon£ena registrace uºivatele. Jedná se nyní o registrovaného uºivatele, který po úsp¥²ném p°ihlá²ení do systému m·ºe vyuºívat v²ech funkcionalit systému, v£etn¥ moºnosti zm¥nit p°ihla²ovací heslo. D·leºitá v procesu registrace je pomocná tabulka pro registraci, která ukládá registra£ní kód pro ov¥°ení registrace a jeho platnost. Uºivatel bude mít omezený £asový úsek pro potvrzení registrace (24 hodin). Tato tabulka také uchovává stav registrace. Aº po úsp¥²ném potvrzení registrace dojde k dokon£ení vytvo°ení uºivatelského ú£tu p°ekopírováním poºadovaného uºivatelského jména do tabulky s p°ihla²ovacími údaji. Osobní údaje a p°ihla²ovací údaje

4.1. FUNKNOSTI SYSTÉMU

17

budou ve dvou rozdílných tabulkách. Unikátnost uºivatelského jména se musí kontrolovat oproti tabulce p°ihla²ovací, i tabulce s registracemi, kde se budou brát v úvahu pouze ta uºivatelská jména, pro která je²t¥ registrace m·ºe být potvrzena (kterým je²t¥ nevypr²el £asový limit). Aby nevyuºité registrace neblokovaly uºivatelská jména, která ve skute£nosti nejsou pouºita, p°i kontrole, zda uºivatelské jméno je k dispozici, se uºivatelská jména u takto nevyuºitých registrací nebudou brát v úvahu.

Následující diagram C.2 znázor¬uje pr·b¥h registrace a zú£astn¥né subjekty. Registration manager je £ást systému - kód, který obstarává kroky registrace. V p°íloze na CD potom najdete diagram aktivit a diagram stav·.

sd SequenceView-Registration RegistrationManager

Mailer

RandomUser

User

WantRegistration()

FillRegForm()

SendRegForm()

CreateNewUser()

ChooseUserName()

SaveUserName() opt UserNameUsed [TRUE]

SelectOtherUserName()

AddUserName()

SendRegEmail()

ConfirmRegEmail()

ConfirmUserValidity()

SendPassEmail()

RegistrationCompleted()

Obrázek 4.1: Registrace - sekven£ní diagram


18

4.1.4 Vykonávání poºadavk· na zm¥ny Webové rozhraní pro uºivatele a administrátory je pouze £ástí systému, který má slouºit pro ovládání hostingu. P°i p°idání sluºby, nebo zm¥n¥ nastavení, je pot°eba krom¥ zápisu do databázových tabulek vykonat toto nastavení i na serveru. Tato kapitola má za cíl popsat systém vykonávání a ukládání zm¥n na serveru. Funk£nosti a jejich nastavení, které hosting poskytuje, m·ºeme rozd¥lit na následující dv¥ skupiny:

Skupina 1:

Jedná se o zm¥ny, které nevyºadují zásah do nastavení serveru, nebo ap-

likací na n¥m b¥ºících. Pat°í sem takové funkce, které se týkají pouze informací uloºených v databázi. Jedná se o správu uºivatel· (informace o zákazníkovi, heslo do informa£ního systému, proces registrace) a správu administrátor· (v£etn¥ správy rolí).

Skupina 2:

Jedná se o takové zm¥ny, které zasahují do nastavení aplikací b¥ºících na

serveru. Tyto zm¥ny je pot°eba provést na dvou úrovních jednak v databázi a potom p°edev²ím na serveru.

Hlavním cílem

je zaji²t¥ní bezpe£nosti a stability provozu serveru, tedy je pot°eba

aby uºivatel nem¥l moºnost nastavit n¥co ²patn¥ tak, aby to n¥jakým zp·sobem negativn¥ ovlivnilo provoz. Zde se nabízí n¥kolik °e²ení.

Prvním °e²ením by mohlo být vynechání databáze nastavení sluºeb by nebylo uloºeno v databázi, byly by v ní pouze p°ihla²ovací a osobní údaje uºivatel·. Existovala by sada skript·, která by poºadavek ihned vykonala. Dále by mezi skripty byly takové, které by pro daného uºivatele vybraly aktuální nastavení, aby si ho uºivatel mohl zobrazit.

Druhým °e²ením by bylo zachování databáze, s tím, ºe po uloºení do databáze by se ihned spustil skript, který by tu stejnou operaci vykonal i na serveru. Toto °e²ení má výhody v tom, ºe by zm¥ny byly provedené ihned a zárove¬ by bylo jednodu²²í zobrazení aktuálního nastavení, protoºe by bylo uloºené v databázi. Zde by mohlo dojít k problému, ºe uloºení do databáze prob¥hne a nastavení na serveru jiº ne. Tento problém by ale ²el odstranit zp¥tnou kontrolou.

T°etí moºností je asynchronní °e²ení. Poºadavky na zm¥nu by se denovaným zp·sobem uloºili v databázi do fronty a existovala by sada skript·, která poºadavky postupn¥ vykoná. Operace by neprob¥hly ihned, ale skripty by byly spu²t¥ny pouze v ur£itých £asech. Tento zp·sob umoºní dobré sledování historie zm¥n a i p°ípadnou kontrolu, jaké poºadavky se budou provád¥t. Zárov¥¬ umoºní kontrolu nad zát¥ºí systému. Sloºit¥j²í zde bude zachování konzistence dat, protoºe zm¥ny musíme provád¥t na dvou místech v databázi i na serveru. První °e²ení se ukazuje jako nejvíce vyhovující s ohledem na zachování konzistence dat. S ohledem na bezpe£nost by i zde mohly být obsaºeny v²echny pot°ebné kontroly. Protoºe ale p°i zm¥n¥ nastavení v aplikacích na serveru je v¥t²inou pot°eba provést restart/reload dané aplikace, zm¥ny provedené skripty by nebyly do restartu patrné. Restart po kaºdém zavolání skriptu je nemoºný, protoºe by mohl p°íli² zat¥ºovat server a sluºby by se staly p°echodn¥ nedostupnými. Tento problém by se dal vy°e²it provád¥ním restartu pouze v ur£ených £asech. Zárove¬ ale je pot°eba, aby uºivatel i administrátor m¥l moºnost zobrazit si nastavení sluºeb. První °e²ení by sice bylo schopno poskytnout skripty, které by nastavení pro daného zákazníka zobrazily, ale jen za p°edpokladu, ºe existuje fyzicky jeden server. S ohledem na nefunk£ní poºadavky z kapitoly 3, které obsahují poºadavek, ºe systém musí být funk£ní i pro fyzicky více server·, být navrºen tak, aby fungoval, i kdyº fyzicky bude existovat více server·, se toto °e²ení jeví jako nevhodné, protoºe skripty by byly sloºité, a


19

stejn¥ bychom museli n¥kde ukládat informaci, který server je pro kterou sluºbu pouºit. Mezi druhým a t°etím °e²ením se jeví jako výhodn¥j²í °e²ení t°etí, protoºe v tomto p°ípad¥ bude existovat historie provád¥ných zm¥n a kontrola zát¥ºe. e²ení navíc poskytuje administrátorovi moºnost kontrolovat provád¥né zm¥ny. Problém p°ípadné nekonzistence dat se vy°e²í následnými kontrolami. Krom¥ skript· provád¥jících jednotlivé operace se v daný £as bude spou²t¥t skript, který zkontroluje konzistenci dat a p°ípadné problémy vypí²e administrátorovi do logu.

4.1.4.1 Zp·sob ukládání a °e²ení poºadavk· na zm¥ny P°i zm¥n¥ nastavení nebo p°idání sluºeb chceme uloºit nové nastavení do databáze a vytvo°it poºadavek pro tuto zm¥nu, který potom bude proveden skriptem na serveru. e²ení p°idat ke kaºdé tabulce, která obsahuje nastavení sluºeb, tabulku s novým nastavením, by bylo zna£n¥ komplikované a rozsáhlé. Situace se vy°e²í zavedením tabulky (tzv. fronty), do které se budou ukládat poºadavky, které mají být na serveru vykonány a tabulky pro ukládání historie. P°íkazy budou ukládány do fronty, kterou v na²em p°ípad¥ p°edstavuje tabulka v databázi, a v denovaných £asových okamºicích budou na serveru spou²t¥ny skripty - tzv. roboti, kte°í vykonají p°íkazy, které se ve front¥ nashromáºdily. Pro vykonání poºadavku robot pot°ebuje následující informace: - jaká operace se má provést - kde má zm¥na prob¥hnout (na kterém serveru) Dále je pot°eba uchovat informaci kdo zm¥nu vyvolal, jakého uºivatele se týká, £as uloºení a £as vykonání poºadavku a jeho stav. V p°ípad¥ více server· budou roboti spu²t¥ni na kaºdém serveru, a z fronty poºadavk· budou vybírat pouze ty, které se týkají serveru, který obsluhují.

Popis stav·, ve kterém se poºadavek m·ºe nacházet (atribut Status): wait_approval Do tohoto stavu se poºadavek dostane, pokud k jeho vykonání je pot°eba souhlas administrátora, administrátor si m·ºe zobrazit seznam poºadavk·, které jsou v tomto stavu a p°ípadn¥ je schválit. Robot si poºadavk· v tomto stavu nev²ímá.

new Stav, do kterého se poºadavek dostane pokud k n¥mu není pot°eba souhlas administrátora, a nebo pokud byl administrátorem jiº odsouhlasen. Této skupiny poºadavku si v²ímá robot a vykonává je.

declined Tento stav mají poºadavky, které byly administrátorem zamítnuté. Robot si t¥chto poºadavk· nev²ímá.

processing V tomto stavu jsou poºadavky, které jsou práv¥ vykonávány robotem. Do tohoto stavu nastaví poºadavek robot, neº poºadavek vykoná a stav zm¥ní po vykonání poºadavku.


20

error V tomto stavu skon£í poºadavky, které byly neúsp¥²n¥ vykonané. Tento stav smí nastavit robot.

done V tomto stavu skon£í úsp¥²n¥ vykonané poºadavky. Tento stav smí nastavit robot.

cancelled V tomto stavu skon£í poºadavek, který by uºivatel zru²il je²t¥ neº by byl vykonán.

P°i ukládání do tabulky

T_CommandQueue,

která obsahuje poºadavky, se v p°ípad¥, ºe

T_CQHistory. Tato tabT_CommandQueue (abychom v¥d¥li k jaké T_CommandQueue sloupe£ky Param1 Param6

se jedná o editaci, bude ukládat p·vodní nastavení do tabulky v ulka bude obsahovat vazbu na zákazníka, vazbu na operaci se historie váºe) a dále stejn¥ jako

pro uloºení p·vodního nastavení. Hodnoty t¥chto sloupe£k· jsou stejné jako specikace pro

T_CommandQueue. Do fronty se obecn¥ ukládají t°i typy poºadavk· p°idání, editace nebo zru²ení sluºby. Následující odstavec popisuje pr·b¥h t¥chto operací:

4.1.4.2 P°idání sluºby P°i zakládání nové sluºby se data uloºí do databáze, do tabulky s nastavením. Do fronty se uloºí pat°i£ný poºadavek a namísto parametr· zakládané sluºby se pouze uloºí ID záznamu v tabulce s nastavením, kam jsme sluºbu jiº p°idali (a p°ípadn¥ kontrolní parametry). Do tabulky s historií se v tomto p°ípad¥ nic neukládá. P°i výpisu sluºeb by se m¥lo zkontrolovat, zda neexistuje ve front¥ nevy°ízený poºadavek na vytvo°ení práv¥ této sluºby, pokud ano, sluºba by se nem¥la zobrazit jako existující, ale pouze s poznámkou, ºe je uloºena a £eká na zaloºení. Robot po vykonání poºadavku zm¥ní jeho stav, jiné úpravy v databázi provád¥t nemusí.

4.1.4.3 Zru²ení sluºby Protoºe v²echny sluºby, které je moºné vytvo°it a zru²it, jsou v databázi dopln¥ny o poloºky

ValidFrom

a

ValidTo

typu datetime, zru²ení sluºby se °e²í jejím zru²ením na serveru, ale

jiº ne smazáním záznam· z databáze, ale pouze nastavením hodnoty

T_CQHistory. nastavení poloºky ValidTo,

ValidTo

na aktuální

datum. Pro mazání tedy není pot°eba vyuºití P°i uloºení poºadavku nedojde k

takºe fakt, ºe sluºba £eká

na smazání, by se m¥l zobrazit stejným zp·sobem jako v p°ípad¥ p°idávání sluºby. Robot po vykonání poºadavku na serveru zm¥ní jeho stav ve front¥ a nastaví poloºku

ValidTo

v

tabulce s nastavením p°íslu²né sluºby.

4.1.4.4 Editace nastavení sluºby Asi nejkomplikovan¥j²ím procesem je editace nastavení jiº existující sluºby. V databázi se

param1 aº param6 se uloºí nastavení sluºby. Do tabulky T_CQHistory se p°ekopíruje p·vodní nastavení. zm¥ny neuloºí ihned. Nejprve se do fronty vloºí poºadavek na zm¥nu, do polí£ek


21

Robot vykoná zm¥ny na serveru, zm¥ní stav poºadavku ve front¥ a následn¥ musí provést zm¥nu i v tabulkách s nastavením sluºeb. P°i výpisu nastavení sluºeb by bylo vhodné p°idat poznámku, ºe k dané sluºb¥ je uloºený poºadavek na zm¥nu.

Vºdy p°ed vloºením poºadavku do fronty se kontroluje tarif, zda má na danou sluºbu uºivatel nárok. Pokud se jedná o sluºby omezené po£tem, je pot°eba kontrolovat po£et jiº zaloºených sluºeb i £ekajících poºadavk· na zaloºení dané sluºby. Nap°. kdyº bude povoleno 5 alias·, je pot°eba kontrolovat po£et jiº zaloºených alias· a po£et poºadavk· na zaloºení aliasu. Tato kontrola prob¥hne je²t¥ p°ed uloºením poºadavku do fronty.

4.1.4.5 Zobrazování nastavení sluºeb Co se tý£e zobrazování aktuálního nastavení uºivateli, je pot°eba aby uºivatel jasn¥ rozpoznal, jaké je aktuální nastavení jeho sluºeb, které sluºby jsou jiº nastavené na serveru, a které teprve £ekají ve front¥ na zpracování. Proto p°i výpisu budeme rozli²ovat následující kategorie:

•

OK - v²echno je správn¥ nastaveno na serveru

•

CREATE PENDING - tato sluºba byla uºivatelem vytvo°ena, ale je²t¥ není zavedena na serveru

•

CHANGE PENDING - byly provedeny zm¥ny nastavení této sluºby, které je²t¥ nejsou zrealizované na serveru

•

DELETED - u této sluºby je poºadavek na smazání

Robot provád¥jící operaci by m¥l zajistit konzistenci dat a v p°ípad¥, ºe by se nastavení na stran¥ serveru nezda°ilo, upravit nastavení v databázi tak, aby odpovídalo skute£nosti. Pro jistotu bude na serveru existovat skript, který se jednou za £as spustí a zkontroluje, zda data v databázi odpovídají skute£nému nastavení. P°ípadn¥ nesrovnalosti vypí²e do logu, který bude k dispozici administrátorovi, který následn¥ problémy vy°e²í.

Následující diagram aktivity 4.2 znázor¬uje pr·b¥h celého procesu editace nebo p°idání sluºeb. Dále je k dispozici sekven£ní diagram 4.3 a diagram stavový 4.4 pro znázorn¥ní stav·, v jakých se poºadavek smí nacházet.


22

act ActivityView-Settings

ChangeSettings

Rozhodnutí o jaký typ zmìny se jedná, zda se jedná o zmìnu v nastavení služeb [yes] nebo pouze v zmìnì dat [no]. SettingsChange [YES]

Insert request into CommandQueue [NO]

Insert old settings into History

Update in DB

NeedAdminApproval

[YES] Approved by Admin

[YES]

[NO]

Wait for Robot

Changed By Robot

Update in DB

Set status in CommandQueue

ChangeSettingsDone

Obrázek 4.2: Settings - diagram aktivit

Set status in CommnadQueue


23

sd SequenceView-Settings

Celé probíhá až po úspìšném pøihlášení (nalogování) uživatele do systému

SettingsManager RegisteredUser

Admin

ChangeSettings()

opt DataOnlyChange

SettingChanged()

[YES]

[NO] opt AdminApprovalRequired [YES] ApproveSettings()

Approved()

PerformChanges()

Performered()

SettingChanged()

Obrázek 4.3: Proces nastavení sluºeb - sekven£ní diagram

Automat


24

stm StateView-Settings

User/Admin update settings

NeedApprovalByAdmin

[YES]

wait_approval

[NO]

Approved [YES]

[NO]

declined

new

processing

ProcessSuccessful [YES]

done

[NO]

error

Update Process Finished

Obrázek 4.4: Stav poºadavk· v procesu nastavení sluºeb - stavový diagram

4.2. ARCHITEKTURA SYSTÉMU

25

4.2 Architektura systému V této sekci se zam¥°íme na architekturu systému a roz£len¥ní systému na jednotlivé komponenty.

4.2.1 Pouºité technologie K informa£nímu systému musí mít p°ístup uºivatelé ze svých osobních po£íta£· prost°ednictvím internetu. Proto se jako nejjednodu²²í °e²ení uºivatelského rozhranní jeví dynamická webová aplikace, pomocí které se uºivatelé i administráto°i k systému mohou p°ipojit.Diagram nasazení zobrazující pouºité technologie je v p°íloze na CD. Pro klientskou £ást je výkonným prost°edím webový prohlíºe£. Serverová £ást je rozd¥lena na více £ástí. Na serveru b¥ºí webový server Apache, který je výkonným prost°edím pro informa£ní systém, který bude naprogramovaný v jazyce PHP. Systém komunikuje s databází, s mailovým serverem a s roboty (Automatic processes ), kte°í zaji²újí vykonávaní operací na serveru a nastavování sluºeb.

4.2.2 Interakce jednotlivých £ástí systému Obrázek 4.5 znázor¬uje interakci informa£ního systému s jiº existujícími £ástmi celého systému pro správu hostingu. V sou£asné dob¥ existuje webová prezentace s informacemi a popisy tarif·, která je spravovaná systémem CMS (Content Management System). Údaje o tarifech je vhodné ukládat pouze na jednom míst¥, kterým bude na²e spole£ná databáze. Prezenta£ní web bude údaje brát pomocí vytvo°ené XML sestavy a transformovat do svého designu. S ohledem na bezpe£nost systému bude £ást pro uºivatele (Client Control Panel) zcela odd¥lena od £ásti pro administrátory (Admin Control Panel). Tím se vy°e²í i problém toho, ºe by jedna osoba zárove¬ byla uºivatelem (zákazníkem) a administrátorem (zam¥stnancem) bude mít v tomto p°ípad¥ dva rozdílné ú£ty a p°ihla²ovací údaje. Samoz°ejm¥ £ást funk£ností systému je stejných pro administrátory i uºivatele a budou existovat sdílené funkce, ale k systém·m se bude p°istupovat odd¥len¥. Komunikace mezi informa£ním systémem, starajícím se o ukládání a prezentaci dat (CP

- Control Panel ), a výkonným systémem (AP Automatic Processing ), který poºadavky na nastavení aplikuje na serveru, probíhá pomocí databáze. Systémy mezi sebou nemají ºádnou p°ímou interakci, Client CP ani Admin CP nespou²t¥jí ºádné funk£nosti systému AP. Systémy spolu komunikují prost°ednictvím vý²e zmín¥né spole£né tabulky v databázi fronty.


26

pkg ComponentModel AdminControlPanel

ClientControlPanel

WEBMain

SQL

SQL

XML

Database

SQL

SQL CMS

Automatic Processing

Obrázek 4.5: Komponenty systému

4.2. ARCHITEKTURA SYSTÉMU

27

4.2.3 Komponenty a struktura systému Systém je navrºen podle návrhového vzoru MVC (Model View Controller ) [6]. Tento návrhový vzor odd¥luje prezenta£ní vrstvu systému (view) od vrstvy, která p°íkazy zpracovává (model) a vrstvy, která provádí kontroly vstup· z klávesnice a oprávn¥ní na spou²t¥ní p°íkaz· (controller). Následuje stru£ný popis funkce jednotlivých komponent, obrázek je k dispozici v p°íloze na CD.

View

slouºí pro zobrazování informací, existují dv¥ odd¥lené £ásti pro uºivatele

(klienty) a pro administrátory (zam¥stnatnce)

Controller slouºí ke kontrole vstup· od uºivatel· systému a autentizaci, pro zaji²t¥ní autentizace spolupracuje s dal²ími komponentami

Model

jedná se o komponentu zaji²újící v²echny hlavní funk£nosti systému, uk-

ládání a zobrazování dat ve spolupráci s databází a s vstupem z komponenty Controller, má moºnost spustit procesy z komponenty Automatic Processes

Session Manager

zaji²úje autorizaci p°ístupu k informacím, v p°ípad¥ klient· je

to pouze stav p°ihlá²en nep°ihlá²en, v p°ípad¥ administrátor· se jedná o systém rolí, rozdílné °e²ení pro administrátory a pro zákazníky

Authenticator

komponenta obstarávající autentikaci, která pro administrátory a

zákazníky probíhá odd¥len¥

DatabaseAbstractionLayer

jedná se o vrstvu, která komunikuje s databází. V

praxi v tomto informa£ním systému bude tato vrstva sou£ástí komponent, které ji vyuºívají.

Database jedná se o databázový objekt, který ukládá data Automatic Processes (Robot) jedná se o £ást systému, která obsahuje tzv. roboty, kte°í provád¥jí nastavení na serveru. Vazba na Model je zde pro p°ípad, ºe ovládání n¥kterých robot· by m¥l administrátor umoºn¥no pomocí webového rozhraní.

4.2.4 Modularita a roz²i°itelnost systému Systém musí být naprogramován takovým zp·sobem, aby bylo jednoduché p°idávání dal²ích funk£ností, protoºe je jisté, ºe k tomu pom¥rn¥ brzy dojde. P°i dodrºení návrhu MVC bude v p°ípad¥ p°idávání nových modul· (funk£ností) pot°eba ud¥lat zm¥nu v £ásti View a Model, Controller pouze v takových p°ípadech, kde je pot°eba kontrola vstupních dat a v p°ípad¥ pouºívání funk£nosti administrátory je vºdy nutné p°idat do databáze operace, pro umoºn¥ní jejich p°i°azení k roli. Systém obsahuje zárove¬ rozhraní pro zákazníky i pro administrátory, £ást View je pro kaºdou skupinu rozdílná, ale protoºe v¥t²ina funkcí se pouºívá pro oba dva typy uºivatel·, je pot°eba zajistit co nejniº²í duplikování kódu. Toto bude dosaºeno jednodu²e, zvolením objektového p°ístupu programování, kdy jednotlivé t°ídy budou obsahovat sadu funkcí, kterou smí vyuºívat rozhranní pro zákazníky i pro administrátory.


28

4.3 Zabezpe£ení systému Zabezpe£ení systému je jednou z nejvy²²ích priorit a proto bude probíhat pot°ebné mnoºství kontrol, zejména kontrol vstupních dat. Následuje stru£ný vý£et n¥kolika bezpe£nostních opat°ení:

•

Obsah formulá°· a správnost zadaných údaj· (nap°. zda je e-mailová adresa ve správném formátu) se bude pro pohodlí uºivatele kontrolovat na webové stránce Java Scriptem, ale kontrola zárove¬ prob¥hne i na stran¥ serveru (v PHP).

•

V²echna data, která jsou ukládána do databáze, musí být o²et°ena, aby neobsahovala pro databázi nebezpe£né znaky.

•

Uºivatel má moºnost si kdykoli p°es informa£ní systém zm¥nit hesla k pouºívaným aplikacím.

•

Uºivatelé mají práva jen na vlastní ú£ty, vy²²í hrozbou by byla moºnost p°ihlásit se pod právy administrátora. I s ohledem na p°edejití této situace je odd¥lené p°ihla²ování do systému, nejen vizuáln¥ pro uºivatele, ale i fyzicky v systému autentizace je zaji²óvána odli²nými t°ídami a p°ihla²ovací údaje jsou v databázi v rozdílných tabulkách. Díky tomu bude moºné správu kompletn¥ odd¥lit, nap°. jen povolit p°ístup jen z n¥kterých IP adres.

Kapitola 5

Realizace 5.1 Adresá°ová struktura a kongurovatelnost Adresá°ová struktura p°i programování byla vytvo°ena tak, aby mohlo být odd¥leno administrátorské rozhraní od uºivatelského. Funkce, spole£né pro ob¥ £ásti sytému, jsou sdílené pomocí t°íd, coº sníºí zbyte£né duplikování kódu. Systém je naprogramován v jazyku PHP, objektov¥, uºivatelské rozhraní v HTML s pouºitím Java Scriptu pro jednoduché dynamické funk£nosti, jako kontrola formulá°·. Databáze je pouºita MySQL, protoºe je neplacená a pro tento projekt posta£ující projekt neobsahuje extrémn¥ náro£né operace s databází.

5.1.1 Adresá°ová struktura programu /admin /inc index.php /class /css /doc /inc /js config.inc.php connect.inc.php index.php init.inc.php Soubory obsaºené v adresá°i

/admin se týkají pouze administrátorského rozhraní. /admin/inc

má podobný obsah jako/inc ale je pro administrátorské rozhraní.

/class obsahuje v²echny t°ídy, které jsou volány z /admin/inc i z /inc, tedy je spole£ný pro ob¥ £ásti sytému, t°ídy jsou roz£len¥ny logicky podle jednotlivých funk£ností.

/css

obsahuje kaskádové styly,

/js

obsahuje Java Scriptové soubory a

/doc

textové

soubory, jejichº obsah se vkládá do webových stránek.

config.inc.php slouºí pro konguraci programu, init.inc.php pro inicializaci prom¥nconnect.inc.php pro p°ipojení do databáze. index.php je hlavní °ídíci soubor celého

ných a

29

KAPITOLA 5. REALIZACE

30

programu, v n¥m se ov¥°uje zda je uºivatel p°ihlá²en (pop°. jakou má roli) a podle toho se vkládají dal²í pot°ebné soubory.

Adressá° class: /class Access.php Admin_Authorization.php Alias_Web.php Authorization.php Checker.php Crontab.php CryptClass.php Customer.php Database.php DatabaseHosting.php Domain_Mail.php Domain_Web.php EmployeeUser.php HtmlForm.php Logger.php Mail_Box.php Mailer.php Operation.php Question.php Request.php Role.php Server.php Tariff.php

5.1.2 Kongurovatelnost Je snaha co nejmén¥ zasahovat do kódu programu, proto existuje soubor

config.inc.php

který obsahuje souhrn nastavení detaily k p°ipojení do databáze, nastavení hodnot vybraných prom¥nných apod. P°i nutnosti zm¥nit n¥který z t¥chto údaj· zm¥nu provedeme pouze v tomto souboru na jednom míst¥ a nemusíme zasahovat do více soubor· a hledat kde zm¥ny provést.

5.2 Administrátorské rozhraní 5.2.1 Role a zabezpe£ení Administrátorský p°ístup je °e²en pomocí rolí. Existuje sada operací (kaºdá funk£nost p°edstavuje jednou operaci), které se seskupí do rolí. Administrátorovi je p°i°azena jedna nebo více rolí. Následující obrázek 5.1 znázor¬uje návrh uloºení dat týkajících se administrátor· a oprávn¥ní.

5.2. ADMINISTRÁTORSKÉ ROZHRANÍ

31

Obrázek 5.1: Uloºení dat - Zam¥stnanec a role

5.2.1.1 Kontrola rolí p°i b¥hu programu PHP kód je vytvo°en tak, ºe p°i kaºdém kliknutí se p°edají dva parametry:

$doc = název do které skupiny operace pat°í (pomocí switch v index.php se podle hodnoty $doc pouºije pat°i£ný soubor)

$action = £íslo akce, která se má provést (pomocí switch v p°íslu²ném souboru se vykoná pot°ebný kód) Kaºdá kombinace

$action

a

$doc

zahrnuje jednu operaci v systému (m·ºe to být zo-

brazení nastavení, vypsání formulá°e, uloºení dat). U kaºdé z t¥chto operací je pot°eba kontrolovat, zda na ni p°ihlá²ený administrátor má právo. Kontrola je vy°e²ena následovn¥: Kaºdá role má unikátní název (poloºka Name v

`$doc-action'. Prom¥nné $doc

a

$action

T_Operation

), který je ve formátu:

se inicializují na po£átku, v souboru init.inc.php, který je

includován z index.php. Includu souboru, který obsahuje poºadovanou operaci, p°edchází kontrola pomocí switch, zda daný uºivatel má na operaci právo. Pokud ne, hodnota

$doc

se

nastaví na noaccess a tedy pr·chod switchem spadne do tohoto p°ípadu a administrátorovi zobrazí hlá²ku o nedostate£ných právech na operaci. Existují operace, na které není pot°eba mít ºádná práva, ty jsou obsaºeny v poli výjimek a nekontrolují se v·£i databázi. Jedná se o login a p°ípady s £íslem 20, které se pouºívají


32

vºdy pro zobrazení výsledku (hlá²ení o pr·b¥hu p°íkaz·).

$access = "$doc-$action"; if (! in_array($access, array('-', 'login-','login-1','login-2','crontab-20','customer-20', 'dbhosting-20', 'domainmail-20','domainweb-20', 'employee-20', 'question-20', 'role-20', 'serverinfo-20', 'tariff-20','home-'))) if (! Access::getAccess($access) ) $doc = 'noaccess';

T°ída Access.php obsahuje funkce, která vrátí výsledek, zda p°ihlá²ený administrátor má na poºadovanou operaci oprávn¥ní.

public static function getAccess($a_operationCode){ $sqlSelectAccess = " SELECT Count(1) cnt FROM T_Operation o, T_RoleOperation x, T_Role r, T_EmplRole e WHERE o.IDOperation = x.IDOperation AND x.IDRole = r.IDRole AND r.IDRole = e.IDRole AND e.IDEmployeeUser = @IDEmployeeUser AND OperationCode = '$a_operationCode' "; $res = mysql_query($sqlSelectAccess); $row = mysql_fetch_array($res); $cnt = $row['cnt']; if ($cnt > 0) return true; else return false; }

5.2.1.2 Role a operace p°ipravené p°i instalaci P°i instalaci je pot°eba spustit skript pro vloºení v²ech operací a po£áte£ních rolí do databáze. Seznam v²ech operací v£etn¥ jejich unikátního kódu byl tvo°en pr·b¥ºn¥ p°i programování. Dv¥ p°edp°ipravené role jsou: - Po£áte£ní role je p°i°azena vytvá°enému administrátorovi, má právo pouze na p°idání dal²ích administrátor· a jejich role. - Super admin jedná se o roli, která má právo na úpln¥ v²echny operace.

5.2.1.3 P°idávání dal²ích rolí P°idávání dal²ích rolí smí administrátor, pokud má na tuto operaci oprávn¥ní, pomocí administra£ního rozhraní. Následující print screen 5.2 z administrátorského rozhraní znázor¬uje formulá° pro p°idávání nových rolí. Administrátor krom¥ základních údaj· o roli vybere v²echny operace, které je moºné v rámci role provád¥t.


33

Obrázek 5.2: Formulá° - p°idání role

5.2.2 P°epnutí do role zákazníka Administrátor má moºnost krom¥ zobrazování v²ech sluºeb (nap°. v²ech domén) zobrazit nastavení pro jednotlivé zákazníky a p°idávat sluºby pro jednotlivé zákazníky. Toto je °e²eno tak, ºe administrátor (pokud má na tuto operaci oprávn¥ní) se m·ºe p°epnout do role zákazníka. Funk£nost se nazývá SUDO - pojmenováno podle programu z Unixových systému, kde pomocí tohoto p°íkazu je moºné spustit program pod právy jiného uºivatele (v¥t²inou pod právy uºivatele root). V této práci se pouºívá pro p°epnutí administrátora do role vybraného uºivatele zákazníka. P°i p°epnutí do role zákazníka se nastaví poloºka IDSudo v tabulce

T_EmployeeUser

na

ID vybraného zákazníka. Je-li administrátor v módu SUDO, zobrazuje se mu jen nastavení vybraného zákazníka (pouºity jsou stejné funkce, dopln¥né o podmínku

WHERE

v

SELECTu).

Administrátor m·ºe p°idávat a editovat sluºby vybraného uºivatele. V p°ípad¥, ºe si administrátor zobrazí nap°. seznam v²ech domén v²ech zákazník·, a chce jednu z nich editovat, po kliknutí na editaci se automaticky nastaví SUDO na toho zákazníka, jemuº pat°í editovaná doména. Následuje ukázka funkce pro p°epnutí do role zákazníka. Obdobn¥ je vy°e²ena i funkce pro zru²ení SUDO public static function nastaveno

public static function isSUDO().

resetSUDO()

public static function SUDO($a_IDCustomerUser){ global $dbo, $logger; $sqlInsertSUDO = "UPDATE T_EmployeeUser SET

a pro zji²t¥ní zda je SUDO


34

}

IDSudo = $a_IDCustomerUser WHERE IDEmployeeUser = @IDEmployeeUser"; if ( $dbo->query($sqlInsertSUDO) ){ if ( $dbo->query('SET @IDCustomerUser = '.$a_IDCustomerUser) ) return "Nastaveno ... viz naho°e v menu"; } return "Nastavení se nepovedlo!";

Ukázka £ásti kódu z funkce vybírající v²echny mailové domény, kde se vytvá°í podmínky pro klauzuli

WHERE.

Prom¥nná

$this->XType

obsahuje informaci, zda je funkce zavolaná

administrátorem nebo uºivatelem.

switch ($this->XType){ case 'admin': if (EmployeeUser::isSUDO() > 0){ // je v modu SUDO $sqlWhere = "AND IDCustomerUser = @IDCustomerUser"; }else{ $sqlWhere = ""; } break; default: $sqlWhere = "AND IDCustomerUser = @IDCustomerUser"; break; }

5.2.3 Uºivatelské rozhraní 5.2.3.1 Kontrola operací a tarifu Jednou ze sloºit¥j²ích £ástí uºivatelské £ásti systému je kontrola tarifu. Kaºdý zákazník má p°i°azen tarif, který specikuje, kolik jakých sluºeb smí pouºívat, nap°. kolik smí mít domén, alis·, pravidel v tabulce cron atd. Jak bylo popsáno v kapitole 3, zákazník si vybere tarif, ale protoºe mu musí z·stat podmínky, za kterých tarif vybral a moºnost p°idat dal²í sluºby, nastavení tarifu se p°ekopíruje do osobního tarifu (tabulka

T_PersonalTariff).

Po vybrání

tarifu m·ºe nastavení m¥nit jiº pouze administrátor. V²echny omezení se týkají sluºeb, které se zavád¥jí na serveru pomocí fronty Com-

mandQueue. Tedy kontrolní funkce, která kontroluje tarif, se volá v kódu na jednom míst¥, a to p°ed zaloºením poºadavku do fronty, ve funkci Funkce pro kontrolu tarifu je ve t°íd¥ Funkce

Tariff.php.

createRequest() ve t°íd¥ Request.php.

Tariff:: checkTariff($a_operation) p°ijme jako parametr název operace (ve switch vytvo°í SQL dotaz

stejném formátu jako se název operace ukládá do fronty) a pomocí

pro zji²t¥ní po£tu vyuºitých sluºeb daného typu. Funkce vybere po£et sluºeb daného typu povolených dle tarifu a po£et aktuáln¥ zavedených sluºeb daného typu (v£etn¥ poºadavk· na zavedení dané sluºby, £ekajících ve front¥). Po£et zbývajících volných sluºeb je rozdíl t¥chto


35

dvou hodnot. Funkce vrátí true nebo false podle toho, zda je po£et volných sluºeb v¥t²í neº 0. Kontrola ve funkci

createRequest()

ve t°íd¥

Request.php:

if (! Tariff::checkTariff($operation) ){ $this->ErrorKey = 9; return 0; } ErrorKey, ROLLBACK) a

V p°ípad¥ ºe jiº je po£et povolených sluºeb vy£erpán, nastaví se hodnota prom¥nné poºadavek se do fronty nevloºí, p°ípadné p°edchozí inserty se zru²í (MYSQL následn¥ se uloºí chybová hlá²ka.

5.2.4 Vykonávání poºadavk· na serveru 5.2.4.1 Fronta poºadavk· Tato podkapitola popisuje funk£nost tzv. fronty p°íkaz·, která °e²í vykonávání t¥ch poºadavk· na serveru, které zasahují do jeho nastavení. Operace s frontou CommandQueue probíhá pomocí t°ídy

Request.php.

Existuje sada

podporovaných operací, a kaºdá operace je ve t°íd¥ Request jako jedna funkce. Tyto funkce mohou být volány z ostatních t°íd, jejich popis je v p°íloze na CD. T°ída

Request.php

dále

obsahuje jednu funkci, která obsluhuje ukládání poºadavk· do databáze. Popis proces· p°idání, zm¥ny nastavení a mazání sluºeb jiº byl popsán v kapitole 3 v¥nující se analýze, zde bude pouze dopln¥na informace o významu pomocné tabulky (T_CmdQHelp), jejíº nutnost se ukázala aº p°i realizaci. P°i zobrazování v²ech sluºeb a nastavení chceme rozli²it, které sluºby jiº má uºivatel zavedené na serveru a které jsou zatím pouze uloºeny v databázi s poºadavkem na zaloºení (ve front¥). Uºivatel si m·ºe vylistovat nap°. seznam v²ech domén, ale je pot°eba mu tam p°idat poznámku v jakém stavu daná doména je na serveru zda je jiº zaloºena, zda je zavedena v databázi a front¥, ale není zaloºena, zda na ni byl dán poºadavek na smazání nebo poºadavek na zm¥nu nastavení. Dohledání t¥chto údaj· zjednodu²í zavedení pomocné tabulky

T_CmdQHelp. Vºdy p°i ukládání do fronty se uloºí záznam i do této tabulky, s parame-

try o jakou operaci se jedná (Delete, Create, Update), jménem tabulky, které se poºadavek týká a ID záznamu v tabulce sluºby, kterého se poºadavek týká. Tato tabulka usnadní listování v²ech sluºeb a dopln¥ní o stav, v jakém se nacházejí. Následující obrázek 5.3 zobrazuje návrh uloºení dat pro frontu. Tabulka

T_CQHistory

slouºí pro ukládání historie p·vodního

nastavení.

Popis parametr· tabulky T_CommandQueue: IDCommandQueue primární klí£, ID v této tabulce IDCustomerUser - cizí klí£, ID zákazníka, ke kterému se zm¥na váºe IDEmployeeUser - cizí klí£, ID zam¥stnance, který zm¥nu vykonal


36

IDServer

- cizí klí£, ID Serveru, na kterém se zm¥ny mají vykonat kde se pouºívá

sluºba kterou upravujeme

Operation

název operace, která se má vykonat (existuje p°edem daná mnoºina

podporovaných operací)

Status stav, ve kterém se poºadavek m·ºe nacházet (popis stav· je níºe) CreatedAt datum a £as vytvo°ení poºadavku ProcessedAt datum a £as vykonání poºadavku Param1

aº

Param6

parametry nastavení sluºeb protoºe do fronty m·ºeme uk-

ládat poºadavky na zm¥nu mnoha sluºeb a kaºdá má jiné parametry, tyto sloupe£ky pouºijeme pro uloºení parametr· sluºeb, v p°íloze na CD je specikace parametr· pro jednotlivé operace, podle této specikace frontu vyuºívají i roboti na serveru

Obrázek 5.3: Uloºení dat - Fronta

Popis parametr· tabulky T_CmdQHelp: IDCmdQHelp primární klí£, ID v této tabulce IDCommandQueue

- cizí klí£, vazba na ID záznamu v tabulce T_CommandQueue

TableName - jméno tabulky, které se týká operace ukládaná do fronty IDRow

- ID °ádku v tabulce sluºby, které se týká operace ukládaná do fronty

Done informace zda jiº byla operace ve front¥ provedena nebo ne `1' nebo `0' OpType typ operace `C' create, Ù' update, `D' delete CreatedAt £as vytvo°ení záznamu


37

5.2.4.2 Vykonávání poºadavk· robot

Robot je skript, který zavede sluºby nebo zm¥ny nastavení sluºeb na serveru, bude kontrolovat frontu poºadavk· v nastavených intervalech. V p°ípad¥ více server·, bude stejný robot spu²t¥n na kaºdém z nich. Robot bude postupn¥ brát poºadavky z fronty od nejstar²ích a provád¥t operace na serveru. Po vybrání poºadavku nastaví stav poºadavku ve front¥ na processing . Po provedení na serveru upraví záznamy i v tabulkách sluºeb pokud je to pot°eba (nap°. u operace delete nastaví datum platnosti sluºby na aktuální datum, nebo v p°ípad¥ zm¥ny uloºí nové nastavení). Pokud v²e prob¥hne v po°ádku, upraví stav poºadavku ve front¥ na done , v p°ípad¥ chyby p°i vykonávání na error . Robot si v²ímá jen poºadavk·, které jsou pro jeho hostitelský server. Proces je zobrazen na následujícícm diagramu 5.4.

sd Sequence-Robot CommandQueue

Server

Automat new getNewRequest() operation(params)

setState(processing) processing

executeRequest()

done(true/false)

opt done [true]

executeChanges()

done(true/false)

opt done [true]

setState(done) done

[false] setState(error)

error

Obrázek 5.4: Proces vykonávání poºadavk· na serveru

Database


38

5.2.4.3 Synchronizace vykonávání poºadavk· N¥které operace jsou závislé na p°edchozích nap°íklad na serveru nejde p°idat alias k je²t¥ nevytvo°ené domén¥, ale uºivatel bude chtít nap°. vloºit doménu a hned alias (d°íve neº bude doména zavedena na serveru). Protoºe se operace do fronty ukládají postupn¥ a robot je zpracovává od nejstar²í po nejnov¥j²í, kdyº budou ve front¥ uloºeny dv¥ na sob¥ závisející operace, robot je vykoná ve správném po°adí. Nap°. zaloºení domény a zaloºení aliasu robot nejprve vykoná zaloºení domény a potom aliasu. P°i ukládání poºadavku na zm¥nu nastavení sluºby se dohledá pomocí pomocné tabulky

T_CmdQHelp, zda jiº existuje n¥jaký nevy°e²ený poºadavek na zm¥nu týkající se stejné sluºby, T_CommandQueue a smaºe se z T_CmdQHelp).

a pokud ano, zru²í se (nastaví stav na cancelled v

Tedy robot nebude zbyte£n¥ vykonávat n¥kolik zm¥n za sebou, ale jen tu poslední. Synchronizaci p°i mazání °e²í systém, ale musí ji kontrolovat robot. P°i smazání sluºby se zaloºí poºadavek do fronty i na smazání na ní závisejících sluºeb, od nejvíce závislých sluºeb nap°. p°i mazání mailové domény se zaloºí nejprve poºadavek na smazání mailbox·, na smazání alias· a nakonec na smazání domény. Pokud uºivatel n¥jakou sluºbu smaºe, nemá jiº moºnost ji editovat nebo k ní p°idávat dal²í sluºby, tedy jiº nebudou ve front¥ vznikat dal²í poºadavky na operace s jiº smazanou sluºbou. V p°ípad¥, ºe uºivatel zaloºí sluºbu a rozhodne se ji smazat d°íve, neº byla zavedena na serveru, záznam se smaºe pouze z fronty. P°i tom se zkontrolují dal²í na této sluºb¥ závisející sluºby, a také se z fronty smaºou.

5.2.4.4 Zaji²t¥ní konzistence dat Robot by m¥l zajistit konzistenci dat, tedy v p°ípad¥, ºe se operace neprovede, ji navrátit do p·vodního stavu a vypsat informaci do logu administrátorovi, který problém vy°e²í. Pokud v PHP probíhá n¥kolik operací s databází, které jsou na sob¥ závislé, je vºdy

MYSQL TRANSACTION a pomocí MYSQL ROLLBACK.

pouºita

pokud n¥která £ást neprob¥hne správn¥, celá operace se

zru²í

Vyuºívá se nap°. p°i vytvá°ení sluºeb, kdy se sluºba vloºí

do databáze do tabulky sluºby a následn¥ se uloºí poºadavek do fronty, p°i jehoº vkládání se kontroluje i po£et povolených sluºeb v·£i tarifu. Pokud uloºení do fronty neprob¥hne, nesmí z·stat údaj uloºený ani v tabulce, celá operace se zru²í. Krom¥ robota vykonávajícího p°íkazy fronty, bude existovat robot, který bude v nastavených intervalech kontrolovat stav databáze oproti stavu na serveru, a p°ípadné chyby vypí²e do logu administrátorovi.

5.2.5 Zabezpe£ení 5.2.5.1 Kontrola vstup· od uºivatele •

Email, doména a URL adresa musí být v odpovídajícím formátu.

•

Hodnoty odesílané formulá°i musí obsahovat rozumnou hodnotu nesmí být prázdné, telefon musí mít p°íslu²ný formát, atd.


•

39

Uºivatelské jméno do systému, název databáze a jméno databázového uºivatele musí být v p°ijatelném formátu (min. 5 znak·, pouze písmena, £ísla, poml£ka nebo podtrºítko)

•

Hesla se p°i volb¥ hesla musí shodovat (formulá° obsahuje dv¥ polí£ka, druhé z nich je kontrolní pro potvrzení hesla) a obsahovat minimáln¥ 5 znak· bez mezer

Kontrola vstup· od uºivatele probíhá na stran¥ klienta pomocí Java Scriptu a v n¥kterých p°ípadech i na stran¥ PHP. Jedná se vºdy o jednoduché regulární výrazy. Na stran¥ klienta se provádí kontrola, zda jsou vypln¥ny v²echny povinné poloºky, zda je email nebo telefon ve správném formátu a zda se shodují hesla. Na stran¥ serveru se provád¥jí kontroly týkající se parametr· nastavovaných sluºeb správná syntaxe domény, emailové schránky, aliasu atd. Kontroly obstarává funkce

Checker.php.

5.2.5.2 SQL injection Útok SQL injection vyuºívá neo²et°ených vstupních polí pro postr£ení kusu kódu SQL dotazu do systému. Kód je posléze databází interpretován. Hrozba se dá o²et°it vyescapováním pro databázi nebezpe£ných znak·. V PHP na to existuje funkce:

string mysql_real_escape_string (string $unescaped_string) [7] V PHP je na v²echny vstupy od uºivatele poslané z formulá°e pomocí $_POST i poslané pomocí $_GET pouºita tato funkce.

5.2.5.3 Ukládání hesel Hesla jsou v databázi ukládána ²ifrovan¥, nikoli jejich otisky. Je to proto, ºe s hesly se dále pracuje p°i nastavování sluºeb na serverech. Technologie jsou r·zné a ne v²ude je moºné pouºít ukládání pomocí hashovací funkce. Ale protoºe ukládání hesel je jisté riziko, je sníºeno ²ifrováním hesel p°ed jejich uloºením, obstarávané ²ifrovací t°ídou CryptClass.php, kterou je moºné upravovat. Pro ²ifrování bylo pouºito funkcí v PHP

mcrypt_generic()

[5].

base64_encode()

[3] a

40


Kapitola 6

Testování Testování aplikace prob¥hlo n¥kolika zp·soby postupné testování jednotlivých £ástí programu po jejich dokon£ení, testování pomocí nástroje Selenium [8] a testování na uºivatelích.

6.1 Obecné testování Pro jednotlivé £ásti aplikace jsem testovala následující aspekty:

•

Aktivovat v²echny odkazy, aplikace vºdy musela zobrazit korektní stránku

•

Vstupní data ve formulá°ích aplikace vºdy musela zobrazit chybovou hlá²ku v p°ípad¥ neakceptovatelných vstupních údaj·

•

Funk£nost formulá°· aplikace musela uloºit správn¥ data odeslaná pomocí formulá°e

•

Kontrola v·£i tarifu aplikace vºdy p°ed uloºením formulá°· musí zkontrolovat oproti tarifu, zda je²t¥ je moºné sluºbu zaloºit

•

Kontrola rolí pro administrátora musí být vykonávaná akce povolena

•

Kontrola akcí aktivovaných odkaz· nap°. smazání údaj·

R·zné webové prohlíºe£e Aplikace byla spu²t¥na na t°ech nejroz²í°en¥j²ích webových prohlíºe£ích (Mozilla Firefox, Internet Explorer a Opera) a zkontrolována správnost zobrazování. Design aplikace je²t¥ bude m¥n¥n v budoucnu podle poºadavk· rmy, aby ladil s designem webových stránek, tedy tento aspekt není momentáln¥ p°íli² d·leºitý.

6.2 Testování pomocí nástroje Selenium Webové rozhraní bylo testováno pomocí nástroje Selenium jedná se o roz²í°ení do Firefoxu, které umoº¬uje vytvo°it jednodu²e testy na jednotlivé funk£nosti, uloºit je a opakovan¥ spou²t¥t. Pomocí nástroje Selenium byly provedeny tyto testy: Pro uºivatelské rozhraní: - Zaregistrování do systému

41

KAPITOLA 6. TESTOVÁNÍ

42

- Zm¥na osobních údaj· (typ rma i osoba) - P°idání mailové domény (p°idá doménu i schránku postmaster), mailové schránky a aliasu - P°idání domény, zaloºení databáze, editace nov¥ vytvo°eného uºivatele a p°idání nového uºivatele - Vloºení dotazu - Vloºení domény a pravidel do tabulky Cron Navíc pro administrátorské rozhraní: - P°idání role - P°idání zam¥stnance (p°i°azení role pro operaci s mail sluºbami) - P°ihlá²ení jako nov¥ vytvo°ený zam¥stnance, zobrazení mail domén (p·jde), web domén (nep·jde kv·li roli) - P°idání tarifu V²echny testy jsou uloºené v p°íloze na CD.

6.3 Testování na uºivatelích D·leºitou £ástí testování je i testování na uºivatelích, které probíhá v sou£asné dob¥, po jeho ukon£ení bude systém zaveden do provozu. V sou£asné dob¥ je systém nasazen na testovacím prost°edí, b¥ºí na serveru ve virtuálním prost°edí (Jail - FreeBSD) [4]. Jail je podobný systému chroot. Navíc i procesy v n¥m spu²t¥né jsou odd¥leny od hostujícího systému. V p°ípad¥ jakékoli chyby by nebyl ovlivn¥n b¥h serveru. Skupina vybraných d·v¥ryhodných uºivatel· má moºnost spravovat své sluºby na serveru pomocí vytvo°ené aplikace, v p°ípad¥ nejasností má za úkol kontaktovat administrátora.

Kapitola 7

Záv¥r 7.1 Zhodnocení Cílem práce bylo navrhnout a implementovat software pro podporu provozu poskytovatele internetových sluºeb (hostingu) který usnadní správu aministrátor·m i uºivatel·m. Po provedení analýzy situace jsem navrhla °e²ení tak, ºe se systém bude skládat ze dvou £ástí, informa£ního systému pro správu údaj·, který je °e²en webovým rozhraním a slouºí administrátor·m i uºivatel·m, a £ást serverovou, která vykonává nastavování na serveru. Protoºe se jedná o velice obsáhlé téma, tato bakalá°ská práce je zam¥°ena na informa£ní systém pro správu nastavení sluºeb a uºivatelských ú£t·. Pro spln¥ní a správné pochopení poºadavk· jsem p°i analýze spolupracovala s p°edstavitelem rmy, pro kterou je software ur£en. Sou£ástí práce je analýza a návrh informa£ního systému, v£etn¥ probíhajících proces· a návrhu uloºení dat. Dále se zabývám propojením informa£ního systému se systémem, který bude spu²t¥n na serverech a obstarávat vykonávání poºadavk·. Výsledkem práce je webové rozhraní, slouºící pro správu sluºeb a nastavení. Systém pro vykonávání poºadavk· na serveru není jako sou£ást této práce implementován. Práce spl¬uje poºadavek z úvodu usnadnit práci uºivatel·m i administrátor·m. Pro uºivatele je výsledek jasn¥ viditelný. Administrátor zatím m·ºe uloºené poºadavky sám zobrazovat a spustit skripty na serveru, které je vykonají, dokud nebude tato £ást automatizovaná, tedy i pro n¥j se jedná jiº nyní o usnadn¥ní práce. Jedná se o funk£ní projekt, který je nyní spu²t¥n v testovací verzi.

7.2 Budoucnost Systém vidím jako první pouºitelnou verzi, která má je²t¥ velký prostor pro budoucí roz²í°ení, proto byla snaha systém navrhnout tak, aby jeho roz²i°ování bylo snadné. Co se informa£ního systému tý£e, nabízí se roz²í°ení o kontrolu a °e²ení plateb, automatizované kontroly platnosti tarif· v£etn¥ odesílání upozorn¥ní zákazník·m o konci platnosti nebo p°ipomenutí platby, odesílání hromadných e-mail·, jejichº text a parametry bude moci administrátor nastavit a dal²í.

43

KAPITOLA 7. ZÁVR

44

Systém by dále m¥l být dopln¥n o automatické vykonávání poºadavk· na serveru. Jedná se o sadu skript·, které budou vybírat uloºené poºadavky, zavád¥t sluºby a nastav¥ní na serveru a nakonec skripty kontrolující konzistenci databáze oproti nastavení na serveru.

[2] [1]

Literatura A

[1] P. Matouch. Instalace L TEXu pro Windows.

http://i.iinfo.cz/r/k/Instalace-TeXu-pro-Windows.pdf,

stav z 1. 5. 2010.

A

[2] L TEX online manuál.

http://www.cstug.cz/latex/lm/frames.html,

stav z 3. 12. 2009.

[3] Php manuál - base64-encode.

http://cz.php.net/manual/en/function.base64-encode.php,

stav z 22. 5. 2010.

[4] Jail - freebsd.

http://www.freebsd.org/doc/en/books/arch-handbook/jail.html,

stav

z

22. 5. 2010. [5] Php manuál - mcrypt-generic.

http://www.php.net/manual/en/function.mcrypt-generic.php,

stav z 22. 5. 2010.

[6] Model-view-controller.

http://msdn.microsoft.com/en-us/library/ms978748.aspx,

stav z 1. 5. 2010.

[7] Php manuál - mysql-escape-string.

http://www.php.net/manual/en/function.mysql-real-escape-string.php, 22. 5. 2010. [8] Selenium.

http://seleniumhq.org/,

stav z 22. 5. 2010.

45

stav

z

46

LITERATURA

P°íloha A

Seznam pouºitých zkratek CMS CP

- Content Management System

- Control Panel

CSS

Cascading Style Sheets

DNS

Domain Name Server

IMAP IP

Internet Message Access Protocol

Internet Protocol

FTP

File Transfer Protocol

HTML

HyperText Markup Language

HTTP

HyperText Transfer Protocol

HTTPS PHP

PHP: Hypertext Preprocessor

POP3

Post Oce Protocol

RBAC RFC

Role Base Access Control

Request for Comments

SMTP SSL

HyperText Transfer Protocol Secure

Simple Mail Transfer Protocol

Secure Socket Layer

SQL

Structured Query Language

WWW XML

World Wide Web

Extensive Markup Language

. . .

47

48

PÍLOHA A. SEZNAM POUITÝCH ZKRATEK

P°íloha B

Funk£ní poºadavky a p°ípady uºití B.1 Detailní funk£ní poºadavky Neregistrovaní uºivatelé: 1. Systém bude umoº¬ovat registraci novým uºivatel·m ( oby£ejná osoba / právnická osoba ) 2. Systém umoº¬uje vloºit dotaz na pracovníka

Registrovaní uºivatelé budou mít po p°ihlá²ení moºnost: 1. Spravovat tarif a sluºby

•

Zobrazit detailní informace o v²ech tarifech

•

Bude moºné vybrat tarif

•

Prohlíºet nastavený tarif a detaily tarifu

•

Zm¥nit tarif na jiný tarif z nabídky

•

Zru²it tarif (deaktivovat)

2. Spravovat osobní údaje

•

Zobrazit osobní údaje

•

Editovat osobní údaje (vkládané p°i registraci)

•

Zm¥nit heslo do informa£ního systému

3. Vkládat dotazy na administrátory

•

Moºnost vloºit dotaz na administrátora (pracovníka)

•

Moºnost prohlíºet v²echny vloºené dotazy a odpov¥di na n¥

4. Spravovat vlastní Webové domény a s nimi související sluºby

•

Vloºení/Smazání webové domény (do po£tu, který dovoluje tarif )

49

PÍLOHA B. FUNKNÍ POADAVKY A PÍPADY UITÍ

50

•

Výpis v²ech domén a zobrazení detail· nastavení

•

M¥nit nastavení pro webovou doménu

•

P°idání/Smazání aliasu pro webovou doménu

•

Výpis v²ech alias· pro webové domény

•

Zm¥na hesla na FTP

5. Spravovat vlastní domény mail serveru a s nimi související sluºby

•

Vloºení/Smazání e-mailové domény (do po£tu, který dovoluje tarif )

•

Výpis v²ech domén a zobrazení detail· nastavení

•

P°idání/Smazání aliasu k domén¥

•

Zobrazení v²ech alias·

•

P°idání/Smazání e-mailové schránky (MailBox) k domén¥

•

Editace e-mailové schránky

•

Zobrazení v²ech e-mailových schránek

•

P°idání/Smazání aliasu k e-mailové schránce

•

Výpis seznamu alias· k e-mailové schránce

•

P°idání/Smazání pravidla pro p°eposílání e-mail·

•

Výpis seznamu pravidel pro p°eposílání e-mail·

6. Spravovat Databáze a s tím spojené sluºby

•

Vloºení/Smazání databáze

•

Výpis v²ech databází

•

P°idání/Smazání databázového uºivatelského ú£tu

•

Výpis v²ech uºivatelských databázových ú£t·

•

Editace nastavení uºivatelského databázového ú£tu

•

Zm¥na hesla uºivatelského databázového ú£tu

•

Moºnost zadat poºadavek na vytvo°ení zálohy databáze

7. Spravovat sluºbu Crontab

•

P°idání/Smazání pravidla do tabulky Cronu

•

Zobrazení v²ech pravidel

Administráto°i budou mít po p°ihlá²ení moºnost: 1. P°epnout se do role libovolného zákazníka a mít p°ístup na v²echny funk£nosti a údaje jako daný zákazník 2. Zobrazit seznam zákazník·, kterým brzy vypr²í platnost hostingu

Oproti registrovaným uºivatel·m navíc je²t¥:

B.2. DIAGRAMY PÍPAD UITÍ (USE CASE)

51

3. Zobrazit v²echny Webové domény a s nimi související sluºby 4. Zobrazit v²echny e-mailové domény a s nimi související sluºby 5. Zobrazit v²echny Databáze a s tím spojené sluºby 6. Zobrazit v²echny poloºky sluºby Crontab 7. Spravovat tarif a sluºby

•

P°idání/Smazání nového tarifu

•

Editace tarifu a k n¥mu pat°ících sluºeb

•

Prohlíºení detail· v²ech tarif·

•

Moºnost vytvo°it individuální tarif zákazníkovi - kombinace tarifu a sluºeb (Zákazník má tedy práv¥ jeden tarif )

8. Spravovat dotazy a odpovídat na dotazy

•

Vloºit odpov¥¤ na dotaz

•

Prohlíºení v²ech dotaz·

9. Spravovat administrátory (zam¥stnance)

•

P°idání/Smazání Role

•

Zobrazení v²ech rolí

•

P°i°azení Operací k roli (sou£ástí p°idání role)

•

Zobrazení v²ech dostupných operací v£etn¥ popisku

•

P°idání/Smazání administrátora

•

Zobrazení v²ech administrátor· a jejich detail·

10. Spravovat osobní údaje

•

Editovat osobní údaje v systému

•

Zm¥nit heslo do informa£ního systému

Dále systém obstarává: 1. Odeslání e-mail· uºivatel·m, kterým brzy vypr²í platnost tarifu 2. Deaktivace ú£tu po vypr²ení platnosti

B.2 Diagramy p°ípad· uºití (Use Case) Diagramy p°ípad· uºití Use Case jsou v p°íloze na p°iloºeném CD. Uºivatelé systému jsou v£etn¥ obrázku popsání ve t°etí kapitole, sekce 3.3, £ásti systému také ve t°etí kapitole, sekce 3.4 .

52

PÍLOHA B. FUNKNÍ POADAVKY A PÍPADY UITÍ

P°íloha C

Analytické t°ídy Tato p°íloha obsahuje diagram v²ech analytických t°íd, jejich detailní popis je v p°íloze na CD. class ClassView MBResentRules

Services -

-

MailBox

d-DiskSpace: int d-NumDatabase: int e-DiskSpace: int e-Imap: bool e-NumAlias: int e-NumDomain: int e-NumEmailBox: int e-PopSmtp: bool w-DiskSpace: int w-MonthTraffic: int w-NumAlias: int w-NumCrontab: int w-NumDomain: int w-NumSSL: int w-NumUserFtp: int w-Php: bool w-Webalizer: bool w-Winscp: bool

-

automaticReply: string automaticReplyActive: bool catchNonexistAddr: bool diskSpace: int password: string userName: string validFrom: datetime validTo: datetime

0..*

MailAlias

1 0..*

-

aliasName: string validFrom: date validTo: date

0..*

Tariff -

createdAt: date createdBy: idAdmin description: string name: string price: int validFrom: date validTo: date

0..* 0..*

1 1

1

CustomerUser

PersonalTariff

1

1

totalprice: int

Mailer

0..1

diskSpace: int nameDB: string validFrom: date validTo: date

1

1

body: string sendAt: date subject: string

-

MailDomainAlias: MailDomain mxPrimary: int mxSecondary: int nameDomain: string validFrom: datetime validTo: datetime

-

-

1..*

Database

MailDomain -

masterUser: bool privileges: int userName: string userPassword: string

+MailDomainAlias 1

0..*

dayOfMonth: int dayOfWeek: string hour: int minute: int month: int params: string program: enum validFrom: date validTo: date

DBUserAccount -

1

1

-

1

1..*

1

Crontab

actionName: enum emailAddress: string

0..* CopyList -

emailAddress: string status: enum

1 0..* 0..1 -

accessCount: int cookie: string cookieValidUntil: datetime lastiIP: string lastLogin: date newPassTimeout: date newUserPass: string userName: string userPass: string 1

Obrázek C.1: Analytické t°ídy - £ást 1

53

1

1

PÍLOHA C. ANALYTICKÉ TÍDY

54

0..* 0..*

FTP 0..*

QuestionRequest -

answer: string category: enum emailAddress: string history: string postedAt: date question: string solvedAt: date status: enum title: string

CommandQueue 0..*

-

0..1

Customer -

1

AdminUser -

1

createdAt: datetime operation: string param1: string param2: string param3: string param4: string param5: string param6: string processedAt: datetime status: enum

0..*

0..1

0..1

accessCount: int cookie: string cookieValidUntil: datetime email: string lastIP: string lastLogin: date name: string password: string phoneNumber: string userName: string validFrom: date validTo: date

-

0..1

addressCity: string addressName: string addressPSC: string addressStreet: string companyName: string DIC: string email: string ICO: string invoiceAddrCity: string invoiceAddrName: string invoiceAddrStreet: string invoieAddrPSC: string name: string phone: string surname: string

allowChangePrivileges: bool dataSize: int password: string rootDirectory: string userName: string validFrom: date validTo: date 1 0..* Web(VirtualHost) -

automaticDirList: bool documentRoot: string domainName: string effectiveUID: string validFrom: datetime validTo: datetime webAdminEmail: string 1

1

History -

param1: param2: param3: param4: param5: param6:

0..*

string string string string string string

DomainNameAlias Vazba na: CommandQueue Database FTP MailDomain

-

aliasName: string validFrom: datetime validTo: datetime 1

0..* PHPSettings

1..* Server Role -

Operation

1..* description: string 0..* name: string -

description: string name: string operationCode: string

-

mailExchange: int name: string validFrom: date validTo: date

Obrázek C.2: Analytické t°ídy - £ást 2

-

docRoot: string includePath: string maxExecutionTime: int maxMemorySize: int openBasedir: string

P°íloha D

Databáze - uloºení dat Tato p°íloha obsahuje diagram v²ech uloºení den, který byl vyvíjen po celou dobu vytvá°ení projektu, tedy se jedná o aktiální pouºívanou verzi. Diagram je pro p°ehlednost rozd¥len na dva obrázky - D.2 a D.1. Detailní popis jednotlivých £ástí je v p°íloze na CD.

55

56

PÍLOHA D. DATABÁZE - ULOENÍ DAT

Obrázek D.1: Uloºení dat - £ást 1

57

Obrázek D.2: Uloºení dat - £ást 2

58

PÍLOHA D. DATABÁZE - ULOENÍ DAT

P°íloha E

Obsah p°oloºeného CD Na p°iloºeném CD je následující adresá°ová struktura:

• /latex

A

- zdrojové soubory textu ur£ené pro L TEX

• /prilohy

/doc

- v²echny p°ílohy nezahrnuté v textu práce - datové soubory

commandQueue-operace.pdf - popis operací vkládaných do fronty. datovy-model.pdf - detailní popis jednotlivých £ástí datového modelu. operace-role.pdf - seznam podporovaných funkcí a po£áte£ních rolí. popis-trid.pdf - detailní popis analytických t°íd.

/dokumentace - programátorská dokumentace k projektu /img

- obrázky - UML diagramy

instalacni-prirucka.pdf • /sql

- sql skript pro vytvo°ení databáze

• /src

- zdrojový kód systému

• /testing

- testovací soubory

/user

- pro uºivatelské webové rozrahní

/admin • /text

- pro administrátorské webové rozhraní

- tento text

• /readme.txt

- soubor s obsahem CD

59

Na tomto míst bude ociální zadání va²í práce

Recommend Documents