Naime, u projektu na kojem sada radim postoji par klasa koje implementiraju singleton pattern. Kao što verovatno znate, tada se umesto konstruktora klase za dobijanje objekta poziva jedan static metod klase.

Zavisno od nekih parametara, u kod hoću da uvedem jednu od dve različite implementacije klase koje se samo neznatno razlikuju. Logično, napraviću jednu abstract klasu i iz nje izvesti dve različite klase koje imaju potrebne razlike u odnosu na baznu klasu.

Pošto sada imam dve različite klase koje implementiraju singleton pattern to znači da je i sintaksa njihove konstrukcije različita. Ja hoću da na početku koda očitam parametre poziva, odlučim se za jednu od dve varijante i onda da ih onda koristim na jedinstven način. Razmišljam dalje i pomislim da zavisno od parametara mogu da učitam datoteku sa tačno jednom implementacijom tako da uvek pri izvršavanju imam u kod uključenu baznu klasu i samo jednu njenu naslednicu. Onda mogu da iskoristim isto ime za obe varijacije (pošto se u kodu pojavljuje uvek samo jedan slučaj pri svakom izvršavanju) i da imam isti pristup nevezan od varijacije koju sam učitao.

Međutim, tu dolazi problem sa phpDocumentor-om. Svaka klasa ima drugu @subpackage oznaku, čak sam probao da uvedem i @name oznaku sa različitim vrednostima ali to ne vredi. On uvek prijavi:

WARNING:
duplicate class element "db" in file appserver/_core/db_normal.class.php will be ignored.
Use an @ignore tag on the original if you want this case to be documented.

Ja sada mogu da ga poslušam i prvo generišem dokumentaciju, onda postavim @ignore nad prvom klasom, i zatim ponovo generišem dokumentaciju. Pošto su klase u različitim podpaketima njihova dokumentacija se nalazi u različitim direktorijumima tako da neće doći do prepisivanja, a meni ostaje da na kraju ručno izmenim listu svih klasa i dodam link ka prvoj klasi. Očigledno, ovo nije elegantno rešenje, a još gore je problem rešiti pri egzotičnijim opcijama izvoza dokumentacije.

Ukoliko se ne setim nekog dobrog razloga zašto phpDocumentor treba da ignoriše klase istog imena koje se nalaze u različitim paketima, sutra ću poslati Bug Report. Naravno, ako je neko naleteo na sličan problem neka slobodno kaže rešenje pošto je sigurno bolje od ovoga što sada radim.

Ali kao što rekoh, pritisnuti sve većom prijavom problema u popularnim sistemima, PHP ekipa je morala da se zaštiti i da jasno stavi do znanja da problem nije do PHP-a nego do samog koda koji je u njemu napisan (kao što greške u Linux-u nisu problem C-a, već...). U skladu sa tim sada već postoji gomila literature, tekstova, tutoriala koji ukazuju na najšesže probleme vezane za sigurnost PHP aplikacija. Sledi lista sa komentarima:

Obavezno pogledajte da li Vaš kod ne sadrži 10 najčešćih grešaka objavljenih na ovom spisku. Lista sadrži ponuđena rešenja za otklanjanje Top10 sigurnosnih grešaka u web aplikacijama, a koje su objavili ljudi koji stoje iza OWASP-a.

Dalje, tekstove koje je za Security Corner rubriku php|arch magazina napisao Chris Shiflett, mozete pogledati na njegovom sajtu/blogu. Tu ima raznoraznih stvari - od sigurnosti u shared hosting okruzenju, preko validacije ulaznih podataka, rešenja protiv Cross-Site Scripting napada i slično. Obavezno pogledati. Naravno, i sam blog je super! Stoji da treba pogledati i PDF dokument istog autora sa prošlogodišnjeg ApacheCon-a. Dokument u PDF formatu se nalazi ovde.

Dalje, nedavni problem koji se pojavio sa phpBB-om (da nije i Vaš kod ugrožen?) je problem implementacije stalnog logina preko kolačića - nešto što postoji na skoro svakoj lokaciji koja sadrži nekakav login. Dakle, pravac na čitanje unosa koji je za svoj blog sastavio Charles Miller.

Slajdovi sa PHP izlaganja koja su bila posvećena sigurnosti - naravno na talks.php.net. Manje više opet iste stvari - ali u tome i jeste kvaka. Uvek se pojavljuju manje više iste stvari.

Detaljno o SQL Injection-u. Ovo je nešto čega većina programera koji u kodu napišu "SELECT * FROM users WHERE name='$name'" nisu ni svesni. Pogledajte i prateće resurse na koje je ukazano u tekstu.

Jedna od stvari koje su pokrenute na početku ove godine je i http://phpsec.org ili "PHP Security Consortium". Njihovo delo je fenomenalan i obiman dokument "PHP Security Guide". Valja ga pročitati, ako ne to onda makar proleteti kroz primere.

Naravno na kraju - ono odakle treba i početi: Security sekcija PHP Manual-a.

Za nove informacije prijavite se na phpsec listu koju je pokrenuo Marco Tabini (php|arch, za one koji nisu upoznati) - adresa je http://www.phparch.com/phpsec/. Na listi aktivno učestvuje gomila poznatih ljudi iz PHP zajednice, a pored obaveštenja o pronađenim greškama, na listi se redovno vode i raznorazne diskusije. Obim liste nije veliki, tako da ne iziskuje puno vremena i ima uglavnom dobar signal/noise odnos. (mada se ponekad dogodi flame na neku od tema, pa onda je neophodno malo proširiti filtere u omiljenom programu za prijem pošte)

Pozdrav, i sigurno kodiranje!

Upkros i dalje prisutnim razlikama između različitih browsera (da ne pričam o eventualnoj podršci za starije browsere) ipak mi se čini da je danas ovakve stvari mnogo lakše raditi danas nego ranije. XHTML za označavanje, CSS za ulešavanje i JavaScript uz pomoć koga se dobija korisniji interfejs, lakši za korišćenje. Nisam pristalica šljaštećih, letećih i kakvih sve ne JavaScript animacija ali pristup DOM-u je itekako korisan kada treba povezati malo komplikovanije formulare, rešiti se višestrukih izbora i slično.

Pojam Gmail-a, zaintersovao sam se za još jednu stvarčicu - XMLHTTPRequest, mogućost da bez ponovnog učitavanja cele stranice pošaljete HTTP POST ili GET zahtev i kao odgovor dobijete komad XML-a koje onda parsirate DOM-om ubacite na pravo mesto. Sve je mnogo čistije nego igranje sa gomilom IFRAME-ova što je jedna od alternativa.

Implementaciju XMLHTTPRequest-a je započeo Microsoft u Internet Exploreru kao posebna ActiveX kontrola, a zatim je sa sličnom sintaksom implementiran i kao objekat u Mozilla-inom Gecko engine-u. Problem je - ovo nikako ne radi u Operi. Opera u verziji 7.6 bi trebalo da sadrži implementaciju, ali opet mnogi su naučili na ovaj browser i izostavljanje podrške je nezgodno ako softver nije u nekakvoj beta fazi (poput Gmail-a).

Ipak, na ovoj adresi je moguće pronaći implementaciju namenjenu Operi, sa poprilično velikim restrikcijama, ali opet čistije nego da se radi o IFRAME-ovima. Pomenuti kod Andrew Gregory-ja koristi Java plugin i njene Input/Output funkcije kako bi komunicirao sa web serverom bez osvežavanja same stranice.

Kod sam neznatno modifikovao kako bih dodao podršku za UTF8 kodnu stranicu (iako još uvek postoje problemi sa Apple Safari browserom, koji ima neispravnu implementaciju XMLHTTPRequest-a i bezobzira na postavljenu kodnu stranicu, rezultat prima u ISO-8859-1 rasporedu) i upakovao sve u demo koji se nalazi na adresi: http://www.goranrakic.com/tmp/xmlhttprequest/demo.php. Voleo bih da primim što više različitih bug reporta, kao i ideje kako da rešim problem sa Safarijem na najoptimalniji način.

Kao što i na stranici samog demo-a stoji, najveći problem je što uprkos XMLHTTPRequest-a, ne dobijate ni X od XML-a jer implementacija za Operu ne sadrzi responseXML objekat. Što se mene tiče dok jednoga dana svi korisnici ne pređu na odlični Mozilla Firefox ja sam zadovoljan i sa PlainTextHTTPRequest-om.

Druga korisna opcija jeste integracija phpDocumentator-a u samo okruženje. Iako je postojala i ranije podrška u vidu prikaza opisa funkcije i povratnih vrednosti prilikom aktiviranja Code Completion prozorčeta tek sada je moguće jednim klikom napraviti dokumentaciju, plus celokupna izrada konfiguracione datoteke je pokrivena grafičkim interfejsom.

Ove opcije su lepo dodate na neupadljiv način u interfejs tako da po prvom pokretanju Zend Studio izgleda manje-više kao i do sada (sa po kojim dugmencetom više). Na kraju, čini mi se da je program čak i malo brži nego prethodna verzija, ali ne bih smeo to baš 100% tvrditi.

Potrudiću se da eto uskoro i napišem poneki tekstić o mogućnostima koje XML-RPC pruža programeru kada je potrebno kreirati i povezati jedno distribuirano web rešenje sa offline komponentama. Koji god jezik da koriste, ideja XML-RPC-a jeste da se klijent može jednostavno implementirati u par redova, a pri pisanju server komponente (ili server komponenti) nije mnogo teže. Upotrebom standardizovanih rešenja, programer može obratiti pažnju na sam problem koji je potrebno rešiti, ne gubeći vreme na implementaciju mehanizma komunikacija između komponenti. Plus, ništa ne sprečava treća lica da implementiraju sa sistemom kompatibilne komponente. Jako je lep osećaj kada je umesto detaljnih objašnjenja nekog protokola, opisa struktura koje je potrebno preneti i slično dovoljno nekome poslati link ka XML-RPC serveru koji sam sadrži opise i dokumentaciju za svaku metodu koju implementira. Uz još nekoliko primera, dosadno pisanje dokumentacije se može zaboraviti.

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.

The Command Pattern
The Factory Method
PHP Static Class Variables
PHP5 concepts in PHP4: interface, abstract, final and Singelton - my approach

...
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) {
	...
	...
  }	

}

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.

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 ;)

Iako se još od prve bete na netu mogu pronaći raznorazna uputsva i vodiči za migraciju koda na novu verziju PHP-a. (Na Zend-u postoji sjajna grupa članaka - ovde i ovde ali i ovde) Međutim, sada i zvanično, na logičnom mestu postoji uputstvo za migraciju. Normalno, reč je o PHP dokumentaciji. Treba imati u vidu da PHP5 još nije zamrznut, pa se tako mogu očekivati promene. Na primer, iako u uputstvu trenutno piše drugačije Andi kaže da ukoliko se ne koriste nove mogućnosti objektnog modela, nije neophodno deklarisati klase pre korišćenja. Sada, što je to sasvim normalno uraditi i većina koda to već poštuje to je druga priča.

Po testovima RC4 je u klasičnim operacijama brži od PHP4, baš onako kako je i najavljeno. Sada još da se još malo sve sredi, očisti memory leak na koji se tu i tamo pojavljuju žalbe (naravno, ovo nije stvar koja se rešava u sat vremena, ali tri meseca je pred PHP ekipom) pa da onda PHP5 izađe, i da svi počnemo da koristimo nove mogućnosti.

Kako će se ovaj potez odraziti na konkurentski časopis php|arch 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.

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)

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