Náš "hudební portál" má teď všechny náležitosti stran správy
uživatelů vyřešené. Takže se směle můžeme pustit do opravdového
programování obsahu tohoto webu. Ještě než k tomu přistoupíme, ujasněme
si ale něco málo názvosloví a zorganizujem si práci.
Frontend a backend
Stojí za zmínku, že skoro všechny poloprofesionální až profesionální
weby s dynamickým obsahem skončí u koncepce "frontend-backend". To
jednoduše znamená, že existují stránky pro uživatele portálu (tedy
frontend), na nichž je zobrazeno to, co potřebuje návštěvník webu
vidět, a stránky pro administrátora, kde je zase naopak to, co
potřebuje ke vkládání dat (backend). Někde "mezi" tím vším jsou data k
zobrazení, převážně uložená v databázi. Celou situaci ilustruje
následující obrázek:
Mluvím o tom proto, že převážná většina naší další práce bude
střídavě práce na zobrazování položek na webu a střídavě práce na
administrační části. V našem případě to bude velmi jednoduché na
rozlišení - pokud bude přihlášený uživatel administrátorem, bude mít k
dispozici další nabídky pro zadávání informací do databáze.
Pozn.: Musíte si uvědomit jedno -
v závislosti na zadání práce může a nemusí být jedno, jak administrační
část vypadá. Takže někdy je možné ušetřit čas a prostředky tím, že
administrační část webu bude obsahovat pouze to nejnutnější a hlavní
úsilí se vloží do práce na webu.
Zadávání koncertů
Nejprve si připomeňme, co jsme si vytýčili jako požadavky pro
zadávání koncertů:
- Zadávat koncerty bude smět pouze uživatel s oprávněními
administrátora
- Z formuláře se zadá datum, čas a místo koncertu, to bude uloženo
v databázi
- Na webu se budou zobrazovat pouze koncerty v budoucnosti (ne ty,
co už byly)
- Aplikační logika by neměla povolit zadat více než jeden koncert
denně
... a začneme definicí tabulky databáze.Tabulka se bude jmenovat
koncerty, bude obsahovat automaticky číslované pole jako klíč, a pole
pro datum, čas a místo. Jelikož budeme chtít ukládat datum a čas do
dvou nesuvisejících sloupců, použijeme na jejich uložení v tabulce
sloupce typu date
a time.
Definiční příkaz pro tvorbu tabulky tedy bude vypadat následovně:
CREATE TABLE `koncerty` (
`id` INT NOT NULL AUTO_INCREMENT ,
`datum` DATE NOT NULL ,
`cas` TIME NOT NULL ,
`misto` VARCHAR( 50 ) NOT NULL ,
PRIMARY KEY ( `id` )
);
Práci na zadávání koncertů musíme chtě nechtě začít tím, že na webu
zajistíme zobrazení speciálních nabídek pro případ, že je přihlášen
administrátor. Takže, postup bude následující:
- Do databáze založíme uživatele a přidělíme mu oprávnění
administárora (asi ručně)
- Vytvoříme funkci, která pozná, že je přihlášen administrátor a
zobrazí "jeho" menu
- Následně do menu administrátora přidáme položku pro zadávání
koncertů
- Naprogramujeme skript zadejkoncert.php a odzkoušíme ho
Detekce administrátora
Ještě jedna důležitá věc. Je potřeba správně ošetřit, kam má přijít
funkce pro zjišťování, zda je daný uživatel administrátorem. Dejme
tomu, že napíšeme funkci jeadmin(), která vrátí TRUE v případě, že je
přihlášen uživatel a je to administrátor. Jedno řešení pak spočívá v
tom, že všechny administrátorské nabídky soustředíme do nějakého
skriptu (třeba admin.php) a někam do souboru index.php přidáme
následující řádek:
if (jeadmin()) require "admin.php";
To by však byla vážná bezpečnostní chyba! Proč? Protože kromě toho,
že by uživatel mohl nasměrovat prohlížeč na soubor index.php, mohl by
jej nasměrovat i na soubor admin.php (!). Tento problém jsme již v jiné
souvislosti řešili v díle o vkládání
souborů. Správná úvaha tedy je - nevzrušeně soubor admin.php do
skriptu index.php vložit a na začátek souboru admin.php napsat:
if (!jeadmin()) return;
Tím je zajištěno, že zbytek skriptu se provede pouze v případě, že
je přihlášen administrátor a nikdy jindy. Tok programu nadále pokračuje
dalšími instrukcemi, protože příkaz return narozdíl od die neukončuje
celý php stroj.
Pozn.: S trochou zdravého rozumu se na
to dá přijít, divili byste se však, kolik stránek obsahuje i takovouto
základní bezpečnostní chybu.
Funkci jeadmin() umístíme do souboru func.php, protože se zdá, že ji
budeme používat opakovaně.
Ověřování času
Když už jsme probrali tolik teoretických otázek, tak si dovolím na
závěr ještě jednu. Jak víte, data z formulářů by se měla ověřovat,
než se použijí. V souvislosti s tím nám vzniká zajímavý problém - jak
ověřit datum a čas, které budou uživatelé vkládat do databáze? Existuje
několik řešení, z nichž většina má výhody a nevýhody:
- Nechat databázi, ať se s tím popere. Nevýhoda je ta, že bychom
museli zachytávat chyby, vzniklé uložením dat do databáze, což není moc
dobré řešení
- Pokusit se testovat, zda předaná hodnota může reprezentovat
platné datum, a podle toho se zařídit.
- Striktně omezit formát zadávaného data a času a pak to stejně
striktně
kontrolovat. Nevýhoda je, že tím nutíme uživatele, aby se přizpůsobil
programátorovi
Podle všeho se zdá, že budeme muset použít tu poslední možnost,
protože ověřit, zda daný řetězec představuje platné české datum může
být pro PHP skutečný problém. Nicméně nám přijde vhod, že PHP obsahuje
funkci checkdate,
která převezme rok, měsíc a den a otestuje, zda to může představovat
existující datum v kalendáři.