Webové rozhraní pro přístup k databázi JIS

1. Webové rozhraní pro přístup k databázi JIS Václav Lederbuch 24.6.2003

2. Architektura JIS S S KK KS DB WWW S

3. Cíle • Odpoutat se od stávajícího řešení a vnést nový pohled na problematiku, • navrhnout odpovídající E-R-A model databáze, • zohlednit zkušenosti a potřeby, • brát v úvahu charakter zpracovávaných dat a obecnou heterogenitu prostředí, • zajistit odpovídající uživatelský komfort a uživatelské view.

4. Akce je podmíněna pěticí: • uživatel • skupina • místnost • snímač • časová zóna

5. Prostředky • PostgreSQL • Apache • PHP • SSL • Cookies • SHA1 fingerprints • !JavaScript, !Java, !Flash

6. Výsledky • Dostupný a zabezpečený interface. • Klientsky nenáročný. • Logovaný provoz: • snímačů • administrátorský • Uživatelsky homogenní, princip nejmenšího překvapení. • Celkem 568 kB kódu ve 126 souborech nad 16 tabulkami.

7. Webové rozhraní pro přístup k databázi JIS Václav Lederbuch 24.6.2003

8. Otázky pro diplomanta • Na str.8 je uvedena architektura protokolu SSL. Můžete ozřejmit, který z uvedených protokolů je přenosový a které jsou doplňkové? Existuje mezi protokoly nějaká těsnější vazba? RLP záhlaví Zásobník protokolů Šifrovaný komprimovaný fragment Typ dat Verze 3.0 Délka AP HP 1416 CCSP 1516 AP 1616 HP 1716 Aplikační data (HTTP) CCSP RLP

9. Otázky pro diplomanta • Na straně 11 autor tvrdí, že jazyk SQL je podskupinou DML, • na straně 13, kde autor vysvětluje pojem transakce, postrádám výčet základních, nepostradatelných vlastností transakce, • na obrázku 2.4 na straně 14 přistupují drivery do fyzické databáze přímo, nikoli přes databázový server, • na straně 18 je ukázka PHP skriptu, jehož úkolem je vyhledat adresy všech restauračních zařízení v Plzni, ve kterých je podáváno dvanáctistupňové pivo. SQL dotaz v tomto skriptu obsahuje syntaktickou chybu, $query = “SELECT adr FROM hospoda WHERE lokace=‘Plzeň’ AND toci LIKE %12% LIMIT 20”; toci LIKE ‘%12%’ toci LIKE %12% … toci=‘12’

10. Otázky pro diplomanta • v odstavci 2.4 věnovaném ověřování uživatelů mohl autor uvést problém jednotného přihlašovacího systému SSO – Single Sign On a zároveň vysvětlit princip LTPA – Lightweight Third Party Authentication, • tvrzení na straně 29, že „nelze dělat nic jiného, než důvěřovat metodě POST, že data nebudou zneužita třetí stranou.“ dle mého názoru není na místě, • v příloze A na straně 62, kde je zachycen E-R-A model báze dat je kardinalita všech vazeb tabulky Vazby obráceně,

11. Otázky pro diplomanta • na straně 35, kde je naznačen způsob ověření uživatele v protokolu HTTP, autor tvrdí, že tento způsob ověřování uživatelů je nedokumentován a že se mu nepodařilo zjistit, zda ověřovací data projdou zabezpečením ve vrstvě SSL. To je v rozporu s tvrzením v druhém odstavci podkapitoly 1.1 na straně 1, kde je uvedeno, že je kladen velký důraz na bezpečnost aplikace. Nicméně tento fakt lze jednoduše ověřit některým z volně dostupných analyzátorů síťových protokolů, ještě jednodušeji jej však lze odvodit z obrázku 2.1 na straně 6.