Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Kako da bezbedno utvrdite da li Java radi u node.js ili pretraživaču



U toku rada na javascript biblioteci, namenjenoj za upotrebu oba, i server i klijenta, naišao sam na zanimljiv problem; kako pouzdano otkriti šta okruženje javascript-a pri pokretanju radi vašem tekstu? Pogledao sam oko sebe i nsam mogao da pronađem zadovoljavajuće rešenje, tako da sam odlučio da pogledam dublje u problem.

Problem je u tome što se svaka promenljiva može slobodno objaviti i modifikovati, što nam veoma otežava da shvatimo koje varijable su poreklom iz okruženja, a koje su izmenjene u ranijim pismima. Dok sagledavam problem fokusiran sam na koje iskaze mogu da se oslanjam, a na koje ne mogu.

Node.js, biblioteke se učitavaju pomoću zahteva funkcija za učitavanje modula po imenu. U biblioteci datoteke modula, objekti koji su definisani u okviru skripte izloženi su u node.js dodeljivanjem promenljivih na exports objekta koji je dostupan za vas od node. Exports varijable mogu se navesti preko modula varijable, kao module.exports.

Ispostavilo se, da na strani servera, možete bezbedno pretpostaviti da je export promenljivih naveden kao ispravan objekat. To je zato što zahtevne funkcije definišu modul i exports u okviru zatvaranja za tu funkciju, i redefiniše da to bude prazan objekat. Ako je vaš kod samo opterećen preko zahtevnih funkcija, može se pretpostaviti da su spoljne skripte promenljive upućivale ispravne node.js objekte, bez obzira na promene načinjene u globalnom obimu od bilo kog drugog programera.

Ako je vaša biblioteka samo dizajnirana da se pokrene na strani servera, nema potrebe da radite bilo kakvu promenu okruženja. Međutim, ako želite da kreirate biblioteku za upotrebu na oba, i servera i klijenta, poželjno je da se obezbedi isti scenario za oba, zbog jednostavnosti i lakoće održavanja.

Underscore je biblioteka koja se suočava sa ovim problemom,i pruža rešenje kucanjem :

    typeof module !== 'undefined' && module.exports


Ova tehnika jednostavno proverava da li modul postoji i ako taj objekat ima exports u okviru nje. U tom trenutku ona samo pretpostavlja da je modul referenciran objekat sa ispravnim ponašanjem, jer objekat je dovoljno sličan u obliku koji smo očekivali, i umetnuti pristup promenljivoj čini šansu da promenljive budu manje sukobljene od očekivanih, više nejasnih promenljivih struktura.

Iako je ova tehnika je dovoljno dobra za najveći deo, ipak ima mana tako da na kraju programer ne može da definiše objekat referenciran od modula koji ima exports promenljivu. U redu, naravno da je to prilično neverovatno. Međutim, kao dobri programeri smo naučili da ne zagađujemo globalni obim, a pod pretpostavkom rezervisanih imena promenljivih podjednako su loša.

Zašto da module.ekports bude rezervisano u celom jeziku samo zato što ga popularna okruženje dobro koriste? Bilo bi ispravnije, i uljudnije, ako bi smo napravili da nema ograničenja o tome šta imena promenljivih na kraj programer može da koristi, čak i ako su nejasna.

Možemo zaobići sve to ukoliko znamo par stvari, pod pretpostavkom da je vaša skripta učitavana u globalnom okviru (što će se desiti ukoliko je učitana preko skripti). Promenljiva ne može biti rezervisana u spoljnom zatvaranju, jer skripta radi u najspoljnijem zatvaranju dostupnom od strane pretraživača. Takođe, ova napravljena referenca ne može da se menja, jer to je zapravo ključna reč, a ne promenljiva. Sada se setite node-a, i ovaj objekat je referenca praznog objekata, ali modul i exports varijable su uvek na raspolaganju. To je zato što je deklarisana u spoljnom zatvaranju. Dakle, onda je možemo popraviti i naglašavaju da proverimo tako da je promenimo na:

    this.exports !== exports


Uz to, ako neko potvrdi export u svetskom obimu u pretraživaču, ona će biti smeštena u this.exports objektu. To će izazvati da test ne uspe, jer this.exports će biti isti objekat kao i exports.U node-u, this.exports ne postoji, a izvoz postoji u spoljnom zatvaranju, tako da će test uspeti. Možemo proveriti izvoz promenljivu direktno jer se više ne oslanjamo na nejasnoće i promenljive strukture.

Dakle, finalni test je:

    typeof exports !== 'undefined' && this.exports !== exports


Iako to sada omogućava da export promenljive može slobodno da se koristi u globalnom okviru, ipak je moguće zaobići ovo na pretraživaču stvaranjem nove zatvorene i deklarisane exports u okviru toga, onda učitava skripta u okviru tog zatvaranja. U tom trenutku korisnik u potpunosti replicira node okruženje, i nadamo se zna šta radi, time što pokušava da uradi zahtev za node stil. Ako je kod označen u skripti, on će i dalje biti siguran od bilo kog zatvaranja koji su možda napravljena na nekom drugom mestu, i sve je urađeno u posebnom zatvaranju koje je izolovano od ostatka koda.

tmetler@gmail.com





Published (Last edited): 25-02-2013 , source: http://timetler.com/2012/10/13/environment-detection-in-javascript/