Upload
lyhuong
View
214
Download
0
Embed Size (px)
Citation preview
SVEUČILIŠTE U DUBROVNIKU
ODJEL ZA ELEKTROTEHNIKU I RAČUNARSTVO STUDIJ POSLOVNO RAČUNARSTVO
DIPLOMSKI RAD
HIBRIDNA WEB APLIKACIJA S DECENTRALIZIRANOM PROVJEROM IDENTITETA KORISNIKA
Mentor: Diplomant: dr. sc. Mario Miličević Tomo Sjekavica
Komentor: mr. sc. Krunoslav Žubrinić
Dubrovnik, srpanj 2010.
1
SAŽETAK U ovom radu opisana je realizacija hibridne web aplikacije koja kombinira Google
Maps API za prikaz mape i Picasa Web Album Data API za prikaz slika sa poslužiteljskom
aplikacijom za prikaz novosti, rezultata, podataka o igračima momčadi Palace i vaterpolo
utakmicama. Web aplikacija omogućava centraliziranu i decentraliziranu provjeru identiteta
korisnika. Hibridne web aplikacije kombiniraju funkcionalnost i podatke s više različitih web
stranica radi nastajanja nove jedinstvene aplikacije. Centralizirana provjera identiteta koristi
podatke o korisniku iz vlastite baze podataka, a decentralizirana koristi OpenID protokol. U
teorijskom dijelu rada je objašnjeno na koji način funkcioniraju hibridne web aplikacije, te je
napravljen pregled najpopularnijih API-ja. Pored toga su objašnjeni načini centralizirane i
decentralizirane provjere identiteta korisnika. U praktičnom dijelu rada opisan je model
sustava, te realizacija i korištenje web aplikacije izrađene na osnovu tog modela. Izgrađena
web aplikacija omogućuje svakom posjetitelju pregled novosti, rezultata, podataka o
igračima, te pregled odigranih vaterpolo utakmica pomoću sučelja mape. Korisnicima je
omogućena klasična registracija i prijava pomoću podataka zapisanih u vlastitoj bazi
podataka, te prijava pomoću OpenID protokola. Nakon prijave korisnicima je omogućeno
komentiranje novosti i ažuriranje vlastitih podataka. Osim korisnika na web aplikaciju se
mogu prijaviti i administratori koji imaju dodatne ovlasti za ažuriranje i brisanje podataka
drugih korisnika, te evidenciju, ažuriranje i brisanje drugih podataka sustava.
2
ABSTRACT
This thesis describes the implementation of the hybrid web application that combines
Google Maps and Picasa Web Album Data APIs with server application to display news,
results, information about players of team Palace and water polo matches. This web
application allows centralized and decentralized user authentication. Hybrid web applications
combine functionality and data from multiple web pages to build a new unique application.
Centralized authentication for authentication uses the user information from own database,
and decentralized authentication uses OpenID protocol. The first part describes the theoretical
background of hybrid web applications and a short overview of the most popular APIs.
Besides that, there is explained centralized and decentralized authentication of users. The
practical part describes the model of the system, its implementation and use of web
application built on that model. Developed web application allows each visitor a view to the
news, results, information about players and overview of played water polo matches. Users
can login in application using their local accounts or using OpenID protocol. After login,
users can post comments on news and update their own data. Except regular users,
administrators can also login to this web application. They have some additional privileges:
to update other users’ information, delete users and have permission to add, update or delete
other data stored in system.
3
SADRŽAJ
UVOD ........................................................................................................................................ 5
1 HIBRIDNE WEB APLIKACIJE ........................................................................................ 6
1.1 Hibridne web aplikacije i portali ................................................................................ 7
1.2 Tipologija hibridnih web aplikacija ........................................................................... 8
1.3 Arhitektura hibridnih web aplikacija ......................................................................... 8
1.4 Google Maps API i Yahoo Maps API ........................................................................ 9
1.5 Picasa Web Album Data API i Flickr API .............................................................. 12
2 PROVJERA IDENTITETA KORISNIKA ....................................................................... 14
2.1 Centralizirana provjera identiteta ............................................................................. 14
2.2 Decentralizirana provjera identiteta ......................................................................... 15
2.2.1 Model združenog identiteta .................................................................................. 16
2.2.2 OpenID protokol .................................................................................................. 18
3 MODEL WEB APLIKACIJE ........................................................................................... 20
3.1 Struktura web aplikacije .......................................................................................... 20
3.2 Funkcionalnost web aplikacije ................................................................................. 21
3.3 Dekompozicija sustava ............................................................................................ 22
3.4 Model procesa .......................................................................................................... 23
3.4.1 Dijagram konteksta .............................................................................................. 24
3.4.2 Pregledni dijagram ............................................................................................... 25
3.4.3 Razrada osnovnih procesa.................................................................................... 26
3.5 ERA model baze podataka ....................................................................................... 28
4 REALIZACIJA WEB APLIKACIJE ................................................................................ 30
4.1 Opis baze podataka .................................................................................................. 30
4.2 Opis poslužiteljskog dijela web aplikacije ............................................................... 32
4.2.1 Registracija novih korisnika ................................................................................ 32
4.2.2 Centralizirana provjera identiteta ......................................................................... 33
4
4.2.3 Decentralizirana provjera identiteta ..................................................................... 33
4.2.4 Ažuriranje korisničkih podataka .......................................................................... 35
4.2.5 Administracija korisnika ...................................................................................... 35
4.2.6 Administracija novosti ......................................................................................... 36
4.2.7 Administracija igrača ........................................................................................... 38
4.2.8 Komentiranje novosti ........................................................................................... 38
4.3 Hibridni dio web aplikacije ...................................................................................... 39
4.3.1 Pohrana i prikaz mape .......................................................................................... 39
4.3.2 Pohrana i prikaz slika ........................................................................................... 40
4.4 Iskustva u izradi aplikacije ....................................................................................... 42
5 KORIŠTENJE WEB APLIKACIJE.................................................................................. 44
5.1 Registracija novog korisnika .................................................................................... 44
5.2 Prijava pomoću OpenID protokola .......................................................................... 45
5.3 Administracija web aplikacije .................................................................................. 48
5.3.1 Administracija korisnika ...................................................................................... 49
5.3.2 Administracija novosti ......................................................................................... 50
5.3.3 Administracija momčadi ...................................................................................... 52
5.3.4 Administracija rezultata ....................................................................................... 53
5.4 Komentiranje novosti ............................................................................................... 54
ZAKLJUČAK .......................................................................................................................... 55
LITERATURA ........................................................................................................................ 56
POPIS SLIKA .......................................................................................................................... 59
5
UVOD
Razvojem i popularizacijom Interneta kao medija, sve se više događaja evidentira i
prati putem web stranica. Radi poboljšavanja sadržaja i donošenja više korisnih informacija
posjetiteljima web stranice, koriste se razni API-ji, i stvaraju hibridne web aplikacije.
Hibridne web aplikacije su aplikacije koje kombiniraju funkcionalnost ili podatke više
različitih vanjskih izvora čime nastaje nova aplikacija s dodatnom funkcionalnošću. Kao
vanjski izvor najčešće se koriste gotovi API-ji. Kao izvor podataka pored API-ja mogu se
koristiti i XML datoteke, web feedovi ili Javascript skripte. Trenutno (lipanj 2010. godine)
najpopularniji API-ji koji se koriste za izradu hibridnih web aplikacija su API-ji za rad s
geografskim mapama [26]. Postoji više API-ja koji omogućavaju rad s mapama: Google
Maps [18], Yahoo Maps [28], Mapquest i Microsoft MapPoint, a najpopularniji je Google
Maps API. Od ostalih vrsta API-ja često se koriste i API-ji za rad sa slikama kao što su Flickr
[15], Picasa Web Album Data [23], Panoramio [24] i Photobucket [25].
Da bi se korisnici mogli prijaviti u web aplikaciju moraju proći proces provjere
identiteta. Postoje dvije vrste provjere identiteta, a to su centralizirana i decentralizirana. Za
provjeru identiteta korisnika kod centralizirane provjere brine se samostalno web aplikacija
čiji se podaci najčešće zapisuju u neku bazu podataka. Kod decentralizirane provjere, za
provjeru identiteta korisnika odgovorna je treća strana kojoj vjeruju i korisnik i usluga kojoj
korisnik želi pristupiti. Koristeći taj pristup korisnik se identificira samo jednom kod svog
davatelja identiteta, te nakon toga može pristupiti različitim uslugama i web stranicama s
istim identitetom. Najpoznatiji protokoli koji se koriste za decentraliziranu autentifikaciju su:
OpenID [22], SAML [27], i InfoCard [10]. OpenID je trenutno najrašireniji i najčešće
korišteni protokol za decentraliziranu provjeru identiteta na webu, te ga prihvaćaju brojne
poznate Internetske kompanije kao što su Google, Yahoo, Facebook i Microsoft [22].
U ovom radu opisana je tehnologija i način realizacije hibridne web aplikacije koja
koristi dva vanjska API-ja. U prvom dijelu opisan je koncept hibridne aplikacije i API-ji koji
se koriste u praktičnom dijelu rada. Provođenje provjere identiteta s naglaskom na
decentraliziranu provjeru korištenjem OpenId protokola opisano je u drugom poglavlju.
Model izrađenog sustava opisan je u trećem poglavlju, a način na koji je sustav praktično
realiziran razrađen je u četvrtom poglavlju. U petom poglavlju na praktičnom primjeru je
prikazan način korištenja izrađene aplikacije.
6
1 HIBRIDNE WEB APLIKACIJE
Hibridne web aplikacije su web aplikacije koje kombiniraju podatke ili funkcionalnost
iz više vanjskih izvora pri čemu se stvara nova jedinstvena aplikacija [32]. Hibridne web
aplikacije često se još nazivaju i mashup aplikacije. Sadržaj koji se koristi kod hibridnih web
aplikacija najčešće dolazi kao rezultat korištenja nekog API-ja [29], ali može dolaziti i iz web
feedova (RSS ili Atom), kao rezultat izvođenja Javascript programa ili iz XML datoteke. RSS
(Really Simple Syndication) je skup formata za prikaz web feedova, baziranih na XML-u koji
određuje oblik prikazivanja sadržaja. Taj format se koristi na web stranicama koje se često
ažuriraju, a omogućuju korisniku pristup novim i promijenjenim sadržajima iz okruženja RSS
čitača, bez potrebe za odlaskom na web stranicu [34]. Naziv Atom se odnosi na par povezanih
standarda. Atom Syndication Format je XML jezik koji se koristi za stvaranje i prikaz web
feedova, a Atom Publishing Protocol (AtomPub ili APP) je jednostavni HTTP bazirani
protokol za kreiranje i ažuriranje web resursa [30].
Na slici 1 prikazan je način rada jednostavne hibridne web aplikacije koja za svoje
funkcioniranje koristi dva API-ja smještena na dvije različite web stranice.
Slika 1 Način rada jedne jednostavne hibridne web aplikacije
Hibridna web aplikacija prima i obrađuje zahtjev korisnika. U programskoj logici
aplikacije opisano je što treba odraditi i koje API-je treba pozvati. Nakon što protumači te
informacije, poziva API-je koji se nalaze na dvije različite web stranice i služe za dohvaćanje
podataka iz dva različita izvora. Komunikacija je obično asinkrona, odnosno aplikacija šalje
7
upite API-jima, i nakon toga nastavlja normalno funkcionirati. Nakon što određeni API vrati
tražene podatke hibridnoj web aplikaciji, ona ih obrađuje i prikazuje u traženom obliku.
Aplikacija može prikazati izravno primljene podatke ili ih kombinirati te stvoriti nove
informacije koje ne postoje u niti jednom od dva pozvana API-ja.
1.1 Hibridne web aplikacije i portali
Hibridne web aplikacije i portali su tehnologije za prikaz sadržaja. Portali koriste
stariju web tehnologiju te su dodatak tradicionalnom klijentsko-poslužiteljskom modelu
weba, dok hibridne web aplikacije koriste novu Web 2.0 [35] tehnologiju i način rada.
Skupljanje sadržaja na portalu može se podijeliti na dvije faze: generiranje dijelova
sadržaja i smještanje tih dijelova na odgovarajuće dijelove web stranice. Svaki dio sadržaja
generira se pomoću portleta [19], a portal ih spaja u jednu web stranicu. Portlet je aplikacijski
element portala koji služi za generiranje i oblikovanje sadržaja na portalu. Za razliku od
portala, hibridne web aplikacije koriste API-je ili web feedove s različitih web stranica radi
skupljanja i korištenja sadržaja. Portali najčešće prikazuju sadržaj oblikovan prezentacijskim
jezicima poput HTML-a, WML-a ili VoiceXML-a. Hibridne web aplikacije mogu koristiti
čisti XML sadržaj, ali i prezentacijsko orijentirani sadržaj poput HTML-a.
Prikupljanje sadržaja za objavu kod portala isključivo se odvija na poslužitelju, a kod
hibridnih web aplikacija može se odvijati na poslužitelju ili na računalu klijenta. Kod portala
sakupljeni sadržaji se prezentiraju paralelno bez preklapanja ili miješanja. Kod hibridnih web
aplikacija različiti sadržaji se mogu međusobno kombinirati na različite načine, što rezultira
novim, hibridnim sadržajem.
Stvaranje i održavanje podataka na portalima obavlja se specifičnim funkcijama
definiranima unutar portleta. Kod hibridnih web aplikacija za pristup podacima najčešće se
koriste klasične CRUD operacije (create, read, update i delete) bazirane na REST
(Representational State Transfer) arhitektonskim načelima. REST je stil programske
arhitekture koji je pogodan za korištenje u distribuiranim hipermedijskim sustavima [4].
Funkcionalnost i izgled portala nisu definirani nikakvim standardom, dok je ponašanje
portleta uređeno JSR 168 [19], JSR 286 [19] i WSRP [37] standardima. Kod izrade hibridnih
web aplikacija još uvijek nisu specificirani nikakvi standardi, a za prijenos podataka najčešće
se koristi XML format. Podaci se dohvaćaju korištenjem REST-a ili web servisima, ili u
obliku RSS i Atom feedova.
8
1.2 Tipologija hibridnih web aplikacija
Postoji više različitih vrsta hibridnih web aplikacija koje se razlikuju po svojoj
funkcionalnosti i mjestu na kojem se izvršavaju [9] [21].
Prezentacijske hibridne aplikacije (engl. presentation mashups) su aplikacije koje
prikupljaju i obrađuju podatke iz različitih izvora. Ova vrsta hibridnih aplikacija po svojoj
funkcionalnosti je najsličnija portletima u klasičnim portalima, a razlika je što za ostvarenje
funkcionalnosti dohvata podataka koristi vanjske API-je.
Klijentske hibridne aplikacije su prave hibridne aplikacije koje svoju funkcionalnost
daju svakom korisniku unutar njegovog web preglednika. Klijentska hibridna aplikacija za
obradu podataka (engl. client-side software mashup) je aplikacija koja se izvršava na
klijentskom računalu, a kombinira funkcionalnost vanjskih API-ja stvarajući klijentsku
aplikaciju s novom funkcionalnošću. Te aplikacije su obično izrađene u nekom skriptnom
jeziku koji se može izvoditi unutar web preglednika. Klijentska podatkovna hibridna
aplikacija (engl. client-side data mashup) izvršava se na klijentskom računalu, a dohvaća
podatke korištenjem vanjskih API-ja ili web feedova te ih kombinira stvarajući novu
informaciju koja do tada nije postojala. Ovu vrstu hibridnih aplikacija vrlo je jednostavno
ostvariti međusobnim povezivanjem podataka dostupnih iz vanjskih izvora pomoću web
feedova.
Poslužiteljske hibridne web aplikacije izvršavaju se na web poslužitelju, a po svom načinu
funkcioniranja predstavljaju prave poslužiteljske aplikacije. Razlika je u tome što u svom
radu koriste način na koji funkcioniraju hibridne aplikacije te za obradu i dohvat podataka
koriste vanjske API-je i web feedove. Poslužiteljska hibridna aplikacija za obradu podataka
(engl. server-side software mashup) stvara novu funkcionalnost, a poslužiteljska podatkovna
hibridna aplikacija (engl. server-side software mashup) prikuplja informacije iz različitih
izvora podataka, te ih kombinira stvarajući nove informacije.
1.3 Arhitektura hibridnih web aplikacija
Po svojoj arhitekturi hibridne web aplikacije se mogu podijeliti na aplikacije
temeljene na klijentu i na poslužitelju [32]. Hibridne web aplikacije temeljene na klijentu
koriste web preglednik korisnika za prikupljanje sadržaja i njegovo prezentiranje. Kod
hibridnih aplikacija temeljenih na poslužiteljskoj tehnologiji, sadržaj se prikuplja, sastavlja i
9
analizira na poslužitelju, te se nakon toga šalje u web preglednik korisnika u konačnom
obliku.
Na slici 2 prikazana je arhitektura hibridne web aplikacije.
Slika 2 Arhitektura hibridne web aplikacije
U hibridnoj web aplikaciji korištenjem API-ja može se dohvatiti i pomiješati više
vrsta različitih podataka. Ulazni podaci obično se dobivaju koristeći API neke treće strane ili
web feed. Novu vrijednost i značenje hibridnoj web aplikaciji daje isključivo tvorac te
aplikacije pošto on odlučuje na koji način će se podaci miješati i kombinirati, te na koji način
će se predstaviti konačni rezultat. Komunikacija između klijenta i poslužitelja u hibridnim
aplikacijama obično se bazira asinkrono. Razlog je taj što podaci dolaze iz različitih vanjskih
izvora pa se pri dohvatu podataka mogu javljati veliki zastoji. Ako bi obrada bila sinkrona,
korisnik bi morao za izvršenje slijedeće akcije čekati da prvo pristignu svi podaci iz svih
izvora. Ako podaci iz nekog izvora kasne, onda će korisnik besposleno čekati. Asinkrona
komunikacija rješava taj problem i omogućuje korisniku da normalno nastavi svoj posao, a
podaci će se obraditi i prikazati onda kada stignu.
1.4 Google Maps API i Yahoo Maps API
Google Maps API je trenutno najpopularniji API u zajednici koja razvija hibridne
web aplikacije (lipanj 2010.) [26], a koristi se za ugrađivanje Google mapa na web stranice i
u web aplikacije koristeći Javascript ili Flash tehnologiju. Google mape su prvo bile bazirane
na tehnologiji mapa tvrtke Navteq, a kasnije prelaze na tehnologiji tvrtke Tele Atlas, koju još
uvijek koriste. Za ugradnju Google mape na vlastitu web stranicu potrebno je imati otvoren
10
Google korisnički račun pomoću kojeg se može dobiti besplatni ključ za korištenje tog
API-ja. Dobiveni ključ vrijedi samo za jednu domenu koja se unosi prilikom ispunjavanja
zahtjeva za ključem. Postoje četiri vrste prikaza mape, a to su: normalna, satelitska, hibridna
te mapa terena. Mapa sadrži kontrole za pomicanje, zumiranje i pregled mape te mjerilo. Na
mapu se mogu dodavati markeri (standardni i prilagođeni), polilinije i poligoni. Google Maps
API podržava geokodiranje i obrnuto geokodiranje. Ne postoji dnevno ograničenje broja
posjeta stranici koja sadrži Google mapu kao ni dnevno ograničenje broja zahtjeva za
geokodiranjem [18].
Yahoo Maps API podržava tri načina za ugradnju mapa na vlastite web stranice, a to
su: Maps Image API, Flash API i Ajax API. Yahoo mape koriste tehnologiju mapa tvrtke
Navteq. Za korištenje Yahoo Maps API-ja potrebno je imati Yahoo korisnički račun da bi se
dobio Application ID ključ za mapu. Za dobivanje ključa potrebno je unijeti podatke o sebi i
o aplikaciji koja se pravi. Kod Yahoo Maps API-ja postoje samo tri vrste prikaza (normalna,
satelitska i hibridna mapa). Također se mogu dodavati standardni i prilagođeni markeri,
polilinije i poligoni. Na mapu se mogu postaviti kontrole za pomicanje i zumiranje, te
mjerilo. Yahoo Maps API također podržava geokodiranje i obrnuto geokodiranje. Maps
Image API nema ograničenje dnevnog broja zahtjeva za geokodiranjem, dok je kod Flash
API-ja i Ajax API-ja dozvoljeno 50.000 zahtjeva za geokodiranjem dnevno [28].
Google Maps API i Yahoo Maps API imaju dosta sličnosti, te je rad s oba API-ja
jednostavan. Bolju dokumentaciju, te više web stranica sa vodičima i uputama za rad s
API-jem ima Google Maps API.
Pokretanje Google mape je puno brže od pokretanja Yahoo mape. Google Maps API
ima 20 stupnjeva zumiranja, dok Yahoo Maps API ima samo 16 stupnjeva zumiranja. Google
Maps API podržava veći stupanj zumiranja na velikom dijelu mape pri radu sa prikazom
satelitske i hibridne mape dok se korištenjem Yahoo Maps API-ja do većeg stupnja zumiranja
pri korištenju prikaza satelitske ili hibridne mape može doći samo na područjima veće
naseljenosti. Razina detalja i ažurnost sadržaja mape je puno bolja kod Google Maps API-ja.
11
Na slici 3 je prikazana razlika u detaljima između Google Maps API-ja i Yahoo Maps
API-ja za normalni, satelitski i hibridni način prikaza za područje grada Dubrovnika.
Slika 3 Usporedba normalne, satelitske i hibridne Google (a, c, e) i Yahoo mape (b, d, f)
Na slikama 3.a i 3.b prikazane su mape korištenjem Google Maps API-ja, odnosno
Yahoo Maps API-ja. Na Googleovoj mapi se vide obližnji otoci Daksa i Grebeni, što nije
slučaj kod Yahoove mape. Yahoova mapa pri normalnom prikazu nudi više detalja od
Googleove, što je vidljivo na kopnenom dijelu mape. Najveći stupanj zumiranja za područje
Dubrovnika za Yahoovoj mapi pri korištenju satelitskog i hibridnog prikaza mape je prikazan
na slikama 3.d i 3.f. Na slikama 3.c i 3.e je prikazana Googleova mapa sa satelitskim i
hibridnim prikazom. Na tim je slikama se vidi puno veći broj detalja. Pored toga Googleova
12
mapa se može zumirati za dodatnih 5 stupnjeva kod satelitskog i hibridnog prikaza mape za
područje Dubrovnika.
1.5 Picasa Web Album Data API i Flickr API
Picasa Web Album Data API je Googleov API koji dopušta korisnicima integriranje
albuma slika u web stranice i aplikacije. Ovaj API dopušta ažuriranje i pregled albuma, slika,
fotografija i komentara u formi Google Data API feedova. Moguće je dodavanje opisa slika,
označavanje ljudi na fotografijama, kao i označavanje lokacija na mapi za slike. Da bi
korisnik mogao raditi s tim API-jem treba imati otvoren Google račun. Trenutno (lipanj
2010.) je besplatno moguće koristiti 1024 MB prostora za pohranu slika ili fotografija, a uz
nadoplatu je moguće povećati prostor za pohranu slika ili fotografija [23].
Flickr API je trenutno najpopularniji API za fotografije. To je API tvrtke Yahoo za
pohranu slika, fotografija i videa. Za njegovo korištenje potrebno je imati otvoren Yahoo
korisnički račun. Pohranjene slike i fotografije se mogu ažurirati, pregledavati i komentirati.
Slikama i fotografijama se mogu dodavati opisi i korisničke oznake (engl. tag), te se mogu
označavati lokacije na mapi za slike. Moguće je besplatno pohraniti dva videa maksimalne
veličine 150 MB svaki, te 100 MB slika ili fotografija mjesečno. Usluga se uz nadoplatu
može nadograditi čime se dobiva mogućnost postavljanja neograničenog broja slika,
fotografija i videa, kao i mogućnost prikaza videa u HD formatu [15].
Na slici 4 prikazana je struktura Picasa i Flickr servisa za pohranu fotografija.
Slika 4. Struktura Picasa i Flickr servisa
Picasa i Flickr su vrlo slični. U besplatnoj verziji se kod Picase može koristiti ukupno
1024 MB prostora, dok se kod Flickra može koristiti 100 MB svaki mjesec. Kako se na kraju
13
svakog mjeseca poništava brojač iskorištenog prostora, to znači da se kod Flickra u
besplatnoj verziji može praktički koristiti neograničen prostor za pohranu slika ili fotografija.
Prilikom postavljanja slika kod Picase se prvo mora napraviti novi album ili odabrati
postojeći album u kojem će se čuvati slike. Odjednom je u album moguće postaviti 5 slika.
Ako se želi postaviti više slika potrebno ih je umetati kroz više ponavljanja. Kod Flickra se
odjednom može postaviti neograničen broj slika.
Nakon postavljanja, slike se mogu dodati u setove od kojih se mogu stvarati kolekcije.
Setovi kod Flickra su isto što su albumi kod Picase. Mogućnost dodavanja setova u kolekcije
kod Flickra je dodatna mogućnost koja još uvijek ne postoji kod Picase.
I kod Picase i kod Flickra mogu se označiti lokacije na mapi za slike. Picasa nudi i
mogućnost označavanja ljudi na fotografijama. Pomoću te opcije korisnici mogu povezati lica
na fotografijama s informacijama o kontaktu iz njihovog Gmail računa. Kod Flickra još
uvijek ne postoji mogućnost označavanja ljudi na fotografijama.
14
2 PROVJERA IDENTITETA KORISNIKA
Provjera identiteta korisnika predstavlja proces kojim se utvrđuje identitet nekog
korisnika, a to je jedan od najvažnijih elemenata svakog sustava koji sadrži podatke koji ne bi
smjeli biti dostupni svim korisnicima tog sustava [7]. U tom procesu od korisnika se traži da
dokaže da je on upravo ta osoba za koju se predstavlja. Najčešće se provjera identiteta
provodi unosom korisničkog imena i lozinke. Kod nekih sustava umjesto korisničkog imena
koristi se e-mail adresa korisnika, dok neki sustavi koriste dodatne metode kako bi povećali
sigurnost transakcija poput generiranja jednokratne lozinke pri svakoj provjeri i sl. Podaci
koje unese korisnik uspoređuju se s popisom korisnika sustava i lozinki zapisanih u datoteci
ili bazi podataka. Ovakav način provjere identiteta korisnika naziva se centralizirana provjera
identiteta. Drugi način provjere identiteta korisnika naziva se decentralizirana provjera i kod
nje je za provjeru identiteta korisnika zadužena treća strana.
2.1 Centralizirana provjera identiteta
Centralizirana provjera identiteta korisnika je način provjere identiteta kod kojeg se
svaka web aplikacija mora samostalno brinuti za identitet svojih korisnika.
Centralizirani način provjere identiteta predstavlja dodatne troškove za vlasnike
aplikacije jer je tijekom realizacije sustava potrebno ugraditi i jak sigurnosni sustav za
provjeru identiteta unutar same web aplikacije. Nedostatak ovakvog načina provjere sa strane
korisnika je u tome što se korisnici moraju registrirati da bi mogli koristiti usluge web
aplikacije. Prilikom registracije moraju unijeti neke osobne podatke kao i željeno korisničko
ime i lozinku koje će koristiti za prijavu na tu web aplikaciju. Registracijom na više web
aplikacija korisnici moraju pamtiti različita korisnička imena, ako žele biti sigurniji i različite
lozinke za prijavu u svaku pojedinu aplikaciju. Prilikom pristupa pojedinoj web aplikaciji,
korisniku se javlja problem prisjećanja korisničkog imena i lozinke koji se koriste za pristup
određenoj aplikaciji.
15
Na slici 5 prikazan je model centralizirane provjere identiteta korisnika.
Slika 5. Model centralizirane provjere identiteta korisnika
Na modelu prikazanom na slici vidi se da korisnik ima posebne identitete kod svakog
pojedinog davatelja usluge (SP). Svaki davatelj usluge također ima i ulogu davatelja
identiteta (IdP). Korisnik može koristiti isto korisničko ime i istu lozinku kod svakog
davatelja usluge, ali kako su korisnički računi nezavisni oni se koriste zasebno za svakog
davatelja usluge [5]. Kada korisnik želi koristiti usluge jednog davatelja usluge treba se
prijaviti pomoću svojih korisničkih podataka kod tog davatelja. Ako kasnije želi pristupiti
uslugama nekog drugog davatelja usluge, mora se ponovno prijavljivati i kod tog davatelja
usluge s onim korisničkim podacima koje ima kod tog davatelja.
2.2 Decentralizirana provjera identiteta
Decentralizirana provjera identiteta je alternativni pristup provjeri identiteta korisnika
kod kojeg se upravljanje identitetom korisnika može odvijati na razini čitavog weba. Takva
ideja odgovara Web 2.0 konceptu, te je poznata pod nazivom Identity 2.0 [31]. Identity 2.0 je
model združenog identiteta (engl. federated identity) i zahtjeva pomoć treće strane pri
povezivanju korisnika s uslugom. Ta treća strana je odgovorna za identifikaciju korisnika na
razini čitavog weba, a ne na razini pojedine aplikacije.
Ovakav pristup prijavi korisnika se je poznat pod nazivom jednostruka prijava (engl.
Single Sign On – SSO) [6][8]. Pomoću ovog pristupa korisnici se identificiraju samo jednom
16
i nakon toga mogu pristupiti različitim uslugama i web stranicama koristeći isti identitet [6].
Glavne prednosti ovog pristupa su u tome što korisnik treba pamtiti samo jedno korisničko
ime i lozinku, te što se smanjuju troškovi razvoja, uvođenja i održavanja web aplikacije jer su
za utvrđivanje identiteta zadužene posebni davatelji i u web aplikaciju nije potrebno
ugrađivati jake sigurnosne mehanizme nužne za provođenje provjere identiteta.
2.2.1 Model združenog identiteta
U modelu združenog identiteta, proces jednostruke prijave se sastoji se od četiri
komponente [6][8]
• Korisnik - To je osoba koja preuzima određeni digitalni identitet radi
identifikacije prilikom rada s nekom web aplikacijom;
• Posrednik (engl. user agent) – To je web preglednik ili neka druga aplikacija
koja se može pokretati na računalu ili mobilnom uređaju, a zadužena je za
automatsko prosljeđivanje podataka o identitetu korisnika;
• Davatelj usluge (engl. service provider - SP) – To je web aplikacija koja
zahtjeva provjeru identiteta korisnika kako bi korisnik mogao koristiti njezine
usluge;
• Davatelj identiteta (engl. identity provider – IdP) – To je web aplikacija na koju
se prijavljuje korisnik i koja čuva podatke o njemu kako bi ih mogla dijeliti sa
onim davateljima usluga na koje se korisnik prijavljuje i kojima korisnik
dozvoljava korištenje svojih podataka.
Kod jednostruke prijave podaci o identitetu korisnika se prenose između davatelja
identiteta i različitih davatelja usluga, a postoje dva osnovna načina na koji se može pokrenuti
utvrđivanje identiteta. Taj proces može pokrenuti davatelj usluge ili davatelj identiteta.
17
Na slici 6 prikazan je proces utvrđivanja identiteta korisnika pokrenut od strane
davatelja usluge.
Slika 6 Utvrđivanje identiteta korisnika - pokrenuto od davatelja usluge
U prvom koraku korisnik šalje zahtjev za uslugom davatelju usluge (1). Davatelj
usluge prima taj zahtjev, i šalje posredniku zahtjev za provjerom identiteta (2). Posrednik
nakon toga prosljeđuje taj zahtjev davatelju identiteta (3). Davatelj identiteta obrađuje
primljeni zahtjev, generira rezultat provjere i šalje taj rezultat posredniku (4). Zatim
posrednik prosljeđuje rezultat provjere identiteta davatelju usluge (5). Davatelj usluge na
osnovu primljenih pozitivnih rezultata provjere korisnika preusmjerava na traženu uslugu (6)
[6].
Na slici 7 prikazan je proces utvrđivanje identiteta korisnika pokrenut od strane
davatelja identiteta.
Slika 7 Utvrđivanje identiteta korisnika - pokrenuto od davatelja identiteta
Davatelj identiteta na svojoj stranici ima linkove prema željenim uslugama. Na početku
korisnik pristupa davatelju identiteta (1). Davatelj identiteta šalje korisniku zahtjev za
davatelj usluge
davatelj identiteta
korisnik
posrednik
(1)
(2)
(5)
(6)
(3)
(4)
davatelj usluge
davatelj identiteta
korisnik
posrednik
(1)
(2)
(5)(6)
(3)
(4)
(7)
18
provjerom identiteta (2). Korisnik pruža davatelju identiteta svoje identifikacijske podatke
(3), a nakon toga korisnik zahtjeva željenu uslugu davatelja usluga pristupom linkovima koji
se nalaze na stranici davatelja identiteta (4). Davatelj identiteta kreira žetone (engl. token) za
provjeru identiteta, te ih šalje posredniku (5) koji ih dalje prosljeđuje davatelju usluge (6).
Nakon što davatelj usluge primi žetone provjerava ima li korisnik pravo pristupa traženoj
usluzi i ako ima, korisnika preusmjerava na tu uslugu (7) [6].
Trenutno najpopularniji protokol koji se koristi za decentraliziranu provjeru identiteta u
web okruženju je OpenID. Od ostalih protokola koji se koriste za istu namjenu poznatiji su
SAML (Security Assertion Markup Language) i InfoCard. SAML predstavlja Oasisov
standard koji je baziran na XML-u, te se koristi za razmjenu sigurnosnih podataka između
dviju poslovnih strana. InfoCard je Microsoft .NET standard koji se koristi za provjeru
identiteta korisnika u Microsoft .NET aplikacijama. InfoCard koristi Microsoft .NET
komponentu Windows CardSpace [36], koja pruža korisnicima dosljedan digitalni identitet.
2.2.2 OpenID protokol
Razvoj OpenID protokola započeo je u ljeto 2005. godine s ciljem rješavanja problema
provjere identiteta korisnika prilikom prijave na razne web aplikacije. Razvio ga je Brad
Fitzpatrick, koji je ujedno i kreator popularne društvene web stranice LiveJournal [33].
Danas bilo koji korisnik može koristiti OpenID, a autori web aplikacija mogu besplatno
ugraditi podršku provjeri identiteta korisnika u svojoj web aplikaciji pomoću OpenID-a. Sve
više i više web stranica podržava prijavu pomoću OpenID-a. Prema podacima na službenoj
web stranici OpenID-a trenutno (lipanj 2010.) postoji preko milijardu otvorenih OpenID
računa, a postoji i preko 50.000 web stranica koje omogućavaju prijavu pomoću OpenID-a
[22]. Neke od najvećih Internetskih kompanija poput Googlea, Yahooa, Facebooka,
Microsofta, AOLa i MySpacea izdaju ili prihvaćaju OpenID.
19
Na slici 8 prikazan je proces provjere identiteta pomoću OpenID protokola.
Slika 8 Proces provjere identiteta pomoću OpenID protokola
Na početku prijave korisnik pristupa web stranici davatelja usluge i unosi svoju
OpenID oznaku (1). Pomoću unesene OpenID oznake davatelj usluge pronalazi URL OpenID
servisa (2). Davatelj usluge i davatelj OpenID identiteta stvaraju vezu. Ovaj korak nije
obavezan, ali se preporučuje zbog uspostavljanja sigurne veze koristeći Diffie-Hellmanovu
razmjenu ključeva. Davatelj OpenID identiteta koristi tu vezu za potpisivanje naknadnih
poruka, a davatelj usluge ju koristi za ovjeravanje poruka. Ako se izostavi ovaj korak davatelj
usluge bi trebao poslati naknadne direktne zahtjeve za provjeru potpisa nakon svakog
odgovora od strane davatelja OpenID identiteta (3). Davatelj usluge kreira zahtjev za OpenID
provjerom identiteta, te preusmjerava posrednika davatelju OpenID identiteta (4). Nakon toga
davatelj OpenID identiteta utvrđuje da li je korisnik ovlašten za izvođenje OpenID provjere
identiteta ili nije (5). Po provedenoj provjeri, davatelj OpenID identiteta preusmjerava
posrednika natrag davatelju usluge s odgovorom koji nosi rezultat provedene provjere (6). Na
kraju davatelj usluge ovjerava primljene podatke (7) i ovisno o rezultatu primljene poruke
dozvoljava korisniku pristup traženoj usluzi ili ga sprječava [6].
20
3 MODEL WEB APLIKACIJE
Model web aplikacije služi za prikaz strukture planirane aplikacije i za opis njenih
osnovnih funkcionalnosti i strukture podataka koje koristi. Na osnovu ovog modela trebala bi
biti moguća realizacija web aplikacije neovisno o razvojnom okruženju i korištenoj bazi
podataka.
3.1 Struktura web aplikacije
Ovaj sustav je zamišljen kao hibridna web aplikacija koja se sastoji od klijentskog i
poslužiteljskog dijela. Na slici 9 prikazana je struktura ove aplikacije.
Slika 9 Struktura web aplikacije
Poslužiteljski dio web aplikacije koristi Google Maps API za stvaranje i pohranu mape s
lokacijama odigravanja utakmica, Picasa Web Albums Data API za uređivanje i pohranu
slika, te vlastitu poslužiteljsku aplikaciju za prikaz i pohranu podataka o utakmicama,
novostima, igračima i rezultatima. Korisnici pristupaju ovoj web aplikaciji pomoću web
preglednika na svom računalu, a prezentacijski dio rađen je korištenjem klijentskih
tehnologija HTML-a, CSS-a i Javascripta, a prikaz dijela podataka vrši se na asinkroni način
korištenjem AJAX tehnologije. Dinamički podaci stvoreni na poslužitelju prikazuju se
pomoću Google Maps i Picasa Web Albums Data API-ja. Za provjeru identiteta korisnika u
ovoj aplikaciji koriste se i centralizirani i decentralizirani pristup. Centralizirana provjera
21
identiteta koristi podatke iz vlastite baze podataka, dok se za decentraliziranu koristi OpenID
protokol.
3.2 Funkcionalnost web aplikacije
Ponašanje i funkcionalnost sustava sa stajališta korisnika opisani su UML dijagramom
slučajeva korištenja (engl. use case diagram). Glavni dijelovi dijagrama slučajeva korištenja
su sudionici i slučajevi korištenja. Sudionik predstavlja osobu ili drugi sustav koji vrši
interakciju s promatranim sustavom. Slučaj korištenja opisuje niz akcija koje sustav izvršava,
ali ne specificira na koji način ih izvršava [1].
Na dijagramu slučajeva korištenja prikazanom na slici 10 vidljiva je osnovna
funkcionalnost koju treba zadovoljiti ova web aplikacija.
Slika 10 Dijagram slučajeva korištenja
Svi posjetitelji web aplikacije, kao i njezini korisnici i administratori mogu pregledavati
novosti, igrače i rezultate utakmica. Da bi posjetitelj postao korisnik treba se registrirati ili
prijaviti pomoću svog OpenID računa. Nakon registracije posjetitelj postaje korisnik, te
dobiva ovlasti da može komentirati novosti. Pored toga korisnik može mijenjati i svoje
22
podatke koje je unio prilikom registracije. Administrator osim svih do sada navedenih
funkcija može još i ažurirati podatke ostalih korisnika, brisati korisnike, te dodavati, brisati i
ažurirati novosti, igrače i rezultate.
3.3 Dekompozicija sustava
Funkcionalnost ove web aplikacije se može podijeliti na nekoliko podsustava, a to su:
pregledavanje podataka, registracija korisnika i administracija sustava.
Na slici 11 je prikazan je dijagram dekompozicije koji prikazuje navedene funkcije
web aplikacije.
Slika 11 Dijagram dekompozicije funkcija web aplikacije
administracija
web aplikacija
ažuriranje vlastitih
korisničkih podataka
komentiranje novosti
dodavanje novosti
ažuriranje podataka
ostalih korisnika
ažuriranje novosti
brisanje novosti
dodavanje igrača
ažuriranje igrača
brisanje igrača
dodavanje rezultata
ažuriranje rezultata
brisanje rezultata
brisanje korisnika
administra-cija novosti
administra-cija igrača
administra-cija rezultata
pregledavanje
pregled novosti
pregled igrača
pregled rezultata
registracija
registracija novog
korisnika
administra-cija korisnika
prva OpenID prijava
23
Na dijagramu su osnovne funkcije razrađene u detaljnije funkcije. Prilikom realizacije
konkretne web aplikacije ona unutar sebe treba imati ugrađene funkcije kojima se može
zadovoljiti kompletna ovdje prikazana funkcionalnost sustava.
3.4 Model procesa
Model procesa prikazuje komunikaciju vanjskih entiteta sa sustavom. Prema složenosti
prikaza može se podijeliti na tri razine: dijagram konteksta, pregledni dijagram i dijagram
razrade osnovnih procesa.
U komunikaciji s procesima ove web aplikacije sudjeluju tri vanjska entiteta:
• Administrator – To je osoba koja održava web aplikaciju i pruža pomoć svim
korisnicima. Administrator ima ovlasti da mijenja podatke svih korisnika, te da
briše korisnike. Uz to administrator ima i ovlasti za rad s novostima, igračima i
rezultatima koje može dodavati, ažurirati i brisati;
• Korisnik – To je osoba koja se registrirala ili prijavila pomoću svog OpenID
računa, čime joj je omogućeno komentiranje novosti koje se nalaze na
poslužitelju. Pored toga ona može mijenjati svoje korisničke podatake;
• Posjetitelj – To je osoba koja pristupa aplikaciji, a može samo pregledavati
novosti, igrače i rezultate koji se nalaze na poslužitelju web aplikacije.
24
3.4.1 Dijagram konteksta
Na slici 12 je prikazan dijagram konteksta koji predstavlja najvišu razinu modela
procesa.
Slika 12 Dijagram konteksta
Dijagram konteksta prikazuje web aplikaciju na najvišoj razini hijerarhije prikaza. U
ovom dijagramu su prikazana sva tri vanjska entiteta (administrator, korisnik i posjetitelj)
koja sudjeluju u procesima, te jedan proces koji prikazuje sustav u cjelini. Između vanjskih
entiteta i procesa su prikazani glavni tokovi informacija u sustavu.
dodavanje i ažuriranje
novosti
zahtjev za podacima za novu novost
komentiranje novosti zahtjev za
tekstom komentara
ažuriranje svojih
podataka i podataka
ostalih korisnika
zahtjev za tekstom komentara
komentiranje novosti
ažuriranje svojih podataka
zahtjev za podacima novog
korisnika
registracija novog korisnika
P0
web aplikacija
korisnik
admini- strator
posjetitelj
25
3.4.2 Pregledni dijagram
Slika 13 prikazuje pregledni dijagram koji predstavlja prvu razinu modela procesa.
Slika 13 Pregledni dijagram
U preglednom dijagramu na slici 13 prikazane su glavne aktivnosti sustava koje se
obavljaju u procesima P1-P6. Procesi koji se koriste u ovom dijagramu su redom: registrirati
novog korisnika, ažurirati podatke o korisniku, ažurirati podatke o novosti, dodati novu
novost, komentirati novost i prikazati novost. U ovom dijagramu su prikazana još i tri
spremišta podataka D0-D2. Spremišta podataka predstavljaju entitete koji će se u konačnici
preslikati u tablice baze podataka koja se nalazi na web poslužitelju.
D0 korisnik
zaht
jev
za te
ksto
m k
omen
tara
komenti- ranje
novosti
zahtjev za tekstom
komentara
podaci novosti
podaci korisnik
zahtjev za podacima za novu novost
podaci komentar
zahtjev za podacima
novog korisnika
D2 komentari
registra-cija
novog korisnika
podaci korisnik podaci komentar
podaci novosti
ažuriranje svojih
podataka
komentiranje novosti
dodavanje novosti
ažuriranje novosti
podaci korisnik
ažuriranje svojih
podataka
podaci novosti
novi podaci novosti
stari podaci novosti
D1 novosti
P1
registrirati novog
korisnika
korisnik
admini- strator
posjetitelj
P2
ažurirati podatke o korisniku
P3
ažurirati podatke o
novosti
P4
dodati novu
novost
P5
komentirati novost
P6
prikazati novost
ažuriranje podataka
ostalih korisnika
26
3.4.3 Razrada osnovnih procesa
Procesi opisani u preglednom dijagramu mogu se detaljnije razraditi i prikazati. Na
slikama 14, 15 i 16 prikazana je razrada osnovnih procesa P1, P3 i P4.
Na slici 14 prikazana je razrada procesa registrirati novog korisnika.
Slika 14 Dijagram procesa registrirati novog korisnika
Proces P1 registrirati novog korisnika se može prikazati pomoću sedam potprocesa.
Na početku posjetitelj pristupa stranici za registraciju (P1.1), nakon čega započinje
registraciju unosom potrebnih podataka (P1.2). Nakon unosa podataka provjerava se jesu li
uneseni svi potrebni podaci (P1.3), nakon čega se provjerava točnost e-mail adrese (P1.4) i
potvrda lozinke (P1.5). Nakon toga se provjerava postoji li već korisnik s istom e-mail
adresom u sustavu (P1.6) i na kraju postoji li u sustavu korisnik s istim korisničkim imenom
(P1.7). Ukoliko nije zadovoljena bilo koja od ovih provjera posjetitelj se vraća na potproces
postoji korisnik s istim korisničkim imenom
postoji korisnik s istom e-mail adresom
podaci korisnik
podaci korisnik
kriva potvrda lozinke
nevažeća e-mail adresa
podaci korisnik
podaci korisnik
nisu uneseni svi potrebni podaci
podaci korisnik
početak registracije
podaci korisnik
D0 korisnik
zahtjev za podacima
novog korisnika
registracija novog
korisnika
P1.1
pristupiti stranici za registraciju
posjetitelj
P1.2
unositi podatke
o korisniku
P1.3 provjeriti
unos potrebnih podataka
P1.4
provjeriti e-mail adresu
P1.5
provjeriti potvrdu lozinke
P1.7 provjeriti
dostupnost korisničkog
imena
P1.6 provjeriti
je li e-mail adresa
slobodna
27
P1.2. Nakon što se zadovolje sve provjere korisnički podaci se spremaju u spremište
podataka D0 korisnik.
Na slici 15 prikazana je razrada procesa ažurirati podatke o novosti.
Slika 15 Dijagram procesa ažurirati podatke o novosti
Proces P3 ažurirati podatke o novosti se može prikazati pomoću četiri potprocesa. U
ovom procesu jedino administrator ima ovlasti za ažuriranje podataka o novostima. Na
početku administrator pristupa stranici za ažuriranje novosti (P3.1). Na toj stranici se
prikazuju stari podaci novosti iz spremišta podataka D1 novosti. Zatim administrator unosi
nove podatke o novosti (P3.2). Kad završi s unosom novih podataka provjerava se da li su
uneseni svi potrebni podaci (P3.3), nakon čega se dodatno provjerava da li je format
unesenog datuma ispravan (P3.4) Ako nije zadovoljena bilo koja od ove dvije provjere
administrator se vraća na potproces P3.2. Ako su zadovoljene obje provjere, novi podaci
novosti se spremaju u spremište podataka D1 novosti.
stari podaci novosti
neispravan format datuma
početak ažuriranja novosti
ažuriranje novosti P3.1 pristupiti
stranici za ažuriranje
novosti
admini- strator
P3.2 unositi nove
podatke o novosti
novi podaci novosti novi podaci novosti
D1 novosti
nisu uneseni svi potrebni
podaci
P3.3 provjeriti unos svih potrebnih podataka
P3.4
provjeriti datum novosti
novi podaci novosti
28
Na slici 16 prikazana je razrada procesa dodati novu novost.
Slika 16 Dijagram procesa dodati novu novost
Proces P4 dodati novu novost prikazan na slici 16 može se prikazati pomoću tri
potprocesa. U ovom procesu kao vanjski entitet se javlja administrator jer jedino on ima
ovlasti za dodavanje novosti. Administrator na početku pristupa stranici za dodavanje novosti
(P4.1) nakon čega unosi podatke o novosti (P4.2). Nakon što se unesu podaci provjerava se
da li su uneseni svi potrebni podaci (P4.3). Ako svi potrebni podaci nisu uneseni
administrator se vraća na potproces P4.2. U slučaju da su uneseni svi potrebni podaci, novost
se sprema u spremište podataka D1 novosti.
3.5 ERA model baze podataka
Logička struktura baze podataka najčešće se prikazuje ERA modelom baze podataka.
ERA model sadrži entitete koji se pojavljuju u bazi podataka zajedno sa njihovim
međusobnim odnosima. Model ove baze sadrži šest povezanih entiteta i jedan entitet koji nije
povezan. Prilikom realizacije sustava, ERA model sustava se može jednostavno
transformirati u relacijsku shemu baze podataka postupcima dekompozicije entiteta i veza u
konkretne tablice i navođenjem njihovih atributa.
početak dodavanja novosti
podaci novosti
dodavanje novosti
podaci novosti
D1 novosti
zahtjev za podacima za novu novost
nisu uneseni svi potrebni
podaci
P4.1 pristupiti
stranici za dodavanje
novosti
admini- strator
P4.2
unositi podatke o
novosti
P4.3 provjeriti unos svih potrebnih podataka
29
Na slici 17 prikazan je ERA model baze podataka.
Slika 17 ERA model baze podataka
Na ERA modelu baze podataka se vidi da jedan korisnik može imati niti jedan, jedan ili
više OpenID-ova. Jedan OpenID može koristiti samo jedan korisnik. Korisnik može napisati
niti jedan, jedan ili više komentara. Jedan komentar može biti napisan samo od strane jednog
korisnika. Jedan komentar se može nalaziti samo u jednoj novosti, a novost može sadržavati
niti jedan, jedan ili više komentara. Jedna novost može sadržavati niti jednu ili jednu
utakmicu, a jedna utakmica može biti povezana sa samo jednom novosti. Također jedna
novost može sadržavati niti jedan ili jedan rezultat, dok jedan rezultat može biti povezan sa
samo jednom novosti. Entitet igrač nije povezan s niti jednim drugim entitetom, jer je on
pomoćni entitet, te kao takav nije ključan za funkcioniranje sustava.
Razlog zbog čega korisnik može imati više OpenId-jeva je da bi u slučaju da web
stranica nekog od davatelja nije u funkciji mogao napraviti prijavu korištenjem identiteta kod
drugog davatelja (npr. ako u trenutku prijave iz nekog razloga prijava putem Yahoo davatelja
usluga ne funkcionira, korisnik se može prijaviti korištenjem identiteta koji ima kod npr.
Google davatelja usluge).
30
4 REALIZACIJA WEB APLIKACIJE
Prema modelu iz prethodnog poglavlja realizirana je ASP.NET hibridna web aplikacija
koja koristi Google Maps API za prikaz i pohranu mape s lokacijama odigravanja utakmica,
Picasa Web Albums Data API za prikaz i pohranu slika, te vlastiti ASP.NET poslužiteljski
dio za prikaz i pohranu podataka o utakmicama, novostima, igračima momčadi Palace i
rezultatima. Za pohranu tih podataka je korištena MS SQL relacijska baza podataka. Ova
hibridna web aplikacija omogućuje svakome posjetitelju pregled novosti, igrača i rezultata, te
pregled podataka o utakmicama putem sučelja mape na kojoj su označene lokacije
odigravanja utakmica sa markerima.
Za korisnike web aplikacije prijava je realizirana na dva načina. Prvi način je
korištenjem centralizirane provjere identiteta koja koristi podatke korisnika iz baze podataka,
te se za ovaj način provjere identiteta korisnik prethodno mora registrirati. Drugi način je
decentralizirana provjera identiteta koja koristi OpenID protokol.
Aplikacija je rađena korištenjem Microsoft Visual Studio 2008 Professional Edition
razvojnog okruženja, a pri izradi poslužiteljskog dijela aplikacije korišten je C# programski
jezik. Za pokretanje aplikacije na poslužitelju potreban je .NET Framework 3.5.
Dizajn web stranice je napravljen u programu Adobe Photoshop CS3. Klijentski dio
rađen je pomoću HTML-a, CSS-a i Javascripta. U nekim segmentima koristi se AJAX
tehnologija kako bi se osigurao asinkroni način rada s podacima. Na klijentu, za korištenje
aplikacije korisnik mora imati instaliran bilo koji web preglednik koji može raditi s
Javascriptom.
4.1 Opis baze podataka
Baza podataka koju koristi aplikacija kreirana je na osnovu ERA modela opisanog u
prethodnom poglavlju. Baza sadrži sedam tablica, od kojih je šest povezanih, dok jedna
tablica nije povezana s niti jednom drugom tablicom.
31
Na slici 18 prikazan je shematski prikaz baze podataka korištene u ovoj web aplikaciji.
Slika 18 Shematski prikaz baze podataka
Za spremanje korisničkih podataka koriste se dvije tablice korisnik i openID. U tablicu
korisnik se spremaju korisnički podaci: ime i prezime, adresa, grad, e-mail, korisničko ime,
lozinka, te razina. Atribut razina predstavlja vrstu korisnika. Postoje dvije vrste registriranih
korisnika, a to su administrator i korisnik. Standardna vrijednost ovog atributa je laž i ona se
koristi za označavanje običnog korisnika, dok se vrijednost istina koristi za označavanje
administratora. U tablicu openID se spremaju OpenID oznake prilikom prijave pomoću
OpenID-a. Svaki korisnik može imati više OpenID oznaka. Jedna OpenID oznaka se može
pojaviti samo jednom u tablici openID, te može biti povezana sa samo jednim korisnikom.
U tablicu novosti se spremaju podaci o novosti. U ovu tablicu se među ostalim
podacima spremaju i link slike, te kôd galerije slika koje su spremljene pomoću Picasa Web
Albums Data API-ja. Postoji pet kategorija novosti, a to su: obavijesti, utakmice, divlja liga,
udruga i putovanja. U slučaju da je kategorija novosti utakmice, onda se ta tablica povezuje
sa tablicom utakmica gdje se spremaju dodatni podaci o toj utakmici. Jedna novost može biti
povezana s niti jednom ili sa samo jednom utakmicom. Svaka utakmica je povezana sa samo
jednom novosti. Ako je kategorija novosti divlja liga, onda se tablica novosti povezuje sa
tablicom rezultati u koju se spremaju podaci o rezultatima. Jedna novost može biti povezana s
niti jednim ili sa samo jednim rezultatom. Svaki rezultat je povezan sa samo jednom novosti.
32
Tablica komentari se koristi za spremanje komentara korisnika za pojedine novosti.
Svaka novost može imati niti jedan, jedan ili više komentara od jednog ili više korisnika.
Svaki korisnik može imati niti jedan, jedan ili više komentara za svaku novost. Jedan
komentar može biti povezan samo s jednim korisnikom i sa samo jednom novosti.
Podaci o igraču se spremaju u tablicu igrac. U ovu tablicu se osim tekstualnih i
numeričkih podataka sprema i slika igrača kao tip podatka image. Ova tablica nije povezana s
niti jednom drugom tablicom jer ona služi za spremanje i prikaz podataka samo o igračima
momčadi Palace.
4.2 Opis poslužiteljskog dijela web aplikacije
Aplikacija je izgrađena u Microsoft Visual Studio 2008 Professional Edition razvojnom
okruženju, koristeći C# programski jezik. Za spremanje teksta novosti i teksta rezultata u
bazu podataka korišten je besplatni HTML uređivač teksta za ASP.NET web aplikacije
FreeTextBox verzije 3.2.4 [17].
Za prijavu pomoću OpenID-a korištena je C# programska biblioteka DotNetOpenID
verzije 2.5.6 [14]. Ova biblioteka omogućuje dodavanje OpenID kontrola programirajući, i
pomoću ASP.NET drop-in kontrola.
4.2.1 Registracija novih korisnika
Da bi se korisnici mogli prijaviti na web aplikaciju putem centralizirane provjere
identiteta prethodno se moraju registrirati. Registracija novih korisnika je realizirana tako da
novi korisnici trebaju unijeti podatke koje se zahtijevaju od njih, a to su: ime i prezime,
adresa, grad, e-mail adresa, korisničko ime i lozinka. Od navedenih podataka obavezni su ime
i prezime, e-mail adresa, korisničko ime i lozinka, pa se proces registracije može završiti tek
nakon unosa tih podataka. Kod potvrde registracije realizirana je provjera unesene e-mail
adrese i korisničkog imena. Ti se podaci uspoređuju s podacima registriranih korisnika iz
tablice korisnik u bazi podataka. U slučaju da u toj tablici već postoji korisnik s istom
e-mail adresom ili s istim korisničkim imenom posjetitelj se upozorava da treba unijeti drugu
e-mail adresu, odnosno drugo korisničko ime. Prilikom spremanja podataka korisnika u bazu
podataka lozinka se šifrira pomoću Rijndael simetričnog enkripcijskog algoritma, te se u tom
šifriranom obliku sprema u bazi podataka.
Algoritam Rijndael je krajem 2000. godine izabran za novi kriptografski standard
standard i nasljednik DES algoritma. Njegove osnovne karakteristike su da je veličina bloka
33
enkripcije, duljina ključa i broj rundi enkripcije varijabilna te je zbog toga otporniji na
brutte-force napad od DES algoritma [2].
4.2.2 Centralizirana provjera identiteta
Centralizirana provjera identiteta korisnika je realizirana s dva polja u koja se trebaju
unijeti korisničko ime i lozinka korisnika.
Na slici 19 je prikazan proces centralizirane provjere identiteta korisnika s provjerama
korisničkog imena i lozinke.
Slika 19 Proces centralizirane provjere identiteta korisnika
Prilikom prijave provodi se provjera postoji li korisnik s unesenim korisničkim
imenom. U slučaju da takav korisnik ne postoji prikazuje se upozorenje da taj korisnik ne
postoji (slika 19.a). Ako korisničko ime postoji u bazi podataka, u slijedećem koraku se
provjerava da li je unesena točna lozinka za tog korisnika. Unesena lozinka se šifrira i
uspoređuje sa šifriranom lozinkom korisnika koja je spremljena u bazi podataka. U slučaju da
unesena lozinka nije jednaka lozinki iz baze podataka prikazuje se upozorenje da je lozinka
pogrešna (slika 19.b). Nakon što se unese točno korisničko ime i točna lozinka korisnik je
prijavljen u web aplikaciju. Umjesto polja za unos korisničkog imena i polja za unos lozinke
pojavi se izbornik administratora (slika 19.c), odnosno korisnika (slika 19.d) ovisno o
vrijednosti atributa razina prijavljenog korisnika u tablici korisnik.
4.2.3 Decentralizirana provjera identiteta
Za decentraliziranu provjeru identiteta koristi se OpenID protokol. Da bi se korisnik
prijavio na takav način treba pristupiti stranici za prijavu pomoću OpenID-a. Nakon toga
treba unijeti oznaku svog OpenID identiteta. Aplikacija na osnovu unesene OpenID oznake
saznaje tko je davatelj identiteta, te šalje zahtjev za provjeru identiteta posredniku. Posrednik
prosljeđuje taj zahtjev davatelju identiteta. Korisnik se preusmjerava na web stranicu
davatelja identiteta, gdje se prijavljuje unoseći svoje korisničko ime i lozinku. Nakon što se
34
prijavio na stranici davatelja identiteta treba potvrditi da želi koristiti usluge web aplikacije.
Nakon toga davatelj identiteta vraća rezultat provedene provjere aplikaciji, koja na osnovu
tog rezultata korisniku dozvoljava ili zabranjuje pristup. Nakon što se korisnik odjavi s web
aplikacije, treba se i posebno odjaviti sa web stranice davatelja identiteta.
Za realizaciju prijave pomoću OpenID-a koristi se C# programska biblioteka
DotNetOpenID koja omogućava korištenje OpenID-a u ASP.NET web aplikacijama. Velik
dio korisnika Interneta još uvijek ne zna na koji način funkcionira prijava pomoću OpenID
protokola. Radi olakšavanja prijave korisniku iznad polja u koje se unosi OpenID oznaka
dodano je 11 tipki s logotipovima najpoznatijih davatelja OpenID identiteta. Te organizacije
su redom: Google, Yahoo, MyOpenID, AOL, MySpace, BlogSpot, ClaimID, LiveJournal,
Verisign, MyVidoop i Wordpress. Google i Yahoo koriste istu polaznu OpenID oznaku za sve
korisnike, dok se kod ostalih unutar OpenID oznake treba unijeti i korisničko ime.
Na slici 20 prikazan je proces prijave korisnika pomoću OpenID protokola
korištenjem Googlea kao davatelja usluga.
Slika 20 Proces decentralizirane provjere identiteta korisnika Google korisničkim računom
Korisnik unosi OpenID oznaku svog Google korisničkog računa ili klikne na tipku s
logotipom Google davatelja usluga (slika 20.a). Nakon toga se prijavljuje na Googleovoj web
stranici (slika 20.b), te potvrđuje da se želi prijaviti na polaznu web aplikaciju (slika 20.c).
Google u pozadini vraća aplikaciji potvrdu da je identitet korisnika potvrđen ili informaciju
da korisnik nije potvrdio svoj identitet. Nakon toga korisnik se preusmjerava natrag na
35
polaznu web stranicu. U slučaju da je provjera kod davatelja identiteta uspješno provedena, a
OpenID korisnika prethodno evidentiran u sustavu korisnik je automatski prijavljen u sustav
te se na desnoj strani web stranice prikazuje odgovarajući izbornik korisnika (slika 20.d).
4.2.4 Ažuriranje korisničkih podataka
Svaki korisnik aplikacije nakon prijave može ažurirati svoje korisničke podatke.
Ažuriranje korisničkih podataka je realizirano na način da se može ažurirati samo ime i
prezime, adresa, grad i lozinka korisnika. Korisnik ne može mijenjati svoje korisničko ime,
niti e-mail adresu. Kada korisnik pristupi stranici za ažuriranje svojih podataka prikazuju se
ime i prezime, adresa i grad u poljima za unos teksta, dok se korisničko ime i e-mail adresa
prikazuju kao tekstualne oznake. Lozinka se ne prikazuje, a polje u kojem se unosi nova
lozinka je prazno.
U slučaju da se lozinka mijenja, ona se prije spremanja u bazu podataka šifrira na isti
način kao i kod registracije novog korisnika. Na stranici za ažuriranje podataka se prikazuje i
popis svih OpenID oznaka koje je korisnik koristio za prijavu u web aplikaciju.
4.2.5 Administracija korisnika
Ažuriranje podataka ostalih korisnika je realizirano tako da administrator može
ažurirati sve njihove podatke osim korisničkog imena. Pored ažuriranja tih podataka
administrator može mijenjati i razinu registriranog korisnika te ga unaprijediti u rang
administratora. U padajućoj listi se prikazuje razina registriranog korisnika, a postoje dvije
razine: administrator i korisnik. Zbog mogućnosti administratora da može mijenjati e-mail
adresu korisnika i tu postoji provjera da li postoji neki drugi korisnik koji koristi istu e-mail
adresu. Ako postoji prikazuje se upozorenje da se treba unijeti neka druga e-mail adresa, jer
više korisnika ne može koristiti istu e-mail adresu.
Na stranici za ažuriranje podataka ostalih korisnika nalazi se i lista s popisom OpenID
oznaka odabranog korisnika. OpenID oznake administrator ne može mijenjati, ali ih može
brisati. Na stranici sa popisom svih korisnika, administrator može izabrati jednog korisnika i
obrisati sve njegove podatke. Prilikom brisanja korisnika automatski se brišu i sve OpenID
oznake tog korisnika. U slučaju da je korisnik komentirao novosti, taj se korisnik ne može
izbrisati iz baze podataka kako bi se sačuvao referencijalni integritet baze podataka.
36
4.2.6 Administracija novosti
Administrator može dodavati, ažurirati i brisati novosti. Definirano je pet kategorija
novosti, a to su: obavijesti, utakmice, divlja liga, udruga i putovanja.
Sve vrste novosti sadrže naslov, kategoriju, autora teksta, autora fotografija, kratak
sadržaj, link na Picasa sliku, kod Picasa galerije te datum i tekst novosti. Prilikom dodavanja
novosti kao datum se automatski sprema trenutni datum. Slike se dodaju pomoću Picasa Web
Album Data API-ja što će biti naknadno objašnjeno. U bazu podataka se sprema samo link na
sliku, dok se za galeriju sprema izvorni kôd potreban za prikaz galerije na web stranici
aplikacije. Izvorni kôd je stvoren pomoću Picasa Web Album Data API-ja. Tekst novosti se
unosi pomoću HTML uređivača teksta FreeTextBox koji omogućuje oblikovanje unesenog
teksta pomoću HTML-a i CSS-a.
Ako se za kategoriju novosti odabere divlja liga, prikazat će se i dodatna polja za unos
kola, datuma odigravanja utakmica te polje za unos rezultata. Kod spremanja rezultata
provjerava se ispravnost formata unesenog datuma. Dodatni podaci o rezultatima se spremaju
u posebnu tablicu rezultati koja je povezana s tablicom novosti u koju se spremaju ostali
podaci o novosti.
U slučaju da se za kategoriju novosti odabere utakmice, prikazuju se i dodatna polja
za unos rezultata, datuma, kola, kupališta, sudaca, ekipe bijelih i plavih, igrača više i
četveraca. Prilikom potvrde spremanja utakmice provjerava se da li je uneseni datum
utakmice u ispravnom formatu. Podaci specifični za utakmicu spremaju se u posebnu tablicu
utakmica povezanu s tablicom novosti u koju se spremaju svi ostali podaci novosti.
37
Na slici 21 prikazana je forma za dodavanje novosti koje pripadaju kategoriji
utakmice.
Slika 21 Forma za dodavanje novosti kategorije utakmice
Kod ažuriranja se mogu mijenjati svi podaci novosti uključujući i datum. Zbog toga
postoji provjera da li je uneseni datum u ispravnom formatu. Ako se mijenja kategorija
novosti postoje četiri specifična slučaja. Prvi slučaj je da se kategorija obavijesti, udruga ili
putovanja mijenja u kategoriju utakmice ili divlja liga. U tom slučaju se na formi za
ažuriranje novosti prikazuju dodatna polja za unos podataka o utakmici, odnosno o
rezultatima divlje lige. Nakon završetka procesa ažuriranja spremaju se podaci o novosti i
dodatni podaci o utakmici ili rezultatima. Drugi slučaj je da se mijenja kategorija novosti
utakmice ili divlja liga u kategoriju obavijesti, udruga ili putovanja. Kada se pristupi stranici
za ažuriranje takve vrste novosti, prikazuje se upozorenje da se promjenom kategorije brišu
prethodno zabilježeni podaci o utakmici ili rezultatima. Odabirom neke druge kategorije polja
sa podacima o utakmici, odnosno o rezultatima postanu skrivena. Ukoliko se potvrdi
ažuriranje, s promjenom kategorije izbrisat će se dodatni podaci o utakmici ili rezultatima.
Treći slučaj da se mijenja kategorija novosti iz utakmice u divlja liga. U tom se slučaju
skrivaju polja sa podacima o utakmici, a prikazuju se polja sa podacima o rezultatima. Nakon
38
potvrde ažuriranja novosti brišu se podaci o utakmici, a spremaju se novi podaci o
rezultatima. Četvrti slučaj je promjena kategorije iz divlja liga u kategoriju utakmice. Onda se
skrivaju polja sa podacima o rezultatima, a prikazuju polja sa podacima o utakmici. Nakon
ažuriranja brišu se podaci o rezultatima, a spremaju se novi podaci o utakmici.
Na stranici koja prikazuje sve novosti, moguće je brisati novosti. Prilikom brisanja
novosti ako novost pripada kategoriji utakmice ili divlja liga, automatski se brišu i podaci o
toj utakmici ili podaci o rezultatima. Novosti mogu sadržavati komentare korisnika koji se
prilikom brisanja novosti automatski brišu.
4.2.7 Administracija igrača
Administrator može dodavati, ažurirati i brisati igrače momčadi Palace. Prilikom
dodavanja igrača unose se razni podaci o igraču od kojih su najvažniji ime, prezime, broj
kapice, pozicija i slika igrača. Za poziciju igrača je definirano svih sedam mogućih pozicija:
vratar, centar (sidrun), branič (bek), lijevi vanjski, lijevo krilo, desni vanjski i desno krilo.
Pozicija igrača se odabire iz padajuće liste. Dodavanje slike igrača je realizirano tako da se
slika sprema direktno u bazu podataka. Slika koja se dodaje mora biti u .jpg ili .gif formatu.
Prije spremanja, slika se smanjuje na zadanu veličinu. U slučaju da se prilikom dodavanja
podataka o igraču ne doda slika, u bazu podataka će se spremiti inicijalno zadana slika. Slika
se u bazu sprema u binarnom obliku. Prilikom potvrđivanja dodavanja novog igrača
provjerava se da li u bazi postoji igrač sa istim brojem kapice. Ako postoji onda treba unijeti
neki drugi broj kapice. Za prikaz slika iz baze podataka koristi se generički rukovatelj (engl.
generic handler) u kojem je definiran kôd za pretvaranje binarnih podataka u sliku koja se
prikazuje na web stranici.
4.2.8 Komentiranje novosti
Korisnici i administratori mogu komentirati novosti. Kad se otvori stranica s podacima
o novosti ispod teksta novosti se prikazuju komentari zajedno s korisničkim imenom i
datumom pisanja komentara. Pored toga se prikazuje i tekst da se korisnik koji želi
komentirati novosti treba registrirati ili prijaviti. U slučaju da toj stranici pristupi korisnik ili
administrator koji su prijavljeni, njima će se iznad komentara prikazati i polje za unos
komentara. Dodavanje komentara je realizirano pomoću AJAX funkcionalnosti i pritom se
osvježava samo dio stranice s prikazom komentara. Preostali dio stranice ostaje
nepromijenjen. Kako bi to bilo moguće, komentari se odmah nakon potvrđivanja dodavanja
39
spremaju u bazu i nakon dodavanja automatski prikazuju na stranici, bez da se cijela stranica
ponovno učita.
4.3 Hibridni dio web aplikacije
U hibridnom dijelu web aplikacije se koriste dva API-ja: Google Maps API za prikaz
mape s lokacijama odigranih vaterpolo utakmica, a Picasa Web Albums Data API za prikaz i
pohranu slika utakmica. Ta dva API-ja se koriste sa ASP.NET poslužiteljskom aplikacijom
koja se koristi za pohranu podataka i teksta o novostima, rezultatima, igračima i utakmicama.
4.3.1 Pohrana i prikaz mape
Google Maps API trenutno nema posebnu aplikaciju pomoću koje se mogu dodavati
markeri izravnim klikom na mapu. Markeri bi se radi toga trebali dodavati korištenjem
posebnog Javascript koda navođenjem točnih geografskih širina i dužina, te opisa i linka na
slike koje se vežu uz lokaciju. Zbog toga sam za realizaciju prikaza mape s lokacijama
odigranih vaterpolo utakmica koristio dodatnu web aplikaciju Map Maker [20]. Ta aplikacija
omogućuje dodavanje markera na mapu klikom na lokaciju na mapi na koju se želi dodati
marker. Mape kreirane pomoću te pomoćne aplikacije moguće je sačuvati, te ih kasnije
koristiti na drugim web stranicama. Za rad s web aplikacijom Map Maker potrebno se
prethodno prijaviti na njezinu web stranicu.
Sučelje ove web aplikacije je podijeljeno na četiri osnovna dijela. U centralnom dijelu
sučelja se nalazi mapa, na kojoj se označavaju lokacije markera. S lijeve strane mape se
nalaze polja sa geografskom širinom i dužinom, nazivom i opisom markera te tipkom za
spremanje ili ažuriranje markera. Desno od mape se nalazi lista svih markera spremljenih u
toj mapi. Ispod mape se nalaze tipke za dohvat Javascript koda za mapu, koda za dodavanje
mape na web stranicu, te tipka za spremanje mape. Klikom na jednu od prve dvije tipke u
polju ispod njih se prikazuje željeni kôd.
40
Na slici 22 je prikazano sučelje web aplikacije Map Maker.
Slika 22 Sučelje Map Maker aplikacije
Da bi se odabrala lokacija markera na mapi potrebno je kliknuti na željeno mjesto na
mapi. U poljima geografske širine i dužine se automatski prikazuje geografska širina i dužina
odabrane lokacije. U polje za unos opisa markera može se unositi običan tekst ili HTML kôd.
Nakon što se sačuva neki marker, on se automatski prikazuje u listi markera te mape.
Markere iz liste je moguće ažurirati ili brisati klikom na ikone za ažuriranje, odnosno ikone
za brisanje koje se nalaze pored naziva svakog markera. Nakon završetka rada s mapom
potrebno ju je spremiti.
Radi jednostavnijeg korištenja mape za njezin prikaz koristio sam HTML kôd koji
sam umetnuo na web stranicu aplikacije u iframe objekt. Razlog za takav način je u tome što
se nakon spremanja mape na Map Maker aplikaciji automatski mijenja i mapa na mojoj web
aplikaciji i nije potrebno nikakvo dodatno ažuriranje mape u aplikaciji.
4.3.2 Pohrana i prikaz slika
Za pohranu slika potrebno se prijaviti na Picasa web stranicu. Da bi se u servis
spremile slike treba odabrati opciju upload na toj stranici. Nakon toga treba kreirati novi
album ili izabrati neki od prethodno spremljenih albuma. Sistem povezivanja koji sam
izabrao je da jedan album predstavlja slike vezane uz jednu novost odnosno jednu utakmicu.
Svaki put kada se uz novu novost ili utakmicu žele povezati slike, potrebno je u Picasi
41
stvoriti novi album. Nakon što se pohrane slike, na toj stranici ih je potrebno povezati s
novostima i markerima na mapi.
Na slici 23 prikazan je dio Picasa web stranice na kojem se bira link na sliku koji se
može umetnuti u web stranicu kako bi se na toj stranici prikazao sadržaj albuma.
Slika 23 Odabir linka na sliku pohranjenu pomoću Picase
Da bi se spremio link na sliku u albumu, prilikom dodavanja ili ažuriranja novosti
treba prvo otvoriti željenu sliku i odabrati opciju stvaranja linka na sliku. Nakon toga treba
odabrati veličinu slike (select size), pa opciju za prikaz samo slike (bez linka na Picasa web
stranicu – Image only - no link) i kopirati stvoreni link slike u polje za unos linka prilikom
dodavanja ili ažuriranja novosti.
Za dodavanje galerije slika vezane uz novost treba otvoriti album vezan za određenu
novost. Nakon toga treba odabrati opciju za link na album i na kraju odabrati ugrađenu
prezentaciju.
Po završetku procesa dodavanja prikazuje se okvir s kodom koji predstavlja galeriju i
koji se koristi unutar aplikacije. U tom se okviru može odabrati veličina galerije, te se kopira
kôd galerije u odgovarajuće polje prilikom dodavanja ili ažuriranja novosti. Ovdje se mogu
odabrati i neke dodatne opcije, kao što su automatsko pokretanje galerije i prikaz opisa slika.
Isti kôd se može zapisati u polje opisa markera u web aplikaciji Map Maker, kako bi se
galerija slika prikazivala automatski nakon što korisnik klikne na određeni marker na mapi.
42
Izgled ekrana za izradu i pridruživanje galerije slika aplikaciji prikazan je na slici 24.
Slika 24 Podešavanja koda galerije slika
4.4 Iskustva u izradi aplikacije
Na početku izrade aplikacije napravio sam i dizajnirao MasterPage stranicu koja se
koristi za definiranje izgleda svih stranica ili grupe stranica u ASP.NET aplikaciji. Ona sadrži
tri ContentPlaceHoldera koji definiraju područja za smještanje sadržaja unutar MasterPage
stranice [13]. Sadržaj svakog ContentPlaceHoldera može biti različit na svakoj stranici.
Ostale stranice ne sadrže <html>, <head> i <body> tagove i za njih je potrebno samo
definirati MasterPage stranicu. Sve što se nalazi na MasterPage stranici automatski se
prikazuje i na svim ostalim stranicama web aplikacije. Nakon toga se sve što je potrebno za
pojedinu stranicu stavlja u ContentPlaceHoldere.
Pomoću web kontrola mogu se prikazati isti elementi na više različitih stranica. Za
desni ContentPlaceHolder sam napravio web kontrolu prijava.ascx. Ova web kontrola sadrži
MultiView komponentu koja u prvom pogledu ima dva polja za unos korisničkog imena i
lozinke za centraliziranu provjeru identiteta korisnika, te linkove za registraciju novih
korisnika i prijavu pomoću OpenID-a. Nakon uspješne prijave prvi pogled se zamjenjuje
drugim koji sadrži izbornik korisnika ili administratora. Nakon odjave ponovno se prikazuje
prvi pogled.
Nakon završetka dizajna aplikacije trebalo je riješiti problem prikazivanja mape i
označavanja lokacija markera na mapi. Za prikaz mape sam koristio Google Maps API.
Google trenutno još nije objavio nikakvu aplikaciju za označavanje markera klikom na mapu
43
za Google Maps API, kao što je to realizirano na stranici http://maps.google.com za obične
Googleove mape pa sam odlučio iskoristiti funkcionalnost vanjske aplikacije Map Maker
koja omogućuje jednostavno označavanje lokacije markera klikom na mapu, nakon čega se
unosi tekst unutar polja opisa markera.
Slike vezane uz novosti i mapu sam postavljao pomoću Picasa Web Album Data API-
ja. Slike sam postavio u više različitih albuma. Izabrani princip je bio da se u svaki album
postavljaju slike koje vezane uz jednu novost. Nakon postavljanja slika povezao sam ih s
markerima na mapi kopiranjem HTML kôda za galeriju albuma unutar polja opisa markera u
Map Maker aplikaciji. Slike sam povezao i s novostima koje se prikazuju u web aplikaciji. S
podacima novosti, u bazu podataka sam spremao i link glavne slike za novost, kao i kôd za
galeriju albuma.
Slike igrača sam spremao direktno u bazu podataka kao tip podatka image. Slika se
sprema u bazu podatka u obliku binarnih podataka. Da bi se mogle prikazivati slike iz baze
podataka realizirao sam generički rukovatelj koji pretvara binarne podatke iz baze podataka u
sliku koja se prikazuje na web stranici. Pri spremanju slika mogao sam koristiti isti način
pomoću vanjskog API-ja koji sam korišten pri spremanju slika vezanih uz novosti. Ovaj drugi
pristup sam izabrao kako bih istražio i upoznao se s dva različita načina za pohranu grafičkih
podataka u aplikaciji.
U web aplikaciji je omogućeno komentiranje novosti. Specifičnost prikaza komentara
je u tome što se komentari prikazuju odmah nakon dodavanja istih. Da bi to bilo moguće
koristio sam funkcionalnost AJAX tehnologije koja nakon spremanja komentara u bazu
podataka omogućuje njihov trenutni prikaz na web stranici bez ponovnog učitavanja cijele
web stranice.
44
5 KORIŠTENJE WEB APLIKACIJE
U ovom poglavlju će se opisati korištenje aplikacije pomoću prikaza njezinih glavnih
funkcionalnosti: registracije novog korisnika, prijave pomoću OpenID protokola,
administracije web aplikacije i komentiranja novosti.
5.1 Registracija novog korisnika
Da bi posjetitelji postali korisnici web aplikacije moraju se registrirati ili prijaviti
pomoću svog OpenID-a. U slučaju da se žele registrirati i prijaviti za rad s web aplikacijom
na klasičan način, pomoću korisničkog imena i lozinke trebaju pristupiti stranici za
registraciju.
Na slici 25 prikazan je proces registracije novog korisnika.
Slika 25 Proces registracije novog korisnika
Nakon što posjetitelj pristupi stranici za registraciju treba unijeti sve podatke koje su
obavezni za unos. Ako se ne unese neki obavezni podatak, pored tog polja prikazati će se
45
zvjezdica, koja upozorava da nije unesen taj podatak (slika 25.a). Nakon što se unesu svi
podaci provjerava se da li je e-mail adresa unesena u pravilnom formatu. Pod pravilnim
formatom e-mail adrese se podrazumijeva da e-mail adresa sadrži znak @ i barem jednu
točku iza tog znaka. Ako e-mail adresa nije u pravilnom formatu ispod polja za unos e-mail
adrese se prikazuje upozorenje (slika 25.b). Prilikom unosa lozinke potrebno ju je unijeti u
dva polja (lozinka i potvrda lozinke). Ako lozinke u oba polja nisu jednake prikazuje se
upozorenje (slika 25.b).
Nakon što su uneseni svi ispravni podaci izvode se još dvije provjere vezane za
jedinstvenost e-mail adresa i korisničkih imena. Prvo se provjerava da li već postoji u bazi
podataka korisnik s istom e-mail adresom koja je unesena u polje e-mail. U slučaju da postoji
prikazuje se upozorenje i traži se od posjetitelja da unese neku drugu e-mail adresu (slika
25.c). Kad se unese slobodna e-mail adresa provjerava se postoji li korisnik s istim
korisničkim imenom. Ako postoji prikazuje se upozorenje da već postoji korisnik s tim
korisničkim imenom te se traži da se unese neko drugo korisničko ime (slika 25.d). Tek
nakon što se zadovolje svi navedeni uvjeti može se završiti proces registracije. Nakon
uspješne registracije korisnik se može prijaviti pomoću korisničkog imena i lozinke koje je
naveo u registraciji.
5.2 Prijava pomoću OpenID protokola
Prijava pomoću OpenID protokola omogućava korisnicima da se prijave pomoću svog
Google, Yahoo, MyOpenID ili nekog drugog korisničkog računa koji podržava OpenID
provjeru identiteta korisnika.
Nakon što posjetitelj pristupi stranici za prijavu pomoću OpenID-a treba unijeti svoju
oznaku OpenID identiteta ili odabrati neki od ponuđenih OpenID-ova na stranici.
Na slici 26 prikazana je forma za prijavu pomoću OpenID-a.
Slika 26 Prijava pomoću OpenID-a
46
Prilikom potvrde provjerava se da li je unesena OpenID oznaka, te se prikazuje
upozorenje ako nije unesena.
Ukoliko se za prijavu koriste Google ili Yahoo korisnički račun dovoljno je kliknuti na
njihove tipke, te nakon toga kliknuti na tipku prijava. Kod ostalih korisničkih računa
potrebno je unutar URL-a OpenID oznake umjesto teksta korisnik unijeti korisničko ime koje
korisnik koristi za prijavu na toj web stranici. Nakon klika na tipku prijava posjetitelj se
preusmjerava na web stranicu odabranog davatelja OpenID identiteta.
U slučaju da se odabere MyOpenID kao davatelj OpenID identiteta preusmjerit će se na
stranicu koja je prikazana na slici 27.
Slika 27 Prijava pomoću MyOpenID davatelja usluga
Nakon što se posjetitelj prijavi na MyOpenID stranicu pomoću svog korisničkog imena
i lozinke otvoriti će mu se stranica na kojoj treba potvrditi da se želi prijaviti na polaznu web
aplikaciju pomoću svog MyOpenID identiteta. Ovdje se može uključiti opcija da se zapamti
ta web aplikacija. Nakon toga svaki sljedeći put kada se prijavljuje na tu web aplikaciju
automatski će se preusmjeriti s MyOpenID stranice natrag na nju. Također se može odabrati
opcija da se prilikom prijave predaju ili ne predaju informacije o korisniku, kao što su ime i
prezime, e-mail adresa, nadimak, adresa, država.
47
Nakon povratka u polaznu aplikaciju prvo se provjerava da li postoji korišteni OpenID
u bazi podataka. U slučaju da postoji vrši se automatska prijava korisnika u web aplikaciju.
Ako ne postoji provjerava se da li je davatelj usluga vratio korisničke podatke. Pri prijavi
korištenjem OpenID-a zahtjeva se unos tri osnovna podatka o korisniku, a to su ime i
prezime, e-mail adresa i nadimak. Nadimak će se koristiti kao korisničko ime u prikazu
komentara. Ako se nakon prijave kod davatelja OpenID identiteta vrate sva tri podatka,
provjerava se postoji li korisnik s istom e-mail adresom. U slučaju da postoji, OpenID se
pridružuje tom korisniku, a ako ne postoji kreira se novi korisnik kojemu se pridružuje
OpenID.
Za razliku od MyOpenID-a tvrtke Google i Yahoo još uvijek ne podržavaju predavanje
korisnikovih informacija prilikom OpenID prijave. U tom slučaju korisnik prilikom prijave
mora ručno unijeti ime i prezime, e-mail adresu i nadimak korisnika.
Na slici 28 prikazana je forma za unos dodatnih podataka OpenID korisnika u web
aplikaciju.
Slika 28 Unos dodatnih podataka o OpenID korisniku
Nakon što se unesu potrebni podaci nakon potvrđivanja prijave provjerava se postoji li
prethodno evidentiran korisnik s istom e-mail adresom, te postoji li neki korisnik koji koristi
uneseni nadimak kao svoje korisničko ime. Ako ne postoji niti jedan korisnik s istom e-mail
adresom, niti s istim korisničkim imenom kreira se novi korisnik kojemu se pridružuje
korišteni OpenID.
48
Na slici 29 su prikazane provjere da li postoji korisnik s istom e-mail adresom ili s
istim korisničkim imenom.
Slika 29 Provjera e-mail adrese i nadimka prilikom OpenID prijave
Ako postoji korisnik s istom e-mail adresom pretpostavlja se da je to isti korisnik, pa se
od njega traži da unese svoju lozinku (slika 29.a). Ako se unese ispravna lozinka tom se
korisniku pridružuje korišteni OpenID, te je on prijavljen u web aplikaciju. U slučaju da se
unese kriva lozinka, od posjetitelja se traži da unese neku drugu slobodnu e-mail adresu pošto
je pretpostavka da to nije korisnik koji je vlasnik unesene e-mail adrese. Ako unesenu e-mail
adresu ne koristi niti jedan drugi korisnik provjerava se da li neki drugi korisnik već koristi
uneseni nadimak. U slučaju da koristi prikazuje se upozorenje i traži se da korisnik promijeni
nadimak (slika 29.b). Ako ne postoji kreira se novi korisnik sa unesenim podacima i njemu se
pridružuje korišteni OpenID.
Na kraju rada s web aplikacijom nakon što se korisnik odjavi s web aplikacije, mora se
posebno odjaviti i sa web stranice svog davatelja OpenID identiteta.
5.3 Administracija web aplikacije
Nakon što se administrator prijavi na web aplikaciju u njegovom izborniku s desne
strane se prikazuje link admin meni. Nakon klika na taj link otvara se stranica za
administraciju web aplikacije. Administracija je podijeljena u četiri osnovne kategorije, a to
su: korisnici, novosti, momčad i rezultati.
49
5.3.1 Administracija korisnika Kad administrator pristupi stranici za ažuriranje korisnika prikazuje mu se lista
korisnika prikazana na slici 30.
Slika 30 Administracija korisnika
Ta web stranica sadrži listu svih korisnika koji su se registrirali ili su se prijavili na web
aplikaciju pomoću svog OpenID-a. U listi je prikazano korisničko ime, ime i prezime
korisnika, te dva linka za ažuriranje i brisanje korisnika.
Za brisanje korisnika dovoljno je kliknuti na link briši odabranog korisnika. Ako taj
korisnik nije komentirao novosti njegovi podaci će se izbrisati. Automatski će se s
korisničkim podacima izbrisati i sve OpenID oznake tog korisnika. Korisnik se ne može
izbrisati ako je komentirao novosti, jer bi se onda trebali izbrisati i svi komentari tog
korisnika.
Nakon klika na link ažuriraj za izabranog korisnika otvoriti će se stranica za ažuriranje
njegovih podataka. Na toj se stranici prikazuju svi podaci tog korisnika uključujući razinu i
lozinku korisnika, te lista svih OpenID oznaka koje je koristio taj korisnik za prijavu na web
aplikaciju.
50
Na slici 31 prikazana je stranica za ažuriranje korisničkih podataka popunjena
podacima korisnika palace.
Slika 31 Administracija korisničkih podataka
Administrator može mijenjati sve podatke nekog korisnika osim korisničkog imena dok
se OpenID oznake mogu samo brisati. Ažuriranje tih oznaka nema smisla, jer ako bi se
promijenila OpenID oznaka ona se ne bi više mogla koristiti za prijavu. Kod korisnika koji se
prijavio samo pomoću svog OpenID-a neće biti ispunjena sva polja koja su ponuđena
prilikom registracije. Kod tog korisnika će biti ispunjena samo polja ime i prezime, te e-mail
adresa. Prilikom ažuriranja mogu se unijeti i ostali podaci o korisniku.
5.3.2 Administracija novosti Kada administrator pristupi stranici za ažuriranje novosti prikazuje mu se tipka za
dodavanje novosti, te lista svih novosti.
51
Web stranica za administraciju novosti prikazana je na slici 32.
Slika 32 Administracija novosti
Za unos nove novosti potrebno je kliknuti na tipku dodaj novost. Nakon klika se otvora
forma s poljima za unos nove novosti. Prvo se treba odabrati kategorija novosti, a nakon toga
se unose obavezni podaci: naslov i autor teksta. Mogu se još unijeti i neobavezni podaci:
autor fotografija, kratki sadržaj novosti i tekst novosti. Pored polja link Picasa slike i kôd
Picasa galerija se nalazi ikona upitnika. Klikom na tu ikonu prikazuju se kratke upute kako se
spremaju slike pomoću Picasa Web Album Data API-ja, te je objašnjeno koji link odnosno
kôd treba kopirati u polja link Picasa slike i Picasa galerija da bi se prikazivali slika i galerija
slika prilikom pregleda novosti. Ako se kao kategorija novosti odabrala utakmice prikazati će
se i dodatna polja za unos podataka o toj utakmici. Podaci o utakmici koji se spreme
prikazivati će se zajedno s novosti, ali će se prikazivati i na stranici sa pregledom vaterpolo
utakmica pomoću sučelja mape. U slučaju da se za kategoriju novosti odabere divlja liga
prikazati će s edodatna polja za unos rezultata odigranih utakmica. Ti će se podaci prikazivati
skupa s novosti, ali izasebno kad se pristupi stranici za pregled rezultata divlje lige.
U listi novosti su prikazani osnovni podaci novosti: kategorija, naslov, te tri linka za
pregled, ažuriranje i za brisanje novosti. Link pregledaj pored novosti služi za prikaz novosti.
Nakon što se klikne na taj link prikazati će se svi podaci izabrane novosti.
52
Prilikom ažuriranja novosti mogu se mijenjati svi podaci. Zbog promjene kategorije
mogu se izbrisati podaci o utakmici u slučaju da se mijenja kategorija iz utakmice u neku
drugu kategoriju, a ako se promijeni kategorija novosti iz neke druge u utakmice mogu se
dodati podaci o utakmici. Isto vrijedi i za kategoriju novosti divlja liga gdje se mogu izbrisati
odnosno dodati podaci o rezultatima utakmica divlje lige.
Za brisanje novosti dovoljno je kliknuti na link briši odabrane novosti. Prilikom
brisanja novosti, zajedno s novosti se brišu i svi komentari korisnika vezani za tu novost.
Također, ako je kategorija novosti utakmice ili divlja liga izbrisati će se i podaci o toj
utakmici ili o rezultatima.
5.3.3 Administracija momčadi Na slici 33 prikazana je web stranica za ažuriranje momčadi.
Slika 33 Administracija momčadi
Nakon otvaranja stranice za ažuriranje momčadi Palace prikazuje se tipka za dodavanje
novog igrača te lista s osnovnim podacima o igračima: broj kapice, ime i prezime te linkovi
za pregled, ažuriranje i brisanje igrača. Link pregledaj pored igrača služi za prikaz podataka o
igraču. Nakon što se klikne na taj link prikazati će se svi podaci o igraču koji su uneseni.
Za dodavanje novog igrača treba kliknuti na tipku dodaj novog igrača. Nakon toga se
otvara stranica sa poljima u koja se unose podaci o igraču: ime, prezime, broj kapice,
pozicija, nadimak, mjesto rođenja, datum rođenja, horoskopski znak, klubovi u kojima je
igrao, najveći uspjesi, školska sprema, zanimanje, hobi, te slika igrača. Za razliku od novosti
kod kojih se slike spremaju pomoću Picasa Web Album Data API-ja ovdje se slike spremaju
53
direktno u bazu podataka zajedno sa svim ostalim podacima o igraču. Prilikom dodavanja
novog igrača u bazu podataka ako se ne preda slika spremiti će se inicijalno zadana slika.
5.3.4 Administracija rezultata Za ažuriranje rezultata treba kliknuti na link „rezultati” u horizontalnom izborniku
administratora pa će se prikazati web stranica prikazana na slici 34.
Slika 34 Administracija rezultata
Na stranici za ažuriranje rezultata se prikazuje link sa uputama za rad s Google mapom
i liste rezultata i utakmica. U uputama za rad s Google mapom je pojašnjeno kako se treba
prijaviti na aplikaciju Map Maker, te na koji način se dodaju markeri i opisi markera na
mapu.
Lista s popisom rezultata sadrži sve rezultate divlje lige koji su povezani s novostima
kojima je kategorija divlja liga. Ako se klikne na link pregledaj prikazati će se samo podaci o
rezultatima bez podataka o novosti koja je povezana s tim rezultatima. Također prilikom
54
ažuriranja mogu se ažurirati samo podaci o rezultatima. Ako se briše neki rezultat automatski
se briše i novost koja je povezana s tim rezultatima.
Lista s popisom utakmica predstavlja podatke o utakmicama dohvaćene iz novosti koje
se prikazuju na stranici sa Google mapom. Prilikom ažuriranja utakmice mogu se mijenjati
samo podaci o utakmici. Da bi se mijenjali podaci o novosti koja je povezana s tom
utakmicom treba se pristupiti stranici za ažuriranje novosti. Prilikom brisanja utakmice
automatski se briše i novost koja je povezana s tom utakmicom.
5.4 Komentiranje novosti
Prikaz komentara novosti za posjetitelje te za prijavljene korisnike i administratore
prikazan je na slici 35.
Slika 35 Prikaz komentara novosti
Prikaz komentara na dnu svake novosti razlikuje se za posjetitelje, korisnike i
administratore web aplikacije. Posjetitelji ne mogu komentirati članke pa se njima prikazuju
svi komentari novosti (slika 35.a). Nakon što se prijavi korisnik ili administrator njima se
prikazuje i polje za unos komentara iznad komentara novosti (slika 35.b). Nakon dodavanja
komentara isti će biti odmah prikazan zajedno s datumom unosa i korisničkim imenom osobe
koja ga je dodala.
55
ZAKLJUČAK
Razvojem web tehnologija Internet postaje sve dostupniji brojnim korisnicima. Na
raznim web stranicama može se pronaći sve više podataka i informacija, a putem web
stranica se prati sve više i više događaja. Da bi se prikupilo i stvorilo što više korisnih
informacija na web stranicama sve više se koriste hibridne web aplikacije.
Mnoge web stranice sadrže određene dijelove koji nisu dostupni svim posjetiteljima
stranice. Za pristup tim dijelovima potrebno se prijaviti na web stranicu pomoću korisničkog
imena i lozinke. Web stranice koriste dva načina provjere identiteta korisnika, a to su
centralizirana i decentralizirana provjera identiteta. Kod centralizirane provjere identiteta
prethodno je potrebno kreirati svoj korisnički račun koji se može koristiti samo na toj web
stranici. Za razliku od centralizirane provjere identiteta, kod decentralizirane se može koristiti
isti identitet na više web stranica. Najpoznatiji i danas najčešće korišteni protokol na webu
koji podržava decentraliziranu provjeru identiteta je OpenID protokol.
U sklopu ovog diplomskog rada realizirana je hibridna web aplikacija. Provjera
identiteta korisnika u njoj se provodi centralizirano i decentralizirano. Ova web aplikacija
omogućuje svim posjetiteljima pregled novosti, podataka o igračima momčadi Palace i
utakmicama putem grafičkog sučelja mape. Nakon prijave, korisnicima i administratorima je
omogućeno komentiranje novosti.
Kao platformu za razvoj ove hibridne web aplikacije odabrao sam ASP.NET
tehnologiju sa C# programskim jezikom te dva API-ja koja sam koristio za dohvat i pohranu
podataka. Za prikaz i pohranu lokacijskih podataka u obliku mape koristio sam Google Maps
API, a za prikaz i pohranu slika Picasa Web Album Data API. Razlog zbog kojeg sam
izabrao te API-je je njihova funkcionalnost, ali i to što omogućuju prijavu korisnika pomoću
istih, Googleovih korisničkih podataka čime se pojednostavljuje i olakšava njihovo
korištenje.
Smatram da je ovakva arhitektura aplikacije pogodna za razvoj i korištenje u praksi
jer omogućava korištenje različitih API-ja i drugih funkcionalnosti proizvođača
specijaliziranih za određeno područje. Time se osigurava da se u konačnom rješenju
jednostavno mogu uklapati i koristiti različiti elementi najboljih proizvođača.
56
LITERATURA [1] G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Languange User Guide,
Addison Wesley Longman, Inc., Massachusetts, SAD, travanj 2000.
[2] J. Daemen, V. Rijmen, AES Proposal: Rijndael,
http://csrc.nist.gov/archive/aes/rijndael/Rijndael-ammended.pdf (20.06.2010.)
[3] S. Downes: Authentication and Identification, International Journal of Instructional
Technology and Distance Learning, Vol. 2, No. 10, listopad 2005.,
http://www.itdl.org/Journal/Oct_05/article01.htm (11.06.2010.)
[4] R. T. Fielding: Architectural Styles and the Design of Network-based Software
Architectures, Dissertation, University of California, Irvine, 2000.,
http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
(08.06.2010.)
[5] M. Hämäläinen: Centralized Identity Managment for Web Applications, Lappeenranta
University of Technology, Helsinki, Finland, siječanj 2008.
https://oa.doria.fi/bitstream/handle/10024/36213/CentralizedIdentityManagementFor
WebApplications_2008_01_16.pdf?sequence=1 (20.06.2010.)
[6] J. Krolo, M. Šilić, S. Srbljić: Security of Web Level User Identity Managment, FER,
Zagreb, 32nd International Convention MIPRO 2009, svibanj 2009.
[7] M. MacDonald (prijevod: D. Žujović): ASP.NET 3.5 i C# 2008: od početnika do
profesionalca , Kompjuter biblioteka, Beograd, 2009.
[8] E. Maler, D. Reed: The Venn of Identity: Options and Issues in Federated Identity
Management, IEEE Security & Privacy, Vol. 6, No. 2, 2008., pp. 16-23
[9] U. Marjit, S. Jana: Mashups: An Emerging Content Aggregation Web 2.0 Paradigm.
Pondicherry University, Puducherry, 7th International Caliber 2009., veljača 2009.,
pp. 296-303
[10] A. Nanda, Identity Selector Interoperability Profile V1.0, Microsoft, travanj 2007.,
http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-
6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf (12.6.2010.)
[11] T. O'Reilly: What Is Web 2.0, Design Patterns and Business Models for the Next
Generation of Software, http://oreilly.com/web2/archive/what-is-web-20.html
(05.06.2010.)
[12] T. Pavić, L. Jelenković: Autentifikacija i autorizacija korisnika na jednom mjestu,
FER, Zagreb, 30th Jubilee International Convention MIPRO 2007, svibanj 2007.
57
[13] ***, ASP.NET Master Pages Overview,
http://msdn.microsoft.com/en-us/library/wtxbf3hh.aspx (24.06.2010.)
[14] ***, DotNet OpenID, http://code.google.com/p/dotnetopenid/ (16.06.2010.)
[15] ***; Flickr API, http://www.flickr.com/services/api/ (10.06.2010.)
[16] ***, Flickr vs Picasa, http://www.slideshare.net/songvision/flickr-vs-picasa-
presentation (10.06.2010.)
[17] ***; FreeTextBox, http://freetextbox.com/ (15.06.2010.)
[18] ***; Google Maps API, http://code.google.com/apis/maps/ (09.06.2010.)
[19] ***, Introducing Java Portlet Specifications: JSR 168 and JSR 286,
http://developers.sun.com/portalserver/reference/techart/jsr168/ (08.06.2010.)
[20] ***; Map Maker, http://mapmaker.donkeymagic.co.uk/ (22.06.2010.)
[21] ***, Mashups, Cognizant Technology Solutions, New Jersey, SAD, srpanj 2007.,
http://trust.cognizant.com/synapses2/downloads/papers/Synapses2.0_mashups.pdf
(08.06.2010.)
[22] ***, OpenID, http://openid.net/ (12.06.2010.)
[23] ***, Picasa Web Albums Data API,
http://code.google.com/apis/picasaweb/overview.html (10.06.2010.)
[24] ***, Panoramio, http://www.panoramio.com/ (10.06.2010.)
[25] ***, Photobucket, http://photobucket.com/ (10.06.2010.)
[26] ***, Programmable Web, http://www.programmableweb.com/ (12.06.2010.)
[27] ***, SAML V2.0 Executive Overview, Working Draft 03, OASIS, veljača 2005.,
http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-
overview-2.0-draft-03.pdf (12.06.2010.)
[28] ***, Yahoo Maps API, http://developer.yahoo.com/maps/ (09.06.2010.)
[29] ***, Wikipedia: API, http://en.wikipedia.org/wiki/Api (07.06.2010.)
[30] ***, Wikipedia: Atom (standard), http://en.wikipedia.org/wiki/Atom_(standard)
(07.06.2010.)
[31] ***, Wikipedia: Identity 2.0, http://en.wikipedia.org/wiki/Identity_2.0 (20.06.2010.)
[32] ***, Wikipedia: Mashup (web application hybrid),
http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid) (07.06.2010.)
[33] ***, Wikipedia: OpenID, http://en.wikipedia.org/wiki/OpenID (25.06.2010.)
[34] ***, Wikipedia: RSS, http://en.wikipedia.org/wiki/Rss (07.06.2010.)
[35] ***, Wikipedia: Web 2.0, http://en.wikipedia.org/wiki/Web_2.0 (05.06.2010.)
58
[36] ***, Windows CardSpace,
http://www.microsoft.com/windows/products/winfamily/cardspace/default.mspx
(13.06.2010.)
[37] ***, WSRP v2.0 Specification,
http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.html (08.06.2010.)
59
POPIS SLIKA Slika 1 Način rada jedne jednostavne hibridne web aplikacije .................................................. 6
Slika 2 Arhitektura hibridne web aplikacije .............................................................................. 9
Slika 3 Usporedba normalne, satelitske i hibridne Google (a, c, e) i Yahoo mape (b, d, f) .... 11
Slika 4. Struktura Picasa i Flickr servisa ................................................................................. 12
Slika 5. Model centralizirane provjere identiteta korisnika ..................................................... 15
Slika 6 Utvrđivanje identiteta korisnika - pokrenuto od davatelja usluge ............................... 17
Slika 7 Utvrđivanje identiteta korisnika - pokrenuto od davatelja identiteta ........................... 17
Slika 8 Proces provjere identiteta pomoću OpenID protokola ................................................ 19
Slika 9 Struktura web aplikacije .............................................................................................. 20
Slika 10 Dijagram slučajeva korištenja .................................................................................... 21
Slika 11 Dijagram dekompozicije funkcija web aplikacije ..................................................... 22
Slika 12 Dijagram konteksta .................................................................................................... 24
Slika 13 Pregledni dijagram ..................................................................................................... 25
Slika 14 Dijagram procesa registrirati novog korisnika .......................................................... 26
Slika 15 Dijagram procesa ažurirati podatke o novosti ........................................................... 27
Slika 16 Dijagram procesa dodati novu novost........................................................................ 28
Slika 17 ERA model baze podataka......................................................................................... 29
Slika 18 Shematski prikaz baze podataka ................................................................................ 31
Slika 19 Proces centralizirane provjere identiteta korisnika .................................................... 33
Slika 20 Proces decentralizirane provjere identiteta korisnika Google korisničkim računom 34
Slika 21 Forma za dodavanje novosti kategorije utakmice ...................................................... 37
Slika 22 Sučelje Map Maker aplikacije ................................................................................... 40
Slika 23 Odabir linka na sliku pohranjenu pomoću Picase ..................................................... 41
Slika 24 Podešavanja koda galerije slika ................................................................................. 42
Slika 25 Proces registracije novog korisnika ........................................................................... 44
Slika 26 Prijava pomoću OpenID-a ......................................................................................... 45
Slika 27 Prijava pomoću MyOpenID davatelja usluga ............................................................ 46
Slika 28 Unos dodatnih podataka o OpenID korisniku ........................................................... 47
Slika 29 Provjera e-mail adrese i nadimka prilikom OpenID prijave ...................................... 48
Slika 30 Administracija korisnika ............................................................................................ 49
Slika 31 Administracija korisničkih podataka ......................................................................... 50
60
Slika 32 Administracija novosti ............................................................................................... 51
Slika 33 Administracija momčadi ............................................................................................ 52
Slika 34 Administracija rezultata ............................................................................................. 53
Slika 35 Prikaz komentara novosti .......................................................................................... 54