Najbolji način za slanje ajax request argumenata (google maps)?

Pozdrav svima.

Bez sumnje naslov teme je nejasan i vjerojatno pogrešan, no nekoliko minuta sam izgubio pokušavajući u jednoj rečenici sažeti srž problema što nije jednostavno. Imam sljedeći problem koji ću pokušati opisati.

Unutar postojeće skripte izvršava se mysql query koji daje rezultate ovisno o tome radi li korisnik browse, search, itd… Rezultate queryja bi trebalo prikazati na google maps. U bazi su već upisani longitude i latitude. Best practice jest da se napravi asynchronous request koji zatim vraća rezultate u xml (ili JSON, moguće i text) formatu koje google maps api parsa i prikaze odgovarajuće markere, na idući način:

downloadUrl("../gmaps_generatexml.php", function(data) {
        var xml = data.responseXML;
        var markers = xml.documentElement.getElementsByTagName("marker");

Ono što mene muči jest da u trenutku kada već imam mysql rezultate jedino sto mogu jest dodavati markere kroz loop i generirati javascript, dakle nema asinhronog requesta i kod veće količine to će vrlo brzo postati problematično, dakle otpada kao opcija.

Moje osnovno pitanje jest kako najbolje riješiti da bude efikasno i sigurno. U trenutku kada se generira google mapa ja rezultate već imam u arrayu (koji su u osnovi neupotrebljivi jer ih moram nanovo generirati unutar gmaps_generatexml.php) ali imam i sve mysql query parametre kao uostalom i kompletan query string. Što napraviti:
[list][:11veces9]Prvo što mi pada na pamet jest poslati kompletan query string kao parametar za gmaps_generatexml.php (downloadUrl("…/gmaps_generatexml.php?query=$querystring") koji se tamo nanovo izvrši. Je li ovo pametno i kako to napraviti na ispravan, tj. siguran način?[/:m:11veces9]
[:11veces9]Drugo, mogu proslijediti parametre za sam query kojeg zatim generiram u samom gmaps_generatexml.php. Ovo je vjerojatno puno sigurnije, ali me također zanima pravilan način za to napraviti.[/:m:11veces9]
[:11veces9]Treće, potpunosam na krivom kolosjeku i postoji bolji način da se ovo riješi.
Nisam ubacio kod jer se nadam da sam uspio dovoljno jasno objasniti, međutim ako treba poslat ću primjer da pojasnim problem.[/
:m:11veces9][/list:u:11veces9]

Hvala!

Nisam nikada radio s Googleovim mapama, pa ću elaborirati tvoj zadatak da vidimo jesam li ga ispravno shvatio.

Dešava se slijedeći scenarij:

  1. Korisnikov preglednik, opcionalno u kontektsu sjednice S, postavlja zahtjev za nekom web-stranicom na urlu URL1, npr. “browse.php” ili “search.php” ili sl.

  2. U skripti koja implementira stranicu se nalazi neki program P koji parametre query stringa tog URL-a, QS(URL1), te opcionalno neke podatke dostupne iz perzistentnog spremnika, a referencirane kroz identifikator sjednice, D(S), pretvara u argumente SQL upita
    A(SQL1) := P(QS(URL1), D(S)), što rezultira recordsetom R := SQL1(A(SQL1)) = P(QS(URL1), D(S)).

  3. U skripti se potom na drugom mjestu generira dio HTML-a rezultirajuće stranice koji sadrži SCRIPT element kojem je svrha naknadno na strani klijenta dinamički modificirati web-stranicu u kojem je on sadržan, a koristeći R.

  4. HTML web-stranice generiran u koracima (2) i (3) se vraća pregledniku kao odgovor na zahtjev 1.

  5. Preglednik obrađuje HTML dobiven u koraku (4) i u nekom trenutku izvrši SCRIPT element iz koraka (3).

  6. U SCRIPT elementu iz koraka (3) se poziva client-side procedura koja uzima URL XML-datoteke s podacima iz R, neki URL2. Taj URL2 može sadržavati iste parametre u query-stringu kao i URL1, te program P, a kako se izvodi u kontekstu iste sjednice kao i URL1 u koraku (1), to vrijedi da ako URL2 implementiraš sa skriptom koja sadrži isti program P kao i URL1, onda možeš upotrijebiti način koji si ti predložio pod brojem 2, posve siguran da će ta implementacija biti najmanje jednako sigurna kao i implementacija skripte URL1 kojoj posjetitelj web-stranica pristupa izravno.

Jednostavnije rečeno:

  • Ako korisnik pristupa stranici <search.php?param1=val1&param2=val2>, onda proceduri downloadUrl kao prvi parametar predaj URL <search.php?param1=val1&param2=val2&gmaps=true>.

Ovaj switch “gmaps=true” će uputiti skriptu na urlu URL1 da ne generira HTML web-stranice, već XML iz recordseta R iz koraka 2.

Ukoliko je URL1 nekakva web 2.0 stranica puna AJAX-a u kojoj kroz interakciju s korisnikom nastaje A(SQL1), onda jednostavno raspiši novu stranicu URL2 tako da dobiješ čisti QS(URL1) i izradi program P koji će iz QS(URL1) i D(S) generirati A(SQL). Ideja je ovdje da QS(URL1) sadrži podatke u takvom formatu da se na serveru mogu testirati kako ne bi doveli do rušenja, gušenja ili “probijanja” programa P dok ih pretvara u “sirove” i “opasne” podatke koji čine A(SQL1) . Tada proceduri downloadUrl predaj URL2, a ponovo implementiraj URL1 tako da i ta stranica ona koristi URL2 kako bi si olakšao održavanje i testiranje. Svakako pri tome razmisli da koristiš parametrizirane upite, umjesto slaganje SQL-a konkatenacijom stringova, dakle da koristiš PDO ili mysqli.

Hvala tsereg, tocno si opisao citavu proceduru i ujedno dao odgovor na moje pitanje. Idem odmah na posao.
Zaboravio sam spomenuti da mi je palo na pamet da originalni query odmah generira xml file za google maps u tmp direktoriju koji kasnije JS procita. Na taj nacin izbjegavam dodatni query na bazi ali imam dodatni connection request - jedino sto moram modificrati filename da bude unique, recimo da user ili session ID-jem. Kako ti se cini ta ideja? Istovremeno izbjegavam slanje parametara uokolo.

Radiš u vrlo asinkronoj okolini i očekivati da će se nešto dogoditi prije, a nešto kasnije nije - kao stvar načela - preporučljivo, ma kako se zaključci činili nužnim. Ako ne moraš nešto pretpostavljati, nemoj. Pogotovo zato što ništa ne dobivaš. Time što si prenio samo jedan parametar, ako prenošenje parametara može uzrokavati štetu, uzrokovati je može i ako prenosiš samo jedan. Ako - pak - možeš zaštiti taj jedan parametar, onda nužno možeš zaštiti i više njih. Konačno, skupljaš po disku međuspremnike neutvrđenih duljina koji se koriste jednokratno (dakle nisu cache) , o čijim pravodobnim brisanjima moraš voditi računa (zombiji?).

Ako bi imao problema s prenošenjem parametara (npr. previše ih je za query-string), onda parametre pohrani (u datoteku ili bazu) na sličan način kako si mislio pohraniti cijeli recordset. Ali je svakako bolje da osiguraš pouzdani prijenos parametara - naprosto zato što to nije nešto što treba izbjegavati, već je nešto što treba naučiti ispravno raditi.

Konačno, tek ako bi generirane podatke mogao ponovo iskorištavati, onda ima smisla pohranjivati ih kako si gore opisao, u svrhu cacheiranja zapisa - ali to isto nije trivijalan problem.

Google sam predlaže korištenje datoteke ili ajax requesta za dohvat podataka što me i nagnalo da krenem razmišljati o datoteci.
Nakon razmišljanja o toj opciji sa datotekom, čini mi se sve praktičnija što se implementacije tiče. Nakon početnog queryja generiram privremenu xml datoteku koju mogu obrisati odmah nakon što ju je javascript kod pročitao (pozivom php koda ne serveru). Tako ipak minimiziram moguće sigurnosne propuste iako se slažem da treba i slanje parmetara svladati na ispravan način. Probat ću u testnom okružju jedno i drugo ia vidjeti kako se što ponaša u stvarnosti.

Nisam sve skužio, ali čemu generiranje datoteke, kada sve što budeš zapisao u tu datoteku možeš pročitati odmah s JavaScriptom? Pa pobogu zato se i zove “asynchronous javascript and xml”.

[quote=""]U trenutku kada se generira google mapa ja rezultate već imam u arrayu (koji su u osnovi neupotrebljivi jer ih moram nanovo generirati unutar gmaps_generatexml.php[/quote]Kako ti se može mapa generirati bez podataka, mislim da imaš negdke grešku u koracima.

S obzirom da nisam skužio što želiš postići ):, teško mogu dati ikakav imalo kvalitetniji odgovor. Kada bi barem mogao bolje pojasniti koji je tvoj osnovni problem koji želiš riješiti možda bi bio od veće koristi.

Datoteka se generira kako bih izbjegao dodatni (identični) query na bazu da pokupim iste podatke - dakle zašto taj xml ne kreirati odmah kod prvog queryja i ostaviti ga za kasnije umjesto nanovo izvršiti isti query “na zahtjev”.
Ne znam gdje si zakljucio da se “mapa generira bez podataka”, srž diskusije i osnovno pitanje je upravo koji je način bolji za generirati iste.

[quote=“Riba”]Nakon razmišljanja o toj opciji sa datotekom, čini mi se sve praktičnija što se implementacije tiče. Nakon početnog queryja generiram privremenu xml datoteku koju mogu obrisati odmah nakon što ju je javascript kod pročitao (pozivom php koda ne serveru).[/quote]To je manje diskretna opcija. Naime, nigdje ne stoji da će javascript ikada pročitati tu datoteku, tj. da će se naknadni asinkroni zahtjev stvarno dogoditi - tako će ti ostajati “zombi” datoteke. Ako ipak ideš u tom smjeru, onda odmah počni ići u smjeru cachea, tj. da datoteka jednostavno stoji na serveru i može biti kasnije iskorištena i od same glavne stranice kada korisnik ponovo pristupi. Ionako moraš riješiti problem brisanja zombi-datoteka, pa to možeš riješiti u sklopu sustava keširanja.

Ja osobno ne bih išao na to rješenje, već bih takvo rješenje implementirao povrh ovog prethodnog u kasnijem koraku.

U pravu si, ne mogu računato na to da će datoteka i biti pročitana. U međuvremenu pojašenjenje za CreatifCode: sam ajax request u mojem konekretnom sučaju nema neku namjenu jer se kriterij za izbor podataka neće mijenjati osim reloada stranice, jer ovisim o već postojećem sustavu odabira podataka koji ne koristi ajax, no za loadanje google markera ga moram koristiti.

Samo misao: Ako se sve to događa u istom sessionu zašto umjesto spremanja u datoteku ne spremiš u session? Naravno ako se ne radi o velikoj količini podataka.

Rezultat queryja? Potencijalno se može raditi o tisućama unosa, pa vjerojatno nije opcija.

A kako se ti markeri prikazuju odjedamput su otvoreni ili kad korisnik napravi neki event na google maps i otvara se jedan marker?

gorrc, ne, prikazuju se svi odjednom ovisno o rezultatima queryja koji se izvršava na samom početku, dakle nema naknadnih izmjena na njima (osim ako ne kreneš u različiti browse/search, ali to znači reload). Zato i kažem da je tu ajax request u stvari nije ključan, međutim i dalje je potreban jer je najefiksniji za load.

Update: prošao sam kroz postojeći kod koji ovisno o opcijama generira WHERE izraz za mysql query i sprema ga u $where_query varijablu. S obzirom na to najjednostavnije je jednosatvno poslati tu varijablu na gmaps_generatexml.php:

downloadUrl("../gmaps_generatexml.php?dbwhere=<?php echo $where_query; ?>", function(data) {
        var xml = data.responseXML;
        var markers = xml.documentElement.getElementsByTagName("marker");

Ovo će sigurno raditi ali bi vjerojatno trebalo sigurnije poslati/primiti tu varijablu?

Tnx još jednom svima!

Ovo su ti trokrilna vrata širom otvorena za SQL-injection. A sadržaj WHERE klauzule SQL-a koji primaš kao ulazni argument ne možeš pozdano verificirati drugačije nego da napišeš parser za SQL što, naravno, nije opcija. Dakle, gornji primjer je definitivno :nene:. A i ne zaboravi da u query-string baš i ne možeš stavljati roman.

Ipak, sada ti u obzir dolazi ovo što je eke rekao, a to je spremanje WHERE izraza u sjednicu (među podatke sjednice na serveru), kada se moraš, pretpostavljam, samo pobrinuti da ti se ne desi session hijacking.

To me zanimalo budući da mi te stvari nisu jača strana. Šteta bi bilo ne iskoristiti tu varijablu kada je već servirana na pladnju. Idem proučiti sessione.

Edit: sve jasno. :slight_smile: Ima netko kratki best practices za korištenje sessiona?

Ok, našao sam da imam na raspolaganju $session klasu. Mislim da je sada sve na svojem mjestu, još jednom zahvaljujem svima na pomoći i ispričavam se na mogućim glupim pitanjima.

Baš radim nešto sa “localStorage” i sjetio sam se da bi to bila odlična stvar za tebe. Vidi
http://diveintohtml5.org/storage.html

Uglavnom, umjesto spremanja u session spremiš sve javascriptiom u taj localStorage što sprema u interno spremište od browsera.

[HTML]localStorage.setItem(“test”, “1234”);
localStorage.getItem(“test”); //dobiješ 1234[/HTML]

Za starije verzije browsera možeš koristiti jQuery plugin koji simulira localStorage:
http://plugins.jquery.com/plugin-tags/localstorage

Local storage mi je zanimljiv iz drugih razloga pa ću se poigrati s time. U međuvremenu sam riješio preko sessiona i to lijepo radi, nadam se da mi nije nešto promaklo. :slight_smile:
Ipak nema smisla spremati ove podatke lokalno.

Riba se ovdje brine za sigurnost. Naime, on želi pohranjivati sirovi WHERE – ako bi ga pohranjivao na strani klijenta, imao bi istu sigurnosnu rupu kao da ga drži u query-stringu.


Copyright © 2020 WM Forum - AboutContact - Sponsored by: Mydataknox & Webmaster.Ninja