Pentru ca sunt oarece probleme cu RSS-ul de pe geekmeet.ro, nu foarte multa lume a aflat de eveniment. Asa ca rog cei 10 cititori unici ai acestui blog sa raspandeasca vestea printr-un tweet/blogpost/whatever. Mersi!

La PHP GeekMeet #7 vor vorbi:

• Alina Fleșer – despre Typo3
• Bogdan Pușcaș – despre HTTP 1.1
• Andrei Popescu – despre PHP & Web security
• Varga Levente – despre Kohana & Code Igniter

Condiții de participare:

• Taxa propriuzisă pentru participare nu este, dar trebuie făcută o consumație minimă de 10 lei / pers
• Participarea se face exclusiv pe bază de preînscriere! Dacă ştii sigur (măcar 90%) că vii, completează formularul de mai jos:

Vor vorbi:

• Mihai Balaceanu despre Webservices
• Dordea Cosmin despre Testarea performanțelor & profiling
• Gabriel Ungureanu despre Drupal (chestii avansate)

Pentru înscrieri, vedeți anunțul oficial.

Meet me there!

Anunțul oficial și detaliile despre înscriere le găsiți aici.

Prezintă:

• Gabriel Ungureanu – Drupal:Basics
• Varga Levente – To template or not to template
• Mihai Brehar – Mysql: stii sa faci un backup cum trebuie?

Am văzut mai demult o prezentare a lui Varga Levente despre Javascript și pot să spun că a fost foarte faină. Sunt convins că și prezentarea despre templates va fi la nivel înalt. Pe Gabriel Ungureanu nu-l știu de multă vreme, dar cred că o sa facă treabă bună cu prezentarea Drupal. La final, chiar dacă nu e despre PHP, subsemnatul o să țină o prezentare scurtă despre cum să faci un backup corect la baza de date(Mysql).

Ce mai aștepți? Înscrie-te!

Problema consta în faptul că orice script php rulat din consolă se bloca înainte să se termine execuția. Era nevoie de un ctrl+c pentru a reveni la consolă. Chiar și un banal php5 -v se bloca.

Nu mă doare mâna să dau câte un ctrl+c, însă ce faci când scriptul rulează într-un cron? M-am trezit cu câteva sute de procese astfel agățate.

Buuun… rulând un strace, aveam următorul output:

…așadar, nici o informație ajutătoare.

În lipsă de alte idei, am început să dezactivez modulele php instalate. Surpriză, php5-mysql se bate cap în cap cu php5-mysqli. Și asta se întâmplă doar pentru cli, serverul web merge bine mersi cu ambele module active. Pe alte servere, cu alte versiuni php5 totul e ok.

În concluzie, folosiți ori mysqli ori mysql.

Bonus, un one-liner cu care am omorât procesele agățate din cron:

Pentru mai multe detalii și înscrieri, click aici.

Pentru mine Smarty a însemnat o adevărată revelație prin anii 2003-2004, marcând un punct de cotitură asupra felului cum scriu cod PHP. Până atunci, codul meu era un mix interminabil de HTML și PHP. Însă când am descoperit Smarty, am început să înțeleg și să aplic cu adevărat ceea ce tot repetau profesorii prin facultate: separarea Business Logic de Presentation Logic.

Aș putea spune că sunt atașat emoțional de Smarty. Când am văzut primul articol în RSS reader am zis că e doar un caz izolat, un tip căruia i s-a pus pata pe Smarty. Însă când am văzut articolele următoare într-un interval scurt de timp, au început să mi se aprindă beculețele de alarmă. O fi Smarty chiar așa de rău?

Am citit toate (contra)argumentele de pe nosmarty.net și pot să spun că nu sunt bazate pe argumente solide. Nu stau să detaliez pentru că nu am nici timp și nici chef.

If you guys don’t agree with me, you can spend hell lot of time learning that {$name} actually does what you could do with “echo $name”.

Nu înțeleg cum autorul unei cărți despre Smarty poate să spună așa ceva. Din câte îmi amintesc, nu mi-a luat mai mult de juma de oră să învăț Smarty (cu tot cu instalare).

Ok, Smarty nu e perfect, însă hai să nu-l denigrăm în halul ăsta!

Smarty m-a slujit exemplar în multe proiecte și n-am fost nevoit să caut alternative. Totuși, publicitatea asta negativă mă face să scot capul din nisip și să mă uit la alte siteme de templates. Încă n-am încă găsit timpul necesar, dar ar fi o prezentare interesantă pentru PHP GeekMeet.

Programmers are so busy working they often don’t have time to be curious about how they could do their jobs better. (Steve McConnel)

De ceva vreme încoace, rumeg o idee împreună cu Adi: să facem un GeekMeet special despre PHP. Încerc să adun o masă critică pentru a porni întâlnirile în Cluj, iar la GeetMeet #4 Cluj am primit un feedback pozitiv de la mai multe persoane.

Pe scurt, ideea se regăsește în citatul de mai sus. Personal, urmăresc RSS-urile de pe vreo două site-uri (legate de PHP, evident) și sunt abonat la php|arch. Dar cantitatea de informații e mult prea mare, RSS-urile rămân necitite și foarte rar încerc să experimentez chestiile pe care le citesc.

Cu toții suntem ocupați cu lucrul și avem prea puțin timp la dispoziție pentru a fi la curent cu ultimele noutăți din industrie, pentru a experimenta chestii noi. Însă sunt convins că fiecare din noi (și aici mă refer la programatori în general) încercăm să ținem pasul cu tehnologia. De aceea un PHP GeekMeet cred că ar fi binevenit, am putea să facem schimb de experiență și idei într-un mod foarte productiv.

Pe site-ul php.net văd o grămadă de întâlniri ale diverselor PHP User Groups din toate colțurile lumii. Noi de ce nu putem face așa ceva? Hai să ne întâlnim, să ținem prezentări practice, la obiect, să beneficiem fiecare de experiența celorlalți, să le evităm greșelile și să devenim mai eficienți.

Așadar, lasă un comentariu dacă ești interesat.

Actualizare: am mutat discuțiile aici.

Ultima problemă legată de IE6 ține de afișarea incorectă a diacriticelor cu virgulă. Problema asta îmi era practic necunoscută acum vreo 6 luni de zile, deoarece layout-urile tastaturilor românești conțineau diactitice cu sedilă (pe linux, cel puțin). Diferența?

Layout nou: ș, Ș, ț, Ț (afișat incorect)

Layout vechi: ş, Ş, ţ, Ţ (afișat corect)

Aici pe blog puțin îmi pasă dacă mai sunt oameni navigând cu IE6 care nu văd textul corect. Însă pe alte site-uri îmi pasă, pentru că fiecare utilizator poate deveni client. Prin urmare, a trebuit să caut o soluție.

Fiind vorba de un site scris în PHP, soluția a ieșit imediat la iveală și se bazează pe funcționalitatea de output buffering despre care am mai scris aici.

Și acum, codul responsabil cu afișarea diacriticilor cu sedilă în locul celor cu virgulă (doar pentru IE6):

function inlocuireDiacritice($buffer){

  $cuVirgula = array("ș", "Ș", "ț", "Ț");

  $cuSedila = array("ş", "Ş", "ţ", "Ţ");

  return str_replace($cuVirgula, $cuSedila, $buffer);

}

function browserIE6(){

  return strpos($_SERVER["HTTP_USER_AGENT"], "MSIE 6");

}

if (browserIE6()){

  ob_start("inlocuireDiacritice");

}else{

  ob_start();

}
...
ob_end_flush();

Dacă ai răspuns nu la toate întrebările atunci merită să citeşti acest articol. Nu e nici un secret că mulţi programatori dau atenţie securităţii abia în ultima parte a proiectului, atunci când nu există prea mult timp pentru aşa ceva.

În continuare vreau să ofer o soluţie elegantă pentru filtrarea datelor venite de la utilizator, şi anume, separarea codului ce ţine de securitate, de restul aplicaţiei. Astfel, soluţia poate fi adoptată cu aceeaşi uşurinţă atât pentru proiectele noi, cât şi pentru cele deja existente. Articolul este scris relativ la PHP, dar cred că aceleaşi principii sunt valabile şi pentru ASP, JSP şi alte limbaje.

Am să încep cu nişte exemple. Nu de puţine ori am văzut cod de genul

sau

sau

Acest mod de a asigura securitatea este foarte greoi şi îţi oferă numeroase „şanse” să greşeşti. Pentru mulţi programatori e un chin.

Ce bine ar fi să poţi scrie liniştit

Ei bine, se poate, fară a face rabat pe partea de securitate!

Ideea de bază constă în verificarea tuturor variabilelor din GET, POST şi COOKIE înainte de a ajunge (de a fi folosite) în aplicaţia propriu-zisă. Cel mai simplu* mod pentru a face asta, este de a scrie o funcţie pentru fiecare variabilă ce trebuie verificată.

//pentru exemplul de mai sus in care avem $_POST["user"], functia de verificare
//ar putea arata in felul urmator:

function check_POST_user($value){
  if (!eregi("^[a-z0-9]$", $value){
    die('user: valoare nepermisa');
  }
}

//aici vin scrise functii pentru restul variabilelor

//apelarea functiilor pentru fiecare variabila se face astfel:
foreach ($_POST as $var => $value){
  $function_name = "check_POST_" . $var;
  if (!function_exists($function_name)){
    die("scrie functie pentru a verifica _POST[$var]");
  }
  $function_name($value);
}

Pentru simplitate, am dat un exemplu minimal de programare procedurală, dar ideea se poate extinde foarte frumos folosind clase şi obiecte.

Folosesc această metodă de vreo 4 ani şi pot să spun că mi-a adus multe beneficii şi m-a eliberat de o grămadă de stres. În încheiere, vreau să subliniez câteva avantaje ale acestei metode:

• codului aplicaţiei devine mai simplu
• ai o privire de ansamblu: tot ce ţine de securitate se găseşte într-un loc bine stabilit
• poţi să ştii în orice clipă care variabile sunt verificate şi care nu
• se pretează bine la lucrul în echipă; poţi să pui un specialist să scrie funcţiile de verificare

Programare plăcută!

* Voi prezenta o modalitate şi mai simplă într-un articol viitor

Pe scurt, vreau să inversez toate link-urile de pe un „site”, având acces la codul sursă, bineînteles. Adică un link se transformă în knil nu. Restul textului de pe site rămâne neschimbat iar URL-urile funcţionează în continuare. Am pus site între ghilimele deoarece nu e vorba de un site cu mii de useri online ci e vorba de un backend la care au acces 5-6 persoane.

Soluţia tehnică se bazează pe funcţionalitatea de output buffering pe care o oferă PHP-ul. Funcţia de mai jos este un callback pentru ob_start();

function link_reverse($buffer){
  if (preg_match_all("|<a.*>(.*)</a>|U", $buffer, $regs, PREG_PATTERN_ORDER)){
    for ($i = 0; $i < count($regs[1]); $i++){
      $text = $regs[1][$i];
      if (!eregi("^[a-z0-9\.\ \-]*$", $text)){
        //nu avem doar un simplu text in interiorul ancorei, ignoram
        continue;
      }
      $reverse = "";
      for($j = strlen($text) - 1; $j >= 0; $j--){
        $reverse .= $text[$j];
      }
      $buffer = str_replace(">" . $text . "<", ">" . $reverse . "<", $buffer);
    }
  }
  return $buffer;
}

Aveţi grijă mâine. Noapte bună!