61
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.

Tomo Sjekavica Diplomski zavrsna - bib.irb.hr · 2 ABSTRACT This thesis describes the implementation of the hybrid web application that combines Google Maps and Picasa Web Album Data

  • 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