Goran Rakić

Nezainteresovani korisnici

Thu, 07 Aug 2003 01:51:56 +0200

Između ostalog što radim je i moderisanje PHP foruma na Elitesecurity-ju. Uglavnom mi ne pada teško ali ima jedna stvar koja me žestoko iritira. Dođe novi korisnik mika na ES, registruje se, ode na php forum i postavi pitanje: “Treba mi skripta za autentifikaciju korisnika iz tekstualne datoteke” ili već nešto slično. Izgleda da onaj FAQ Kako pitati pitanja na pametni način treba postaviti na svaku drugu stranicu.

Pitam se šta takav profil korisnika očekuju? Da ja krenem da pišem njihovu skriptu koja autentifikuje korisnika iz txt datoteke po već utvrđenom formatu? Još kada bih uradio i HTML dizajn za to, bilo bi super. A on, zahvaliće se uredno.

U takvim slučajevima uglavnom odgovorim sa već dobro poznatom frazom “pročitaj php manual”, što je već i meni samom dosadno.

Ja lično volim da pomognem mnogima kada vidim da se sami trude da reše problem. Na primer, da je pitanje bilo postavljeno “Napisao sam to i to, ali neće jer izgleda da po grešci koju stavlja nemam dobar fajl deskriptor…” ili slično. Ali ne, najbolje bi bilo kada ne bi morali ni da otvore php manual. Onolika velika arhiva, to da skidaju… uh?

Jedino što mi je interesantno što uvek naleću u rojevima. Uvek se pojavi 5 pitanja takvog profila, pa onda sledi pauza od nedelju dana, pa opet… Da li jedan drugog ohrabruju ili je uticaj Meseca u pitanju?

Trenutno mrzim php

Mon, 25 Aug 2003 13:39:00 +0200

Iako ima brojne prednosti, kada dođe do većih zahteva php prikazuje svoje slabosti. Da ja shvatam da je najveća popularnost zbog postojanja jako velikog broja ugrađenih funkcija za sve i svašta, zbog opšte prisutnosti na 99% svih hosting paketa, znam da ima jako mnogo programera koji u njemu šljakaju, ali se meni jezik sve manje dopada.

Kada počnete da radite u php-u, prvo što primetite jeste da vrlo brzo moćete da napravite nešto korisno, nema deklaracije, definicije, pravila su vrlo slobodna, php radi automatske konverzije i sve ostalo, ma idealno. Ali…

Onda na red dolaze krupnije stvari, i shvatite da vaš kod liči na špagete (hvala Predragu Damjanoviću na poređenju) i ma kako vi poštovali vaš coding style dolazite u situaciju da više ne možete da pratite organizaciju projekta. Ok, idemo na OOP, sredićemo funkcije u klase, kontrolisaćemo ko šta poziva i ko šta mož?e da poziva. Ali đavola, sve do najnovijeg php5 (koji se dugo vremena neće naći na nivou popularnosti php4), trenutno neupotrebljivog za bilo kakv ozbiljan rad, OOP u php-u je, pa prava reč je smešan. Kakav je to OOP kada ne postoje privatni i javni deo klase, kada ne postoje pokazivači i reference? Dobro, hajde za ovaj prvi deo, recimo da pišemo kod tako da sigurno nećemo dopustiti sebi da odemo van interfejsa klase, već pazimo na private/public metode i vrednosti. Ali kako rešiti drugi problem? Recimo da imamo DB klasu. Ta klasa je potrebna iz Auth klase kako bi ista pročitala privilegije korisnika, a potrebna je i iz neke Navigation klase jer će ona učitavati odgovarajući kod zavisno od tražene stranice (Koji će verovatno koristiti metode DB klase). Nikakav problem, na prvi pogled. Imamo instancu DB klase, poš?aljemo je po referenci u Auth i u Navigation klasu i šta se onda desi? PHP-ev idiotski način prosleđivanja objekta po referenci izvršava konstruktor ponovo pri svakom prosleđivanju. E sada kako ne bismo upali u filelock (pošto naša DB klasa, jelte koristi tekstualne datoteke), mi iz konstruktora DB klase izdvajamo deo koda van klase, zatim iz metoda koji postavljaju upit, izdvajamo delove koji moraju da se prenose izmedju 2 instance DB klase kao globalne varijable koje čitamo i pišemo pomoću funkcija ne-članica klase. I šta na kraju dobijamo, pa opet špagete. Umesto da dobijemo black-box objekat DB, mi imamo klasu DB koja rasipa svoj kod na barem još tri mesta. Hajde dosta o objektima.

Kako stvari stoje sa kontrolom programa? Pa dovoljno je pomenuti da je php typesafe i sve je jasno koliko kontrole može da se implementira. One glupave is_* funkcije su nepredvidive, tj treba uvek prvo njih proveriti kako se ponašaju, a tek onda proveravati program.

Sledeće, mrežno programiranje… PHP je skript jezik koji se najčešće koristi za izradu raznoraznih dinamičkih sajtova zar ne? Pa onda bi valjda trebao da ima dobro implementiran socket interfejs, da omogući kvalitetno mrežno programiranje. Ali… Recimo da trebamo da pošaljemo udaljenoj skripti neke podatke, zar nije logično da postoji način da ta udaljena skripta pročita sve podatke koje smo joj poslali? Funkcija fread() to radi međutim tek od php-a verzije 4.3.0 i novije. Za starije verzije php interpretatora ili moramo ubaciti kontrolnu sekvencu koja imitira EOF (iako select() funkcija u BSD sockets interfejsu itekako može da očita EOF u poslatoj komunikaciji sa servera - “man select”) ili postaviti da fread() pročita nekih 10MB podataka, a pošto će web server prekinuti komunikaciju čim pošalje podatke (manje od 10MB) php neće čitati doveka (jer gubi deskriptor socket-a koji se gasi po prekidu konekcije).

Može ovde sigurno još mnogo toga da se nabraja, ali nakon dužeg rada sa php-om verujem da svi shvate idiotizam php-gtk projekta. Pored toliko kvalitetnih jezika poput C++-a ( ;) ), praviti php sa klijentskim GUI-jem je čista perverzija. Nekada sam se bunio kada neko sa podsmehom pomene php. Sada, pa hm, ćutim. Nadam se da će kada php uđe u stable, mnogi hosting provajderi prihvatiti novu verziju, mada bez otkrivanja nekog velikog sigurnosnog propusta u php4, do toga teško mož doći, prvenstveno zbog kompatibilnosti loše napisanog php4 koda, koji iz ko zna kog razloga upravo koristi one gore felerične reference.

php_network_getaddresses: getaddrinfo failed

Sun, 31 Aug 2003 01:02:15 +0200

Zašto menjati stvari koje rade? U php-u je lepo postojala “ipv4 only” gethostbyname funkcija, ali ne gospoda žele da budu u trendu i da podržavaju ipv6 i onda naprave internu funkciju getaddrinfo. Naravno nju koriste prvo u FTP funkcijama, onda i za mail() funkciju pa na kraju i za fsocket funkcije. Na kraju i staru gethostbyname implementaciju zamene sa novom. Pa šta, nije problem kome bi smetalo što podržavamo i ipv6…

Trebalo bi nikom, ali to baš nije tako, jer… Jer nova implementacija ne operiše dinamički sa listom dns servera, i što je još gore interno kešira dns upite (zašto kada je po celoj Unix filozofiji namenjeno da mali alati rade usko ograničeni deo posla, pa zar keširanje nije u domenu dns servera?). I sada imate neke varijacije DynDNS hostova sa kojima morate da ostvarite vezu, jednostavno nakon promene IP adrese DNS-a php odbija da radi i daje grešku iz naslova.

Drugo, sama promena /ec/resolv.conf datoteke uopšte ne utiče na php, jer po novoj implementaciji kada se voljeni ISAPI modul učita u Apache, php pročita datoteku i u “cilju smanjenja korišćenja resursa” to više ne radi dok god vi ne restartujete Apache.

Naravno ovo ne možete nikako saznati čitajući php dokumentaciju, pa jedini spas dolazi sa Google-a. Očigledno tražim previše od “konektuj se na bazu, pomnoži vrednosti i prikaži ih” jezika.

php programeri, mislite da znate php?

Sun, 19 Oct 2003 16:41:49 +0200

Mislili ste da samo Perl ima nezgodnu sintaksu? Pročitali ste php manual bezbroj puta i mislite da znate sve? E pa onda uradite test BlueShoes PHP Syntax Exam. Ja sam radio do pola, i uglavnom je bilo, pa hm.. ok, ako ignorišemo potrebno vreme da uradim samo 1/2 testa. Mada je rezultat bio poprilično fin (bilo je više zelenih, nego crvenih ;) ).

Hajde probajte, pa javite rezultate u komentarima. Samo nemojte da kliknete na link ispod ovoga u navigaciji na BlueShoes sajtu.

("i18n" && "l10n") WITH "php"

Thu, 23 Oct 2003 16:12:22 +0200

Pri izradi internet aplikacija pomoću jednog od najpopularnijeg za to namenjenog jezika - PHPa^[1], često se susrećemo sa problemom lokalizacije same aplikacije. Najčešće korišćeno rešenje, ujedno i najjednostavnije za realizaciju jeste korišćenje tako odomaćenih „lang datoteka“. Naime, u jednoj php datoteci definišemo niz elemenata (bilo imenovani ili ne) sa stringovima koje treba lokalizovati i onda umesto pisanja samog stringa u php kodu, koristimo indeks datog niza. Mana ovog pristupa jeste nepodržavanje za oblike množine (svaki moramo posebno definisati novim indeksom niza), nečitljivost koda, laka greška u zapisu samog niza…

Drugi korak u lokalizaciji može biti pravljenje posebnih šablona za svaki jezik (pomoću Smarty sistema šablona ili ekvivalenta) gde bismo definisali sve jezički zavisne celine u samom šablonu. Međutim, prevođenje je dosta kompleksno jer ma koliko to mi želeli sami stringovi se mešaju sa jezikom za označavanje ili sa programskim delom šablona koji definiše oblike množine i slično.

Ukoliko ste se ikada susreli sa GNU gettext bibliotekom svakako ste primetili prednosti korišćenja iste. Laka ekstrakcija stringova iz php datoteka, očuvanje čitljivosti koda (u kodu ostaje string, uokviren _() funkcijom, a ne nekakav indeks nekog niza), stringovi za prevod su potpuno ekstraktovani a za samo prevođenje postoje razni alati. Sama gettext biblioteka podržava oblike množine, ukoliko neki string nije preveden ostaće u originalu, podržava dodavanja dinamičkih vrednosti unutar stringa (poput printf funkcije) i slično. Kako sam negde pročitao, ko jednom krene da radi sa gettext-om, uvek radi sa gettext-om.

PHP poseduje podršku za gettext, ukoliko je kompajliran sa parametrom –with-gettext, što najčešće nije slučaj. Proverite phpinfo(), možda imate sreće. Ukoliko pak nemate sreće, možete prekompajlirati gettext za ciljni sistem i instalirati ga u CGI direktorijum, zatim učitati php modul preko funkcija za dinamičko učitavanje ili prekompajlirati ceo php i .htaccess-om podesiti izvršavanje. E sada, ni ovo najčešće zbog sigurnosnih podešavanja neće raditi. Zato je potrebno naći neku alternativu za gettext, koja ima mogućnosti gettext-a.

Danilo Šegan je danas objavio PHP-Gettext biblioteku (i sam kaže da inventivniji u imenu nije mogao biti ;) ), koja podržava standardne GNU Gettext MO datoteke, koje se generišu iz PO datoteka. U samom paketu postoje i primeri koda, i README pa neću prenositi. Ono što može da zasmeta jeste brzina izvršavanja, ali za manje projekte to nije opasno.

[1] PHP pročitano u ćirliličnom pismu (velikim slovima) označava skraćenicu od Radi-Ne-Radi. (Danilo Šegan)

PHP Magazine u PDF formatu

Mon, 08 Dec 2003 17:57:46 +0100

Proslavljeni nemački časopis posevećen PHP-u - PHP Magazine već neko vreme ima internacionalno izdanje. Ono što je interesantno je da će se od 15. decembra u njihovoj ponudi pored štampanog naći i elektronsko izdanje u PDF formatu. Takođe, ono što je jako lepo - prvo PDF izdanje će biti apsolutno bespaltno dok će kasnija cena mesečnog izdanja biti 5$ što uopšte nije strašno. (I znatno je manje od varijante papirnog izdanja sa uračunatim troškovima slanja i verovatnoćom da se “zagubi”).

Kako će se ovaj potez odraziti na konkurentski časopis php

arch</a> koji je nastao kao primarno elektronski PDF časopis. Možda je ovo i reakcija na nedavni upad php

arch-a na štampano tržište, ili verovatnije čist ekonomski potez PHP Magazine-a.

Link na saopštenje PHP Magazine-a.

Iscedite brzinu iz PHP-a i još po neki tekst

Wed, 30 Jun 2004 23:24:45 +0200

Danas sam naleteo na fini tekstić (Squeezing code with xdebug) o optimizaciji PHP koda. Prikazano je nekoliko interesantnih nazovimo ih “caka” kao i preporuka za upotrebu xdebug alata u profilisanju koda.

Na primer, nisam proveravao ali mi ovo deluje jako interesantno:

ob_start(); for ($i=0; $i < 10000; $i++) echo $i; $s = ob_get_contents(); ob_end_flush();

Takođe, izdvojio bih i zapažanje o brzini različitih funkcija na osnovu mesta njihove implementacije (u ZendEngine-u ili kasnije kroz ekstenziju). Za nove programere bitno je istaći i usporenje pri pozivu funkcije i koda koji je direktno napisan, usporenje pri pozivu funkcije sa nizom koji je prosleđen po referenci kao parametrom i funkcijom koja prima 10 različitih parametara itd.

Neki bi rekli da PHP ne vredi takvih optimizacija jer se narušava čitljivost koda, a to inače nije jezik za projekte i okruženja gde ovakve optimizacije mogu značiti… Neću se izjasniti po tom pitanju, a ovakve “tekstiće” nije na odmet pročitati povremeno.

Od interesante PHP literature izdvojio bih post na SitePoint-ovom PHP Blog-u: PHP Gotchas, part I. Ima dobrih stvari za zapamtiti, naročito oko magic_quote-a. Eh, da sam ovo čitao pre godinu dana ;).

Tu su i prezentacije sa Linuxtag-a: 1) Rasmus Lerdorf: Debugging PHP with Xdebug 2) Rasmus Lerdorf: Large scale PHP 3) (Obojena i ušarenjena) Tobias Schlitt i Stefan Neufeind: Pear an introduction

A na kraju ću preskočiti prenošenje vesti o tome da je Friendster prešao na PHP i napravio veliko ubrzanje u radu sistema jer ne mislim da je to zasluga PHP-a već onoga ko je pisao novi PHP kod, odnosno onoga ko je pisao stari tomcat/jsp kod ;)

"Svetski, a naše" i sigurnost

Wed, 07 Jul 2004 20:13:21 +0200

Bila na brdovitom Balkanu jedna manje-više poznata, da je tako nazovemo, aktivna web development agencija. Radiše vredno i marljivo - prosto rapidno! I igrom slučaja dođoh ja do jednog njihovog projekta, da pogledam malo. Kliknu ovde kliknu onde, a sigurnosne rupe iskaču ne znaš koja veća od koje…

Ništa, kažem ja pa dobro dešava se - igrala se deca, pa zaboravila ponešto. Obavestim ja njih telefonom, i posle nekoliko dana stigne odgovor “Sigurnost je u redu, lozinke su kriptovane”. Ko vidi samo odgovor, kaže u redu, ali u pitanju su se pominjale opasne stvari, one koje se pišu na vratima špajze kao upozorenje za malu decu. Prosto ne znaš koja je opasnija - izostavljanje basename()-a pre fopen() i readfile() funkcija, a ime datoteke HTTP GET parametar, iskljucen registar_globals, a prijava ne podesava kontrolnu varijablu na NULL ili FALSE pre toga, problemi sa magic_quotes itd.

Bilo je tu i neobičnih, prosto smešnih stvari:

3) NEOBICNI PROBLEM PRI PRIJAVI KORISNIKA Kratkim uvidom, primetio sam drugacije ponasanje prijave ako se prijava pokusava pre 17h. Naime, za sada izgleda da prijava pre 17h uvek prolazi, svejedno od rezultata poziva login() metode klase admin, ako postoji vise od 3 neuspela pokusaja. Cudnim kodom u metodi kojim se umesto prebrojavaja neuspelih pokusaja u toku dana proverava broj neuspelih pokusaja sa IP adrese sa koje se sada pokusava prijava na dan 26. aprila 2004. godine ovu gresku nije moguce iskoristiti, ali svakako brojanje pogresnih pokusaja treba ispraviti (izbaciti ili komentarisati red "$date='2004-04-26';" u classes/admin.php), a iskljuciti mogucnost prijave bez lozinke pre 17h.

Ne znam ja, živim u zemlji koja je uglavnom izolovana od sveta, možda se tamo po Italiji gde dotična aktivna agencija voli da radi ovakve stvari ne gledaju. Ono, korisnici su pošteni svet neće oni da menjaju adresu i da skinu ceo PHP izvorni kod kroz tamo neki sigurnosni “šta ti ja znam” propust… Ne znam, sve je moguće. Možda…

A možda sam ja sve ovo sanjao, ličilo bi. Ipak ovaj par stranica dugačak mail sa odgovorom je u mom Drafts folderu, nešto neće da nestane ma koliko se ja ubadao viljuškom.

Bacati Exception ili otkidati Error?

Mon, 12 Jul 2004 19:59:24 +0200

Znam da se ovo tiče coding style-a, ali me zanima šta ostali učesnici foruma misle. Kao što verovatno većina vas zna, u PHP5 je (će biti) prisutan interfejs za izuzetke (exceptions).

Ono što mene sada zanima jeste kada je poželjno koristiti ih? Njihovo izvršavanje je nešto malo sporije od klasičnih promena toka programa pomoću if/else i sličnih jezičkih konstrukcija. Takođe, moguće je čak i u PHP-u napravti memory leak preko istih.

Sam izuzetak u PHP-u predstavlja objekat tako da može imati sve i svja od dodatnih informacija kao što su delovi backtrace-a.

Moje je mišljenje da izuzecima treba kontrolisati greške koje nastaju usled obrade korisničkih parametara ili trenutnih grešaka u pristupu resursima, dok greške u kodu treba obrađivati kroz standardni trigger_error/error handler mehanizam. Pod greškama u kodu ne mislim samo na greške u kodu sistema jer toga ne bi trebalo biti već i na greške u čitanju i izvršavanju pojedinih modula, pristupu šablonima koji se pozivaju iz programa/modula i slično...

Takođe zanimali bi me i predlozi mojih cenjenih čitalaca ;) o mogućnostima implementacije exceptions mehanizma u PHP4. Trebalo bi napraviti globalno drvo koje bi čuvalo podatke o izuzecima i prostor za jedan serijalizovani niz u kome bi se mogli sačuvati dodatni podaci ukoliko postoji potreba za tim. Dalje, potrebna je funkcija trow_exception koja bi postavljala status izuzetka na 1, kao i svih čvorova drveta od njega do vrha. Funkcija catch_exception bi proveravala da li je status 1, i ako jeste postavljala status od tog čvora naniže na 0 i vraćala TRUE, odnosno FALSE ako status nije 1. If konstrukcija oko catch_exception poziva bi imitirala try/catch konstrukciju u petici.

I šta je onda problem? Pa problem je to što se onda ceo kod mora pisati odvojeno za verzije 4/5. Ovo nije nikakav problem za sistemske klase jer se one dosta menjaju inače (naročito one za rad sa modulima/objektima). Problem je šta u samim modulima gde bi se po mom viđenju izuzetaka oni mnogo više i koristili jer će većina grešaka u sistemskim klasama biti obrađena kroz klasičan error handler. Ono što bi bilo zgodno jeste pisanje nekog omotača za izuzetke koji u petici koristi njene jezičke kontrukcije, dok u četvorci koristi predloženu implementaciju. To je sa nekoliko eval-a koji su samo jedno slovo daleko od evil moguće za registrovanje izuzetaka i za bacanje istih, ali ja ne vidim način da to primenim na try/catch konstrukciju, tj. morao bi ceo try blok da bude pod eval-om, što je poprilično glupo jer komplikuje klasičan error handler dodavajući dodatne elemente u backtrace i verovatno (nisam testirao) dosta usporava rad. Rešenje koje mi sada pada na pamet bi ličilo na:

...
if(($sfw_phpversion & SFW_PHP4)) {

  /* catch exception in PHP4 style via catch_exception function call */
  $this->add_code($code);
  if( catch_exception('ExcAddCompCode') ) {
	...
	...
  } 	
   	   	 
}
else {

  /* catch exception in PHP5 style */
  try {
	$this->add_code($code);
  }
  catch(ExcAddCompCode $e) {
	...
	...
  }	

}

Ovo dodaje jako puno koda na inače nevoljno pisanu kontrolu grešaka i mora da postoji neko rešenje. Jedno je trivijalno, ne obrađivati PHP5 deo već zarad backward kompatibilnosti raditi samo na prvi način. Ono što se žrtvuje tako jesu neke napredne mogućnosti grupisanja/ponovnog bacanja/šta ti ja znam izuzetaka, a što bi ako bi se primenila gornja implementacija moglo uraditi u onom PHP5 specific delu koda. A možda treba potpuno zaboraviti na sve ovo i koristiti

Odakle inače sada ovo? Radim sada na svom PHP framework-u (konverzija na PHP5, promena rada sa modulima/objektima, podrška za distribuirane objekte itd) i eto, priča o kontrolisanju grešaka je izbila ovih dana u prvi plan. Željno očekujem predloge onih koji se igraju duže vreme sa peticom od mene ili su izuzetke susretali u drugim jezicima...

Zend Studio, iskorišćen popust za studente

Sat, 22 Jan 2005 17:04:57 +0100

Danas sam, uz odobreni popust za studente kupio Zend Studio u aktuelnoj verziji 3.5 sa pravom na besplatnu nadogradnju na verziju 4.0 kada ista izađe iz beta programa. Zend Studio sam i ranije koristio u par navrata (Beta, Trial i slično) i utvrdio da se radi o jako kvalitetnom alatu koji značajno ubrzava rad, ali sam ipak kod evo do sada pisao koristeći raznorazne editore poput vi editora pa čak i Apple XCode razvojnog okruženja.

Ipak kada sam video da Zend Studio mogu dobiti po ceni od 95$ (imajući u vidu da program inače košta 259$, ali i trenutni kurs dolara) morao sam isti kupiti. Radi se o popustu, dakle verzija je ista kao i Zend Studio Plus - jedino što treba jeste javiti se prodaji Zend-a. Mene nisu tražili nikakve potvrde i cela procedura bi bila poprilično brza da nije naših banaka, konkretno moje “The Bank of Vojvodina” tako da sam iako još juče pre podne uplatio novac na devizni račun tek danas mogao isti da potrošim. Samo me zanima kakav im je to informacioni sistem koji ima delay više od jednog dana za one-click transakciju sa jednog na drugi račun unutar banke.