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()
Salut.
Am si eu o nelamurire: Daca apelez funcia session_start() si apoi scot niste informatii din variabila $_SESSION trebuie apoi sa apelez functia session_destroy() sau se apeleaza singura cand se termina scriptul? Din ce am inteles eu, aceasta functie este inversul functiei session_start(), deci nu distruge si continutul variabilei $_SESSION… Ca sa sterg date din $_SESSION, eu am folosit unset($SESSION(‘whatever’)).
PS: Poate reusesti sa scrii un articol mai detaliat despre sesiuni si despre restul functiilor PHP legate de acestea…
Aşa cum am afirmat în articol funcţia session_destroy() va şterge datele din sesiune, nu sesiunea în sine. Sesiunea va exista în continuare şi poate fi folosită normal
foarte bun articolul, dear cico ai explicat in 2 vorbe ceea ce tot cautam sa aflu de ceva timp…
ps: in god we trust! everything else must have md5 checksum!
Dezavantajul deschiderii sesiunii în mod explicit se poate evita prind arhitectură bine gândită. Cei ce apelează la front controller pattern design sunt acoperiți. Cei cu MVC pot avea un base controller pe care să-l derive (you’ve gotta love OOP). Chiar și mizeriile acelea de scripturi independente pot avea un init inclus, dar să-i ierte Dumnezeu pe cei ce vor avea nevoie de reguli de rewrite în acest caz.
În rest, recomand session.use_only_cookies setat pe 1. În mod “tradițional” PHP-ul era vulnerabil la session fixation trimis prin GET (cacalamal.php?SESSIONID=[insert coin to continue]) și se prea poate să mai fie, dar n-am testat, la mine 1 e implicit. Deasemenea n-ar strica session.cookie_httponly pentru cei cu PHP 5.2.0+ pentru că poate evita citirea cookie-ului ce conține Session ID-ul prin metode XSS pe browserele ce respectă flag-ul respectiv și pentru XmlHttpRequest, unde cele bazate pe Gecko sunt acoperite de ceva vreme.
Printre altele, legat de exemplul de cod din articol, recomand ca flag-urile de autentificare (cum e acel $_SESSION['isLogged'] = true
să fie verificare corect.
if ($_SESSION['isLogged'])
nu e tot una cu
if ($_SESSION['isLogged'] === true)
chiar dacă pentru valoarea true se evaluează la fel. În plus, nu recomand ca autentificarea să se facă pe bază de sesiune, ci mai degrabă prin cookie trimis doar prin conexiune SSL, dacă se poate (în general nu se poate SSL pe shared hosts datorită arhitecturii proaste Apache + mod_ssl și pentru faptul că majoritatea oricum fac oversell pe shared), iar verificarea datelor de autentificare să se facă la fiecare cerere. Da, e un “overhead” acolo, dar modelul acesta “stateful” pentru autentificare a ridicat suficiente probleme de securitate de-alungul istoriei.
Ac6um eu știu că acest articol este dedicat începătorilor, dar o trântesc aici ca să nu mai umplu alte pagini de comentarii: începătorii de azi, coderii de mâine. PHP conduce detașat la capitotlul “web security issues” pentru un motiv anume: cred că 90% din cei ce se auto-intitulează “PHP coders” sunt pastă, Joomla groupies programmers wannabes. Pentru cei ce au ceva de obiectat la propoziția anterioară, un search pe Secunia este relevant. De cele mai multe ori particula defectă stă între scaun și tastatură din moment ce doar aproximativ 1% din problemele de securitate ale PHP sunt generate de către nucleul limbajului. Deci încă de la început ar trebui ca lucrurile să fie făcute bine. Eu inițial le-am învățat prost și a trebuit să depun eforturi substanțiale pentru a uita mizeriie învățate în școală legate de PHP.