BAZA ZNANJA
|
Kurs: PHP programiranje Materijali vezani uz ovu lekciju: - Test kretanje podataka kroz response-request proces - Kretanje podataka kroz response-request proces (PDF dokument) Osnove funkcionisanja HTTP protokolaDa bi se razumelo kako se prenose podaci kroz reponse/request proces, odnosno, sa jedne web stranice na drugu, ili jedne aplikacije na drugu, ili, jednostavno, sa weba do neke aplikacije i obrnuto, potrebno je razumevanje o tome kako HTTP protokol funkcioniše.HTTP (Hyper Text Transfer Protocol) je protokol čija je uloga koordinacija zahteva i odgovora na Internet-intranet mreži. Ove zahteve postavljaju obično razni klijenti (razni oblici aplikacija), dok su za odgovore zaduženi web serveri. Nezavisno od tipa, klijent se u ovom procesu naziva user agent, dok se server naziva origin server. Kada dođe do zahteva, user agent prosleđuje serveru informacije o tome koje MIME tipove (Multimedia Internet Mail Extensions – ovo su razni oblici dokumenata, html, slika, arhiva...) može da prihvati, koju verziju HTTP protokola zahteva, koja verzija user agenta je u pitanju, koji kodni raspored zahteva, referera (stranu sa koje je došao zahtev, ukoliko je došao sa neke strane), podakte o kolačićima, koji je status keša user agent-a (da li je strana keširana na klijentu)... Zahtev sadrži u sebi i HTTP metod, odnosno, obrazac koji web server treba da ispoštuje prilikom obrade zahteva i rukovanja resursima. Metod bi najbolje mogao da se okarakteriše kao najobičnija naredba. Ako bismo, npr. otkucali u pretraživaču www.mojsajt.com/index.html, mogli bismo biti sigurni da će negde u našem zahtevu postojati linija: GET /index.html HTTP/1.1 Kao i linija Host: www.mojsajt.com gde je GET naziv metoda, /index.html adresa koja se zahteva, HTTP/1.1 verzija protokola i Host: www.mojsajt.com naziv top domena za taj sajt. Na osnovu ovih informacija, web server formira odgovor i prosleđuje ga klijentu. GET nije jedini metod. Osim njega, za nas korisni metodi su i HEAD i POST. Pored njih, postoji još nekolicina request metoda PUT, DELETE, OPTIONS, CONNECT... Na zahtev formatiran na pomenuti način, server formira odgovor i prosleđuje ga nazad pošiljaocu (a server u svakom trenutku zna IP adresu i port, gde se od njega očekuje da prosledi odgovor). Odgovor servera sadrži status - 200 ako je sve u redu i mnoge druge brojeve grešaka, ukoliko nešto nije kako treba. Brojevi sa kojima se najčešće susreće su 404 (tražena strana ne postoji) i 500 (greška u web aplikaciji). Zapravo, statusi se po brojevima dele na određene grupacije: 1xx za informacije, 2xx sve vrste uspešnih apstrakcija, 3xx redirekcije, 4xx klijentske greške, 5xx serverske greške. Pored statusa, u odgovoru se obično nalazi i heder, kao i sam sadržaj dokumenta. Ceo proces izgleda ovako: Klijent unosi adresu: http://www.mojsajt.com/index.html ... user agent otvara socket preko porta 80 i šalje zahtev preko njega: GET /path/file.html HTTP/1.0 Nakon toga, potpuno je nebitno šta će user agent učiniti sa dobijenom odgovorom. U slučaju web pretraživača, ovaj odgovor će biti parsiran, preveden i emitovan korisniku, ali, aplikacija se može baviti i raznim drugim stvarima. Na primer, crawler, sistem za analizu internet saobraćaja... Na osnovu ovih informacija, vidi se da stvari putem HTTP-a funkcionišu dosta jednostavno. Transport stanjaVideli smo kako se tokom request/response procesa prosleđuju podaci. Klijent traži od servera podakte i server mu šalje te podatke u odgovoru. Ali, problem je u tome što server nije u stanju da prepozna ko mu je šta tražio. On, jednostavno, na osnovu IP adrese i porta, prosleđuje odgovor nazad i to je sve. To znači da nije u stanju da vidi da li je, na primer, korisnik još uvek na web strani koju je emitovao. Kaže se zato, da je HTTP protokol stateless.Ovakav način funkcionisanja je logičan, obzirom da se dva različita posla obavljaju na dve različite lokacije (klijentu i serveru) nevezani jedan za drugi, ali nosi i svoje probleme, jer je, da bi se podaci o stanju prosleđivali tokom response/request procesa, potrebno upotrebiti posebne metode. Postoje tri različita načina da se rukuje stanjem u PHP-u u web aplikaciji. U ovoj lekciji, objasnićemo načine njihovog funkcionisanja, a u narednim i kako se praktično upotrebljavaju. GET/POSTOva dva metoda, pomenuta su u kontekstu HTTP zahteva (request-a).GET GET, kao osnovni i najčešći metod za dobijanje serverskog odgovora, prilaže adresu na kojoj se nalazi željeni odgovor. Ali, pored tražene adrese, zahtev može sadržati i određene parametre koje je server u stanju da razlikuje, pa tako i programer može da ih upotrebi u serverskom kodu. Parametri poslati kroz GET metod nisu nimalo bezbedni, štaviše, veoma su nebezbedni jer se emituju u Query stringu (string koji predstavlja kompletnu adresu strane). Zato se često, GET parametri kriptuju. Npr. www.mojsajt.com/index.php?id=098f6bcd4621d373cade4e832627b4f6. Na ovakav način ne prenose se nikakve bezbednosno vitalne informacije, već obično ovakav kod prezentuje kodiranu reprezntaciju nekog dela izvora podataka gde se određene informacije nalaze. Pa tek odatle, mogu se izvršiti određene ozbiljnije provere (npr. provera korisnika). Ali, čak iako je izveden na taj način, prenos bitnih podataka putem Query stringa je nebezbedan i nepreporučiv. Pored toga, nije moguće preneti veliku količinu informacija. Ovo ne znači da Query string za prenos informacija treba izbegavati, kada govorimo o informacijama koje nemaju bezbenosni kontekst. Npr. www.mojsajt.com/index.php?proizvod=15. Ovde je pristup slanja podatka kroz Query string dobar, jer maliciozni korisnik ne može da uradi ništa aplikaciji ukucavanjem pogrešnog broja proizvoda (osim da dođe do proizvoda koji ne želi), a link je čitak i funkcionalan. Naravno, obavezno je da sva odstupanja od željenog scenarija moraju biti obrađena u serverskom kodu. Jedan od oblika manipulacije Query stringom je i prepisivanje url-a. Prepisivanje url-a funkcioniše tako što na samom web serveru odredimo određene konvencije, koje će web server poštovati i na osnovu njih praviti odgovore. Te konvencije su međusloj, između stvarne hijerarhije fajlova na web serveru i onoga što korisnik zahteva u upitu. Malopređašnji primer: www.mojsajt.com/index.php?proizvod=15 mogli bismo prevesti u: www.mojsajt.com/proizvodi/15 , ukoliko kažemo serveru da deo adrese »proizvodi« tretira kao index.php?proizvod= , a deo sa brojem (u ovom slučaju 15), kao drugi deo adrese. Na ovaj način, moguće su moćne manipulacije nazivima adresa (URI-jima). Na primer, bez problema je moguće sve .php ekstenzije na serveru prikazati kao .aspx ili bilo koje druge ekstenzije, a da se pri tom, na serveru i dalje izvršavaju php aplikacije. Prepisivanje URL-a, kao modul, treba zasebno startovati u okviru apache servera i često je isključeno ili zabranjeno, ukoliko ne koristite sopstveni server za host. To je zato što ovaj modul može dovesti do problema prilikom nepažljivog rukovanja. Na primer, može se lako desiti da zaključate folder u kome radite i da posle toga ne možete više da mu pristupite, što može biti veliki problem ako koristite udaljeni, automatski, hosting sistem. POST POST metod funkcioniše nešto drugačije od GET metoda, i bezbednosno je na samo malo višem nivou. Naime, prilikom slanja zahteva serveru, ukoliko zahtev poziva ovaj metod, u telu zahteva se očekuje i set serijalizovanih podataka koje server, odnosno, aplikacija na serveru, može uzeti za obradu. Informacije prenešene ovim putem, ne mogu se videti »golim okom«, ali već pregledom izvornog HTML koda strane, lako je doći do svih transportovanih podataka. Ovakav način prosleđivanja podataka koristi se obično za aplikacije na kojima se obrađuju kontrole (forme) i nije naročito dobar za promociju određene web strane, zato što nije moguće samo proslediti adresu strane, jer ona neće dati rezultate bez podataka koje zahteva. A da bi te podatke prosledili, potrebna nam je forma koja će ih serijalizovati i poslati. Cookie (kolačići)Dva do sada pomenuta načina, iako to nije neizvodljivo, nisu baš uzori za bezbedno čuvanje stanja u request/response procesu. Informacije putuju pred očima korisnika u često nekriptovanoj formi i čine ove metode nebezbednim za bilo koju informaciju koja treba da bude sigurna i skrivena.Za razliku od njih, cookie je nešto bolji način da se očuva sigurnosni integritet informacije kroz proces. Zapravo, on i ne učestvuje aktivno u procesu, već čuva podatak na klijentskom računaru (ne učestvuje u procesu u smislu toga da se neće videti, ali jednom aktiviran, kolačić jeste deo svih zahteva tom serveru do isteka važnosti). Ovakav pristup omogućava da podaci budu čuvani vremenski neograničeno i da se manipulacija njima vrši samo onda kada je to potrebno i time smanji opterećenje protoka podacima. Kolačići se nalaze na klijentskom računaru, pa postoji šansa da budu obrisani ili ukradeni. Ali, u svakom slučaju, oni su odličan način da server, prilikom svakog zahteva, ukoliko to želi, precizno zna sa kojim klijentom komunicira. Treba naglasiti da kolačići (kao ni sessioni, o kojima će biti reči u sledećem pasusu) nisu preporučivi za skladištenje velike količine podataka. Ovo su mali blokovi podataka (ne veći od 4k po sajtu) i služe da se u njih smeste samo najosnovniji podaci koji povezuju klijenta i server. Na primer, ID korisnika, čije će, sve ostale informacije pod tim brojem, biti izvučene iz nekog izvora podataka na samom serveru. Sessions (sesije)Konačno, poslednji i najpopularniji način za čuvanje stanja na web serveru je sesija. Generalno, sesija funkcioniše slično kolačiću ali podrazumeva da ćete podatke o klijentu uskladištiti na samom serveru.Ovo funkcioniše tako što, kada klijent prvi put zatraži otvaranje sesije, na web serveru se generiše jedinstveni broj (phpsessid) koji će ubuduće predstavljati tog klijenta u listi sesija. Ovaj ID se zapamti u fajlu na serveru (session store file) i biva prosleđen klijentu. Klijentska aplikacija zatim formira kolačić, u kome se nalazi ovaj broj i uz svaki zahtev ga prosleđuje serveru kako bi server identifikovao sesiju i iz nje prosledio tražene podatke. Iako su sesije predviđene da funkcionišu uz pomoć kolačića, nije obavezno imati kolačiće da bi se rukovalo sesijama. Moguće je do sesije doći i ručno, tako što se u Query stringu prosleđuje serveru i ID sesije: http://www.mojsajt.com/index.php?PHPSESSID=be20081806199800da22e24081964000 Što se informacija tiče, kao i za ostale opisane sisteme, tako i za sesije, važi da nije poželjno skladištiti u njima prave informacije, već radije samo identifikatore kojima možemo doći do pravih informacija iz nekog izvora podataka na serveru. Sesije su bezbednosno dosta »čvrste«, ali ne i »neuništive« (npr, pomenutom tehnikom slanja id-a sesije kroz Query string, moguće je pogađanjem doći do tuđe sesije, pa tako i do tuđih podataka (session hijack)). Najvažnije iz lekcije
|