In PHP we Trust

OAuth (sau Open Authentication) este un protocol liber prin care se poate permite accesul la resurse aflate pe un alt site fără a dezvălui datele de conectare (nume utilizator și parolă) către site-ul în care se dorește accesul la acele resurse partajate (imagini, video, adrese de email, conturi bancare etc.)

Este practic o ”cheie pentru valet” sau un ”ecuson pentru vizitator” cu care se acordă un acces mai restrâns la resursele personale aflate pe un site, decât dacă le-am accesat direct din acel site. La fel cum o cheie pentru valet (cel care se ocupa de parcarea mașinii) ar permite accesul doar la anumite funcții ale mașinii și pentru o perioadă restrânsă sau cum un ecuson de vizitator nu ar permite accesul la orice încăpere dintr-o clădire.

Înțelegerea protocolului OAuth se bazează pe cunoașterea următorilor termeni:

• Resursele – sunt obiectele private ale unui utilizator la care se dorește accesul selectiv de către alte site-uri sau aplicații
• Furnizorul de Servicii – este cel care suporta toate aspectele ale implementarii protocolului, cel care urmează sa ofere acces la resursele care le are în administrare către alți clienți. Poate fi un site de stocare de poze care oferă acces altor site-uri pentru preluarea imaginilor stocate de către un anume utilizator. Poate fi un site care stochează toate contactele (nume, email, telefon, adresa) personale ale unor utilizatori. Poate fi, în general, orice serviciu care oferă stocarea de informații private și accesibile selectiv. De regulă, acest furnizor de servicii, își oferă serviciile în baza unei înscrieri și în baza unei autentificări folosind un nume utilizator și o parolă.
• Utilizatorul – este cel pentu care s-a inventat acest protocol. Utilizatorul are resurse în cadrul unui furnizor de servicii (imagini, video, contacte, mesaje) care nu vrea sa le facă publice, dar care vrea sa le folosească și pe alte site-uri. El este cel care va decide cărui site va acorda acces la resursele proprii
• Consumatorul – este site-ul de pe care se dorește accesarea resurselor aflate la furnizorul de servicii.
• Jetonul – sau celebrul token, este identificatorul prin care furnizorul de servicii va comunica cu consumatorul. În baza lui se va ști ce resurse și ale cărui utilizator trebuiesc partajate

Astfel, presupunem că deținem un cont pe site-ul Flickr în care avem stocate câteva imagini din vacanța de iarna. Aceste imagini le dorim printate folosind un serviciu online. În situația de față furnizorul de servicii este flickr.com deoarece deține niște resurse pe care dorim sa le partajăm folosind protocolul OAuth către un site ce oferă servicii de printare. Pentru a obține imaginile stocate pe flickr.com putem manual să le descărcăm și să le încarcăm pe site-ul de printat fotografii. Dar ar dura prea mult. Site-ul de printare fotografii se oferă să le preia automat în numele nostru. Pentru aceasta noi va trebui să furnizăm adresa de email şi parola pentru ca site-ul să ceară în numele nostru lista de fotografii pe care o avem pe Flickr. Intervine problema securităţii şi a increderii faţă de site-ul care ne va printa pozele: furnizând parola, aceasta poate fi stocată pe serverele lor, iar cineva rău intenţionat poate crea daune.

Aici intervine OAuth. Procesul de obţinere de informaţii de la Flickr fără a dezvălui parola pe alte site-uri decât Flickr.com este următorul

1. Accesăm site-ul comsumatorului, în cazul nostru cel care ne va oferi servicii de printat fotografii.
2. În cadrul acestuia vom găsi informatii cum că este dispus să preia imagini de pe site-ul flick.com
3. Pentru a prelua aceste informatii vom fi redirectionati pe flickr.com
4. Fiind pe flickr.com, deci într-un loc sigur, putem să ne autentificăm cu emailul şi cu parola persoanlă
5. După autentificare flickr.com ne va redirecţiona înapoi pe site-ul de la care am pornit (cel de printare imagini) şi îi va furniza acestuia şi un jeton (token)
6. Folosind acest jeton, site-ul de printare fotografii va face cereri in numele nostru catre flickr.com pentru a accesa fotografiile ce urmeaya a fi printate.

Jetonul este un cod unic, securizat, cu ajutorul acelui caruia se asigură faptul că se vor accesa doar imaginile din contul nostru şi pentru o perioadă finită de timp.

Vom arăta în următorul articol o implementare parctică a protocolului OAuth folosind un serviciu de microblogging. Vom crea o aplicaţie care interacţionează prin OAuth cu o platfomă externă pentru autentificare şi trimitere de mesaje.

În timp ce programatorii PHP încep să descarce si să testeze cea mai mare modifcare adusă limbajului de programare din ultimii 7 ani, mulţi se întreabă nu despre ce le-a adus Moş Crăciun în sacul lui plin de jucării pentru a le folosi în dezvoltarea aplicaţiilor de mâine ci despre modificările aduse în limbajul de programare care vor afecta aplicaţiile de ieri.

Vestea cea buna este că dacă v-aţi ţinut aplicaţia în ton cu modificările aduse limbajului sunt puţine modificări care vă vor afecta. Vestea cea rea este că pe măsura ce vă îndepărataţi de versiunea curentă portarea aplicatiilor devine din ce în ce mai grea.

Ceea ce urmează nu este o listă de noi funcţionalităţi din PHP 5.3, puteţi găsi destule referinţe bune in spaţiul web pentru informare. Acest articol este o sinteză a manualului de migrare la PHP 5.3. Vom acoperi acele subiecte care afectează continuitatea ramurii 5.x

Functii de procesare a vectorilor

Inainte de PHP 5.3, multe din funcţiile folosite la procesarea vectorilor puteau primi ca parametrii un obiect sau un vector. Din PHP 5.3 multe din aceste funcţii vor putea primi doar vectori. Daca doriţi accesarea unei proprietati din obiecte cu una din următoarele funcţii, va trebui să le convertiţi la array în prealabil.

• natsort()
• natcasesort()
• usort()
• uasort()
• uksort()
• array_flip()
• array_unique()

Modificari în funcţiile magice

Înainte de 5.3 metodele magince puteau fi declarate cu orice modificator de vizibilitate.

• __get()
• __set()
• __isset()
• __unset()
• __call()

Din PHP 5.3 aceste metode trebuiesc declarate publice, si nu pot fi statice.

Considerate depăşite

PHP are o lista de funcţii care au fost marcate pentru a fi eliminate din limbaj. Majoritatea acestor funcţii nu au o folosire comună, dar ar fi utilă o verificare a lor. Funcţiile marcate pentru eliminare sunt:

• call_user_method()
• call_user_method_array()
• define_syslog_variables()
• ereg()
• ereg_replace()
• eregi()
• eregi_replace()
• set_magic_quotes_runtime()/magic_quotes_runtime()
• session_register()
• session_unregister()
• session_is_registered()
• set_socket_blocking()
• split()
• spliti()
• sql_regcase()

În plus, căteva din directivele php.ini au fost marcate pentru eliminare. Daca sunt activate ele vor emite un avertisment de nivel E_DEPRECATED:

• define_syslog_variables
• register_globals
• register_long_arrays
• safe_mode
• magic_quotes_gpc
• magic_quotes_runtime
• magic_quotes_sybase

Cum orice emite un mesaj E_DEPRECATED va fi eliminat la urmatoarea versiune majora a limbajului, acestea sunt niste indicii pentru programatori la ce sa se uite pentru trecerea la PHP 6.

Reconsiderare

În PHP 5.0, funcţia is_a() a fost marcată pentru eliminare in favoarea operatorului instanceof, şi totuşi nu a fost eliminată din limbaj. În PHP 5.3, această decizie a fost reconsiderată, iar apelul către funcţia is_a() nu mai emite un mesaj E_DEPRECATED.

Cuvinte rezervate

Au fost adăugate două noi cuvinte rezervate

• GOTO
• NAMESPACE

Având în vedere natura acestor cuvinte este puţin probabil ca ele să existe în codul provenit din versiunile vechi ale limbajului. Totuşi este o idee buna să va scanaţi codul pentru aceste cuvinte rezervate. Dacă există, ele vor genera erori de parsare. Nu pot fi folosite ca nume de funcţii, clase etc.

Concluzie

Ghidul migrarii către PHP 5.3 poate fi găsit în documentaţia de pe php.net. Nu sunt multe elemente din PHP 5.3 care să împiedice un cod bine scris in PHP 5.x sa funcţioneze în versiunea 5.3. Aceasta nouă versiune vine mai mult cu adaugiri la limbaj.

Multumiri

De cele mai multe ori se trece peste aprecierea si multumirea celor care au contribuit la dezvoltarea PHP-ului. Nu cred ca vom trece mai departe fără a face si noi acest lucru. Multumim întregii echipe care si-a dedicat timpul pentru crearea şi îmbunătăţirea PHP-uluiâ

Acest articol este o traducere a articolului Migrating to PHP 5.3.0 aparut in techPortal.

Cache-ul este o zonă temporară de stocare de informatii, care duplică niste date considerate originale, creat pentru acces direct si rapid asupra acestor date. Aceasta mapare a datelor faţă de locul lor de stocare iniţial, se face pentru  acele date care sunt greu de accesat în mod direct, care se afla în zone partajate, care ar avea un timp de prelucrare ridicat si care ar fi solicitate în mod frecvent, iar rezultatul ar fi de fiecare dată acelaşi.

Sisteme de cache se întalnesc implementate în microprocesoare(exemplul fiind cache-ul de nivel 2), în hard disk-uri(pentru a micşora timpul de citire al datelor), în sisteme de management al bazei de date(MySQL va ţine în cache rezultatul unei interogari, iar la primirea aceleiaşi interogări va returna rezultatul din cache, făra a interoga tabelele în sine), in browser-ele pe car ele folosim zi de zi(Firefox de exemplu îşi va face cache la imagini, ca la un refresh sa nu fie nevoit sa le preia de pe server din nou), chiar şi Google deţine propriul cache din care poate furniza conţinutul paginilor web.

Aşadar, scopul declarat al cache-ului este de a economisi timp.

Teoria Cache-ului

Există cateva concepte cheie în teoria cache-ului care trebuiesc respectate în implementarea unui astfel de sistem

1. identificatorul unic – care va fi folosit la identificarea elementului în cache
2. durata de viaţă – defineşte cât timp un element din cache va fi considerat valid
3. preluarea condiţionată – astfel încat părţile din cod care ar accesa informaţiile originale să fie evitate, dar să si permită reîmprospătarea
4. resetarea la cerere – pentru păstrarea consistenţei informaţiilor din cache cu cele din locaţia originală, este necesară posibilitatea ca la o modificare a datelor din această locaţie, cache-ul sa fie marcat ca invalid şi reconstruit

Astfel, un algoritm general de folosire a cache-urilor ar fi:

• dacă elementul din cache cerut de aplicaţie există atunci el va fi returnat intocmai
• dacă elementul din cache cerut nu există atunci datele acelui cache se vor aduce din locaţia originală, se va crea elementul corespunzător în cache, iar datele vor fi returnate aplicaţiei

Aplicare

Aşadar, vom presupune o apicaţie web, pentru care avem un număr mare de accesări atât din partea vizitatorilor dar şi din partea celor care administrează respectivul website. Pentru o şi mai buna exemplificare, vom considera cazul standard al unui magazin online, în care avem listări de categorii, listări de produse din fiecare categorie şi afisări detaliate de produse(preţ, descriere, detalii tehnice etc). În spatele site-ului, respectiv în aplicaţia de administrare a acestuia, avem un număr de operatori care lucrează necontenit la imbunătăţirea informaţiilor prezentate pe acel site. Mai mult decât atât, să mai luam în calcul existenţa unor aplicaţii care periodic sincronizează preţurile şi stocurile produselor cu cele existente la furnizorii direcţi. Pentru a îmbunătăţi imaginea de ansamblu să considerăm ca magazinul are câteva zeci de mii de produse. În cuvinte mult mai simple şi mai tehnice: o mulţime de interogări sql de tip insert, update dar mai ales select.

Dezavantajul unui astfel de scenariu este evident cel al supraîncărcării bazei de date cu interogări care de cele mai multe ori se vor repeta şi vor furniza acelaşi set de date. Cu toate că, de exemplu, MySQL deţine un cache propriu din care returnează un set de date al unei interogari la o repetare a acesteia, aplicaţia PHP care interogheză baza de date va trebui sa realizeze tot protocolul de comunicare, să furnizeze interogarea şi să primească datele, deci nişte timpi deşi mici, deloc de neglijat în contextul unui volum de trafic ridicat.

Continuând scenariul nostru de “groază” mai trebuie luat în considerare faptul ca la o interogare de tip insert sau update, cele cauzate de aplicaţia de administrare, pot apărea lock-uri pe câmpurile, înregistrările sau chiar tabelele din baza de date, deci până la terminarea execuţiei şi scrierea ori modificarea cu succes a datelor în bază, o instrucţiune select, nu va putea citi baza de date pentru preluarea informaţiilor şi va fi pusă în aşteptare până la terminarea tranzacţiei. Rezultă un timp mort şi mai mare. Cache-ul ar trebui sa intervină în astfel de momente, când putem spune ca majoritatea interogarilor vor furniza acelaşi set de date pentru perioade definite de timp,  iar rularea lor nu ne-ar aduce decât dezavantaje.

Interogând baza de date pentru a obţine informaţiile despre produsele din categoria “Monitoare LCD” vom obţine unset de date reprezentat printr-un vector cu produsele din acea categorie. Datele din acest vector pot fi introduse în cache. Conform algoritmului general descris mai sus putem scrie urmatorul cod PHP

if (!($data = loadFromCache('cache_for_category_id_' . $categoryId)))
{
    $data = loadDataFromDatabase($categoryId);
    saveToCache('cache_for_category_id_' . $categoryId, $data, 3600);
}

Plecăm astfel de la premisa ca informaţia căutată se afla în cache şi chiar încercăm să o preluăm. Dacă functia loadFromCache() va întoarce o valoare nulă atunci înseamnă ca datele nu se află în cache şi ele vor trebui aduse din baza de date, lucru ce se va face prin functia loadDataFromDatabase() iar apoi salvate în cache cu ajutorul funcţiei saveToCache(), cache valabil o ora. Chiar dacă presupunerea noastră iniţială referitoare la existenţa datelor în cache este adevărată sau nu, după executarea acestei porţiuni de cod vom avea în variabila $data informaţiile necesare.

Trebuie avut în vedere faptul că în tot acest timp datele considerate valide sunt cele din baza de date, cache-ul fiind doar o copie locala a acesteia. Deşi sistemul ne va reseta automat cache-ul după expirarea perioadei de viaţă, vor exista situaţii când cache-ul va deveni inconsistent, adică nu va mai reflecta realitatea din baza de date. Deci, la adăugarea unui produs nou în baza de date în categoria “Monitoare LCD”, cache-ul construit mai devreme nu mai este consistent(nu conţine si acest nou produs). Cum varianta în care aşteptăm trecerea celor 3600 de secunde pentru a se recrea cache-ul nu ne multumeşte(perioada putând fi mult mai mare), aplicaţia de administrare va trebui sa intervină asupra cache-ului şî să invalideze înregistrarea ce conţine datele din această categorie. În acest mod vom forţa recreerea cache-ului cu noile informaţii la următoarea accesare a categoriei respective.

resetCache('cache_for_category_id_' . $categoryId);

În tot scenariul de mai sus am considerat crearea de cache-uri pe categorii şi nu unul global care să conţină toate categoriile existente pe site, din considerente de acces si de resetare. Este mai simplu sa alegem direct cache-ul categoriei pe care dorim să o afişăm decât sa încărcăm toate categoriile prin care să o căutăm pe cea dorită, precum este mai normal ca la introducerea produsului nou în categorie să resetăm doar cache-ul categoriei respective şi nu cel al tuturor produselor.

Unelte

PHP nu deţine nativ funcţii de lucru cu cache-ul, însă există extensii PECL care pot fi instalate şi cu care se pot lucra, printre care enumerăm Memcache şi APC.

Folosirea extensiei Memcache:

$cache = new Memcache();
$cache->addServer('localhost');

if(!($data = $cache->get('cache_id'))
{
    $data = getData();
    $cache->add('cache_id', $data);
}
$cache->delete('cache_id');

Folosirea extensiei APC:

if(!($data = apc_fetch('cache_id'))
{
    $data = getData();
    apc_add('cache_id', $data);
}
apc_delete('cache_id');

Diferenţa dintre cele 2 extensii este aceea că Memcache va stoca informaţiile în memoria RAM a serverului, pe când APC le va stoca in fişiere pe hard disc.

UPDATE:

A Practical Guide to Data Caching with Zend Server scrisă de Shahar Evron, Product Manager la Zend Technologies, Inc., este o lucrare apărută recent şi pe care o recomandăm celor interesati de acest subiect.

Până la un subiect mai serios, care se află deja în scriere, vin cu o problemă, ce se adresează celor care se considera începători. Mi s-a întamplat sa dau această “problemă” unora de nivelul celui menţionat mai devreme, iar răspunsurile să  mă surprindă de fiecare dată.

Aşadar, dându-se un array (vector) cu 2 milioane de elemente, indexate corespunzător de la 0 la 1.999.999 cu valori de tip string, să zicem sub 1 KB ca dimensiune. 

Scrieţi o funcţie care să determine dacă vectorul în cauză este sau nu mulţime. Evident, se cere un timp de execuţie al funcţiei minim

Un vector este considerat mulţime dacă are toate valorile distincte

Citeam zilele tecute pe The PHP Benchmark un articol  care compară diversele metode prin care se poate parcurge un vector asociativ. În mod normal, un foreach simplu care ne-ar funriza cheia şi valoarea aflată la cel index ar fi de ajuns la fel şi soluţia unui for cu indice de la zero la numarul maxim de elemente, în cazul în care cheile vectorului ar fi numere întregi. Cu toate acestea însă, în cazul unui volum mare de date utilizarea unui foreach, uşoară şi comodă, poate duce la un timp de execuţie foarte mare


reset($aHash);
foreach($aHash as $key => $val)
{
$aHash[$key] .= "a";
}


Exemplul de mai sus, are timp de executie 409 µs pe un vector de 100 de elemente.


$key = array_keys($aHash);
$size = sizeOf($key);
for ($i=0; $i<$size; $i++)
{
$aHash[$key[$i]] .= "a";
}


Deşi cel de-al 2-lea exemplu presupune mai multe opreaţii decât primul, timpul de execuţie în conditiile în care furnizăm acelaşi vector de 100 de elemente este de 38 µs ... de 10 ori mai putin.

In acest articol vom incerca sa va dam cateva idei despre ce reprezinta si mai ales despre ce poate face Adobe Flex.

Ce este Flash stie toata lumea. Il intalnim pe aproape orice pagina de web. Cat de bun sau folositor este nu face obiectul acestui articol insa avand in vedere ca Adobe raporteaza ca numarul de download-uri pentru aceasta aplicatie depaseste 10 milioane vom pleca de la premiza ca este folosit pe scara larga.

Ce este RIA sau mai bine zis ce intelegem prin RIA?. Rich Internet Application pleaca de la premiza ca orice activitate se executa fara refresh-ul paginii in browser. Utilizand tehnologia transferurilor asincrone de date catre si dinspre server sau mai bine zis AJAX aplicatii de acest fel au inceput a fi dezvoltate pe platforme precum Adobe Flash, Java FX sau Microsoft Silverlight simuland pana la un anumit nivel o aplicatie tip desktop.

FLEX SDK reprezinta un framework pentru dezvoltarea aplicatiilor Flash. Acest pachet este distribuit gratis si poate genera doua tipuri de aplicatii. Prima dintre ele se poate executa intr-o pagina html si este livrata sub forma unui fisier swf. Cea de-a doua genereaza un fisier air care in esenta lui este un installer a unei aplicatii ce ruleaza local pe orice fel de platforma cu ajutorul lui Adobe AIR. Tutoriale pentru acest produs se gasesc cam peste tot pe internet insa echipa InPHPweTrust le recomanda pe cele de pe site-ul producatorului.

De ce Adobe FLEX pe un site intitulat “In PHP we trust” ? Vom incerca o deductie scurta. Orice aplicatie medie fie desktop fie web comunica cu o baza de date sau cu un sistem de acumulare de date unificat. Acest sitem de cunostinte cu siguranta va avea nevoie de o aplicatie de management care sa ruleze pe server si care sa gestioneze datele rapid si eficient. In articolele urmatoare va vom prezenta solutii sau idei despre cum se pot construi aplicatiile PHP si FLEX pentru un mai bun “user experience”.

Vă doresc un an nou mai bun, sau cel puţin la fel de bun pe cât a fost 2008, plin de realizări şi, evident, cu mult cod.

La multi ani!

Una din primele întrebări pe care le adresăm unui programator începător dornic de cunoaştere aprofundată a programării web este: “Ce este web-ul?”. Deşi o întrebare cu un răspuns aparent simplu, rar ni se întamplă să primim un acelaşi răspuns. Pentru fiecare dintre noi web-ul înseamnă altceva, şi se referă întotdeauna la motivele pentru care îl utilizăm. Poate fi un mediu de socializat, un bun suport de promovare, de comunicare, de făcut marketing şi implicit bani. Pentru unii însă, web-ul este o reţea interconectată de calculatoare, de maşini care interacţionează între ele pe principiul client-server.

Arhitectura client-server este o arhitectură de bază în funcţionare internetului, şi neînţeleasă de la început, poate face ca aprofundarea programării web şi a conceptelor din aceasta sa fie foarte greu de înţeles şi poate duce la confuzii care pot avea efecte devastatoare asupra unor aplicaţii lansate publice.

Client

Clientul este partea din această arhitectură care va iniţia comunicarea. Este cel care va trimite o cerere către un server pentru a primi un răspuns, nişte informaţii peronalizate pentru cererea care tocmai a făcut-o, date in general. Clientul poate fi un browser de web care se conectează la un server web, poate fi un client de e-mail(gen Thunderbird sau Microsoft Outlook) care se conectează la un server de email, trimite datele de autentificare pentru un cont de e-mail si cererea de primire a mesajelor noi, poate fi un client de FTP(gen Smart FTP sau Cute FTP) care va trimite unui server de FTP cererea de stocare pe acel server a unui fişier, urmat de fişierul în sine şi va primi ca răspuns confirmarea primirii acestuia sau un mesaj de eroare corespunzător. Aşadar clientul este cel care va acţiona şi va determina un întreg lanţ de acţiuni din partea server-ului: iniţiază cererea către server, aşteaptă raspunsul de la server, primeşte răspunsul de la server şi în final îl returnează utilizatorului posibil într-un mod formatat.

Server

Un server, în general, este probabil cea mai pasivă, indolentă şi comodă invenţie de pe internet. Serverul nu are niciodată iniţiativă, principala lui activitate este de a sta şi de a aştepta. Serverul nu va acţiona niciodată din cont propriu, nu va transmite date decât dacă este întrebat şi decât dacă sunt urmate anumite reguli de comunicare. Cu toate acestea, odată “deranjat” un server va face tot posibilul să mulţumească cererea clientului. Când este pornit, un server va lua poziţia de aşteptare de conexiuni (numită mai tehnic: listening state), de regulă acesta ascultă pe un anume port primirea conexiunilor. La primirea unei astfel de conexiuni, deci implicit a unei cereri, el va face toate demersurile necesare pentru a returna rezultatul aşteptat. Dacă este un server web, va întoarce clientului (browserul web) codul html al paginii care a fost cerută, dacă este un server de e-mail va returna clientului o listă cu toate email-urile pe care le-a primit de la ultima cerere, daca este un server de MySQL va prelua interogarea SQL primită o va executa şi va returna setul de date rezultat. Aşadar un server stă şi aşteaptă conexiuni pe care le va servi cererile de îndată ce au fost primite.

Diferenţe

Nu trebuie înţeles că toate calculatoarele personale, laptopurile sau orice maşină folosită în mod frecvent de o fiinţă umană este un client şi restul sunt servere. Noţiunea de client-server este întâlnită între oricare două maşini între care exista o cale de acces, o conexiune directă sau indirectă. De exemplu, să presupunem ca avem o maşină pe care ţinem o bază de date MySQL, o maşină pe care o folosim ca web server (deci unde stocăm fişierele unui web site) şi o maşină care va fi folosită drept client. Astfel, iniţiem o cerere de la client către serverul web pentru a primi o anumită pagina în care vom vizualiza, de exemplu, produsele de pe un magazin online. Serverul web primeşte cererea şi va acţiona întocmai, însă datele necesare generării acestei pagini HTML care va conţine informaţiile despre produse, se află în baza de date, deci pe un alt server. Serverul web, prin intermediul librariilor din PHP va iniţia acum o cerere către serverul de MySQL pentru a întoarce informaţiile despre produse, pe care cel din urmă le va furniza. În această ultimă situaţie serverul web este client pentru serverul de MySQL pentru că el este cel care iniţiază o cerere de date iar baza de date va furniza raspunsul la această cerere. În final, cu datele primite se va furniza pagina HTML complet formatată.

Protocolul HTTP este poate unul dintre cele mai simple protocoale. Este un protocol care tăieşte în prezent, nu are amintiri şi nici vise care speră să i se îndeplinească în viitor. Tradus în limbaj tehnic acest lucru înseamnă că un server web (care se foloseşte de protocolul HTTP) nu va şti şi nici nu-i va păsa dacă o cerere va veni de la acelaşi utilizator precum precedenta sau de la un utilizator nou. Acesta tratează fiecare cerere ca şi cum ar fi unică şi ca şi cum nu ar avea nici o legătură cu posibile cereri precedente sau viitoare. Acest lucru ar fi un dezavantaj evident, dacă nu ar exista diverse căi de a suplini acest neajuns. O astfel de cale se numeşte sesiune, iar limbajul PHP dispune de o serie de funcţii pentru a uşura lucrul cu sesiuni.

Sesiunile sunt folosite aşadar pentru a crea continuitate între accesările utilizatorilor unui site, chiar dacă aceste au loc la intervale relativ ridicate de timp. Sesiunile sunt stocate pe server, iar la cel mai jos nivel de reprezentare ele sunt nişte fişiere ce sunt stocate într-o zonă sigură a serverului de unde PHP-ul poate avea acces pentru citire, modificare sau creare. Ele sunt menţinute în relaţie cu clientul printr-un identificator de sesiune care va fi stocat la client de regulă într-un cookie(poate fi transmis şi printr-un parametru din GET).

Sesiunile de deschid în două modalităţi: imiplicit şi explicit. Implicit se face prin directiva de configurare aflată în fişierul php.ini numită session.auto_start, care setată pe valoarea 1 va porni implicit sesiunea la începutul rulării oricărui script PHP. Explicit, aceasta se realizează la cererea programatorului folosind funcţia session_start() de regulă la începutul fiecărui script. Avantaje si dezavantaje există de ambele parţi, prin pornirea implicită se evită apelarea în fiecare script al aplicaţiei a funcţiei session_start() însă datorită faptului că o sesiunea se va crea înainte de încărcarea fişierelor auxiliare folosite într-o aplicaţie, cum ar fi cele de definire a claselor, facând astfel imposibilă stocarea unor obiecte în sesiuni. Pornită explicit, funcţia session_start() va trebui apelată întotdeauna înainte de a trimite orice informaţie către client, deoarece aceasta va încerca stabilirea cookie-ului de sesiune, care va fi transmis printr-un header la client.

Informaţiile stocate pe sesiunie se pot regăsi în variabila superglobala $_SESSION care va fi creată automat la pronirea sesiunii şi care va conţine toate informaţiile deja existente pe sesiune. Se pot scrie, citi şi sterge informaţii din această variabilă, care beneficiază de toate avantajele oferite de vectorii limbajului PHP.


session_start();
$_SESSION['isLogged'] = true;



session_start();
if ($_SESSION['isLogged'])
{
echo "Utilizatorul este autentificat";
}


Presupunând că cele 2 coduri reprezintă fişiere diferite, apelate în ordine vor genera afişarea mesajului de autentificare iar variabila se va păstra pe sesiune până la ştergerea ei sau pănă la distrugerea sesiunii.

O sesiune este persistentă până când aceasta este ştearsă sau până când ea expiră. Timpul de expirare este dat de către timpul de expirarea al cookie-ului păstrat în browser-ul clientului. Directiva session.cookie_lifetime din php.ini este setată implicit pe valoarea zero, şi înseamnă că sesiunea va expira în momentul în care utilizatorul va închide browser-ul. În cazul în care se doreşte forţarea unei sesiuni persistente se poate folosi funcţia session_set_cookie_params(). Distrugerea manuală a datelor existente într-o sesiune se poate face prin functia session_destroy()

Vom începe scrierea unei serii de articole menite să promoveze diverse practici de programare sau utilizare corectă a limbajului PHP, MySQL, Javascript sau a framework-ului de la Zend. Ne vom adresa prin acestea în special începătorilor şi vom încerca să arătăm consecintele unei folosiri incorecte a diverselor facilităţi oferite de limbajele de mai sus.