Si të konfiguroni telefonat inteligjentë dhe PC. Portali informativ

Grackat e përdorimit të seancave në PHP. Përdorimi i Sesioneve - Puna me Sesionet PHP

Ueb serveri nuk mban një lidhje të përhershme me klientin dhe çdo kërkesë përpunohet si e re, pa asnjë lidhje me të mëparshmet.
Kjo do të thotë, nuk mund të gjurmoni as kërkesat nga i njëjti vizitor, as të ruani variabla për të midis pamjeve individuale të faqeve. Pikërisht për të zgjidhur këto dy probleme u shpikën seancat.
Në fakt, seancat, me pak fjalë, janë një mekanizëm që ju lejon të identifikoni në mënyrë unike një shfletues dhe krijon një skedar për këtë shfletues në server që ruan variablat e sesionit.

Unë nuk do të përshkruaj në detaje nevojën për një mekanizëm të tillë. Bëhet fjalë për raste tekstesh shkollore, si p.sh. një karrocë blerjesh në një dyqan elektronik, autorizim, si dhe probleme jo krejt të parëndësishme, si p.sh. mbrojtja e pjesëve ndërvepruese të një faqeje nga mesazhet e padëshiruara.

Në parim, është mjaft e lehtë të bësh analogun tënd të seancave, jo aq funksionale sa PHP-ja e integruar, por e ngjashme në thelb. Në cookies dhe bazën e të dhënave.
Kur kërkojmë një skript, ne shikojmë nëse ka mbërritur një cookie me një emër specifik. Nëse nuk ka cookie, atëherë ne e vendosim atë dhe shkruajmë një linjë të re me të dhënat e përdoruesit në bazën e të dhënave. Nëse ka një cookie, atëherë lexojmë nga baza e të dhënave. Me një kërkesë tjetër, fshijmë të dhënat e vjetra nga baza e të dhënave dhe tani kemi gati mekanizmin e sesionit. Mjaft e lehtë. Por ka disa nuanca që e bëjnë të preferueshme përdorimin e mekanizmit të integruar të sesionit.

Nëse aktivizohet vetëm i pari, atëherë në fillim të seancës (me çdo telefonatë sesioni_fillimi ()) një cookie është vendosur te klienti. Shfletuesi e kthen saktë këtë cookie në çdo kërkesë tjetër dhe PHP ka një ID të sesionit. Problemet fillojnë nëse shfletuesi nuk i kthen cookies. Në këtë rast, pa marrë një cookie me një identifikues, PHP do të fillojë një sesion të ri gjatë gjithë kohës dhe mekanizmi nuk do të funksionojë.

Nëse aktivizohet vetëm i dyti, atëherë cookie nuk është vendosur. Dhe ajo që ndodh është për hir të së cilës, në thelb, në fakt, ia vlen të përdoret mekanizmi i integruar i sesionit. Pasi skripti kryen punën e tij dhe faqja është formuar plotësisht, PHP skanon të gjitha dhe shton në secilën lidhje dhe në secilën formë transferimin e identifikuesit të sesionit. Duket diçka si kjo:
Indeksi shndërrohet në
Indeksi
Shtimi i një fushe të fshehur në forma

Dhe shfletuesi, kur klikoni në ndonjë lidhje, ose kur klikoni në një buton në formular, do të dërgojë variablin që na nevojitet në kërkesë - ID-në e sesionit!
Për arsye të dukshme, ID-ja shtohet vetëm në lidhjet relative.

Teorikisht, në seancat tona të bëra vetë me ju për skedarët e skedarëve dhe bazën e të dhënave, ju mund t'i atribuoni manualisht transferimin e ID-së në të gjitha lidhjet - dhe më pas sesionet tona do të funksionojnë pavarësisht nga skedarët e skedarëve të skedarëve. Por, e shihni, a është më e këndshme kur dikush tjetër e bën këtë punë? ;-)

Të dy opsionet janë aktivizuar si parazgjedhje në versionet e fundit të PHP. Si sillet PHP në këtë rast? Cookie është vendosur gjithmonë. Lidhjet plotësohen automatikisht vetëm nëse PHP nuk e gjen cookie-n e ID-së së sesionit. Kur një përdorues viziton sajtin për herë të parë në këtë sesion, vendoset një cookie dhe lidhjet plotësohen. Në kërkesën tjetër, nëse kukit mbështeten, PHP e sheh cookie-n dhe ndalon mbushjen e lidhjeve. Nëse cookies nuk funksionojnë, atëherë PHP vazhdon të shtojë id-në në lidhje siç duhet dhe sesioni nuk humbet.
Përdoruesit që kanë skedarë kuki që funksionojnë do ta shohin lidhjen e gjatë me ID-në vetëm një herë.

Phew. Përfundoi me transferimin e identifikuesit.
Tani mbetet për të lidhur një skedar me të dhëna në anën e serverit.
PHP do ta bëjë atë për ne. Është mjaft e lehtë për të shkruar
sesioni_fillimi ();
$_SESSION [ "test" ]= "Përshëndetje botë!" ;

Dhe PHP do të shkruajë në skedarin e lidhur me këtë sesion testin e variablës.
Këtu ka një shënim shumë të rëndësishëm.
varg $_SESSION- e veçantë.
Në të, në fakt, ka variabla që duam t'i vëmë në dispozicion në skripta të ndryshëm.
Për të vendosur një variabël në një sesion, mjafton ta caktoni atë në një element të grupit $_SESSION.
Për të marrë vlerën e tij - thjesht referojuni të njëjtit element. Një shembull do të jetë më poshtë.

Mbledhja e mbeturinave - heqja e skedarëve të vjetëruar PHP gjithashtu trajtohet vetë. Si dhe kodimi i të dhënave dhe një mori gjërash të tjera të nevojshme. Si rezultat i këtij kujdesi, puna me seancat është shumë e thjeshtë.
Këtu, në fakt, erdhëm te shembulli i punës së seancave.
Shembulli është shumë i vogël:
sesioni_fillimi ();

jehonë "Ju e keni përditësuar këtë faqe". $_SESSION[ "counter" ]++. "një herë.";
jehonë"
përditësimi";
?>

Kontrollojmë nëse kemi një variabël numërues në seancë, nëse jo, atëherë e krijojmë atë me vlerën 0 dhe më pas shfaqim vlerën e tij dhe e rrisim me një. Vlera e rritur do të shkruhet në seancë dhe herën tjetër që do të thirret skripti, ndryshorja do të ketë vlerën 1, e kështu me radhë.
Gjithçka është shumë e thjeshtë.

Për të pasur akses në variablat e sesionit në çdo faqe të faqes, duhet të shkruani VETËM NJË (!) rresht në fillim të ÇDO skedari në të cilin na duhen sesione:
sesioni_fillimi ();
Dhe pastaj hyni në elementet e grupit $_SESSION. Për shembull, një kontroll autorizimi do të duket diçka si kjo:
sesioni_fillimi ();
nëse ($_SESSION[ "i autorizuar" ]<> 1 ) {
header ("Vendndodhja: /auth.php");
dalje;
}

Heqja e variablave nga sesioni.
Nëse keni register_globals=off, atëherë mjafton të shkruani
unset($_SESSION[ "var" ]);
Nëse jo, atëherë aty pranë për të shkruar me të
session_unregister("var");

Gabimet më të zakonshme që PHP hedh kur përpiqet të punojë me sesione janë:
Dy prej tyre
Paralajmërim: Nuk mund të dërgohet skedari i sesionit - titujt janë dërguar tashmë
Paralajmërim: Nuk mund të dërgohet kufizuesi i memories së sesionit - titujt janë dërguar tashmë

janë shkaktuar nga e njëjta arsye, zgjidhja përshkruhet në këtë false
e treta,
Paralajmërim: open(/tmp\sess_SID, O_RDWR) dështoi: Asnjë skedar ose direktori (2) në shtegun e plotë_script në numrin e linjës(më parë dukej kështu Paralajmërim: Shkrimi i të dhënave të sesionit (skedarët) dështoi. Ju lutemi verifikoni që cilësimi aktual i session.save_path është i saktë (/tmp)),
nëse përkthehet nga anglishtja, ai shpjegon problemin në detaje: shtegu për në drejtorinë e specifikuar në php.ini nuk është i disponueshëm, në të cilin janë shkruar skedarët e sesionit. Ky gabim është më i lehtë për t'u rregulluar. Thjesht shkruani një direktori që ekziston dhe është e shkruajtshme, për shembull,
sesioni.rruga_save = c:\windows\temp
Dhe mos harroni të rinisni Apache pas kësaj.

Siç rezulton, zgjuarsia njerëzore nuk ka kufi, dhe për këtë arsye jam i detyruar të shpjegoj:
mesazhi i tretë i gabimit (nuk mund të gjendet direktoria) do të rezultojë në mënyrë të pashmangshme në dy të parët, pasi mesazhi i gabimit del në shfletues dhe asnjë titull nuk mund të përdoret pas tij. Prandaj, mos nxitoni të kërkoni një përfundim të parakohshëm, por fillimisht shkruani rrugën e duhur!

Problemi tjetër më i zakonshëm me seancat është trashëgimia e rëndë e register_globals. MOS u jepni emra variablave të skriptit që përputhen me indekset e grupit $_SESSION!
Me register_globals=on, vlerat do të mbishkruajnë njëra-tjetrën dhe do të ngatërroheni.
Dhe me register_globals=off, do të shfaqet një gabim tjetër: "Skripti juaj ndoshta mbështetet në një efekt anësor të sesionit që ekzistonte deri në PHP 4.2.3.", në rast se ka një variabël sesioni në skript që nuk ka vlerë dhe një global ndryshore me të njëjtin emër. Për ta hequr qafe atë, duhet gjithmonë të inicializoni variablat përpara përdorimit (ose të paktën të kontrolloni ekzistencën) dhe mos u jepni emra variablave globalë që përputhen me indekset e grupit $_SESSION.

Nëse nuk funksionon, por nuk shfaqen mesazhe, atëherë shtoni dy rreshta në fillim të skenarit që janë përgjegjës për shfaqjen e TË GJITHA gabimeve në ekran - është mjaft e mundur që të ketë gabime, por thjesht nuk i shihni ato .
ini_set("gabimet_afishimi" , 1 );
raportimi i gabimit (E_ALL);

ose shikoni gabimet në error_log. Në përgjithësi, tema e shfaqjes së mesazheve të gabimit është përtej qëllimit të këtij artikulli, kështu që vetëm sigurohuni që të paktën t'i shihni ato. Mund të lexoni pak më shumë rreth gjetjes së gabimeve në këtë seksion.

Nëse jeni të sigurt se nuk ka gabime, por shembulli i mësipërm nuk funksionon gjithsesi, atëherë është e mundur që PHP të mos mundësojë kalimin e ID-së përmes url-së, Cookies nuk funksionojnë për ndonjë arsye.
Shikoni se çfarë po ndodh me cookie-t tuaja.
Në përgjithësi, nëse seancat nuk funksionojnë për ju, atëherë së pari përpiquni të kaloni me dorë identifikuesin e sesionit, domethënë, bëni një lidhje dhe caktoni një identifikues për të:
sesioni_fillimi ();
if (!isset($_SESSION [ "counter" ])) $_SESSION [ "counter" ]= 0 ;
jehonë "Ju e keni përditësuar këtë faqe". $_SESSION[ "counter" ]++. "një herë.

përditësimi";
?>

Kur e bëni këtë, sigurohuni që direktiva session.use_only_cookies të mos përfshihet, gjë që e pengon PHP-në të pranojë një ID të sesionit nëse është kaluar përmes një URL

Nëse ky shembull nuk funksionon, atëherë problemi është ose në atë banal gabime printimi(gjysma e "problemeve" me sesionet vijnë nga një emër variabli i shkruar gabimisht), ose në një version të PHP që është shumë i vjetër: mbështetja e sesioneve u prezantua në versionin 4.0 dhe një grup $_SESSION- në 4.1 (E përdorur më parë $HTTP_SESSION_VARS).
Nëse funksionon, atëherë problemi është në cookies. Gjurma - çfarë lloj cookie i vendos serveri në shfletues, nëse shfletuesi e kthen atë. Kërkimi është shumë i dobishëm duke parë shkëmbimin e titujve HTTP midis shfletuesit dhe serverit.
Një shpjegim se si funksionojnë cookies është përtej fushëveprimit të këtij teksti tashmë shumë të gjatë, por të paktën sigurohuni që serveri të dërgojë një cookie me një identifikues dhe shfletuesi ta kthejë atë. Dhe në të njëjtën kohë, identifikuesit përkojnë me njëri-tjetrin =)
Cilësimi i cookie duhet të duket si
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6;
ose si
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; rrugë =/
(nëse po kërkoni një skript jo nga direktoria rrënjësore)
Përgjigja e serverit duhet të duket si
Kuki: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6
ose
Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; b=b
nëse shfletuesi kthen një cookie të ndryshme nga ID-ja e sesionit.

Nëse shfletuesi nuk kthen cookie - kontrolloni nëse cookies funksionojnë fare.
Sigurohuni që domeni ku po hyni të ketë një emër të vlefshëm (që ka të paktën një pikë dhe nuk përmban karaktere të paligjshme si nënvizat) dhe pastroni cache-in e shfletuesit tuaj - këto janë dy arsyet kryesore pse kukit mund të mos funksionojnë.

Nëse shembulli nga këtu funksionon, por kodi juaj nuk funksionon, atëherë problemi padyshim nuk është te sesionet, por te algoritmi. Kërkoni se ku keni humbur variablin, transferoni shembullin nga këtu hap pas hapi, korrigjoni skriptin tuaj.

Një problem tjetër mund të lindë nëse përdorni ridrejtimin e kokës ose navigimin JavaScript.
Fakti është se PHP automatikisht shton identifikuesin e sesionit vetëm në lidhjet e formularit
, por nuk e bën këtë për headers, javascript, meta etiketat.
Prandaj, duhet të shtoni identifikuesin me dorë, për shembull, si kjo:
header("Vendndodhja: /script.php?" .emri_sesionit(). "=" .sesion_id());

Gjithashtu, një shumë e rrallë, dhe është plotësisht e paqartë nga vjen, problemi është se cilësimi session.save_handler ka një vlerë të ndryshme nga skedarët. Nëse nuk është, rregullojeni.

Siguria
Siguria e seancës është një temë e gjerë. Prandaj, do të përqendrohem në disa pika kryesore.
Teksti më shkollor - mos e kaloni identifikuesin përmes shiritit të adresave. Kjo është shkruar edhe në php.ini, por kufizon funksionalitetin e sesioneve. Nëse vendosni të ndiqni këtë këshillë, atëherë përveç session.use_trans_sid = 0, mos harroni sesion.use_only_cookies = 1
Këshillohet që të lidhni seancën me një adresë IP: në këtë mënyrë, nëse identifikuesi vidhet, zuzari nuk do të jetë ende në gjendje ta përdorë atë në shumicën e rasteve.
Rekomandohet të përdorni direktivën session.save_path, me të cilën mund të vendosni direktorinë tuaj për ruajtjen e skedarëve të sesionit. Kjo është më e sigurt se kur ato ruhen në drejtorinë e përkohshme të përbashkët të serverit si parazgjedhje.

Informacion shtese:

  • Përveç cookies, mekanizmi i sesionit dërgon gjithashtu tituj që ndalojnë ruajtjen e faqeve (i njëjti kufizues i cache-it). Për html, kjo është e saktë dhe e nevojshme. Por kur përpiqeni të dërgoni një skedar me një skript që kontrollon autorizimin, Internet Explorer refuzon ta shkarkojë atë. Kjo është për shkak të këtij titulli. Thirrni
    session_cache_limiter ("privat");
    para fillimit të seancës duhet të zgjidhë problemin.
  • Sado e çuditshme të duket, por në grup $_SESSION ju nuk mund të përdorni indekse numerike - $_SESSION [ 1 ], $_SESSION [ "10" ]- seancat nuk do të funksionojnë.
  • Diku midis versioneve 4.2 dhe 5.0 nuk ishte e mundur të vendosej session.use_trans_sid me ini_set(). Duke filluar nga 5.0 tashmë është e mundur përsëri.
  • Përpara versionit 4.3.3, PHP dërgoi një cookie vetëm nëse kërkesa nuk kishte një identifikues kur filloi sesioni. Tani cookie dërgohet në çdo telefonatë sesioni_fillimi ()

    Një shembull i autorizimit duke përdorur seancat
    Le të ilustrojmë të gjitha sa më sipër me një shembull të vogël:
    krijoni skedarin auth.php:
    if (isset($_POST [ "auth_name" ]))
    {
    $sql = "ZGJEDH * NGA përdoruesit WHERE emri=?s";
    $row = $db -> getRow($sql, $_POST [ "auth_name" ]);
    nëse ($row && password_verify ($_POST [ "auth_pass" ], $row [ "pass" ])) (
    $_SESSION [ "user_id" ] = $rresht [ "id" ];
    }
    header("Vendndodhja: http://" . $_SERVER ["HTTP_HOST"]. $_SERVER ["REQUEST_URI" ]);
    dalje;
    }

    if (isset($_GET [ "action" ]) AND $_GET [ "action" ]== "logout" ) (
    sesioni_fillimi ();
    sesion_shkatërrim();
    header("Vendndodhja: http://" . $_SERVER ["HTTP_HOST"]. "/" );
    dalje;
    }

    nëse (!isset($_SESSION [ "user_id" ])) (
    ?>








    dalje;
    }

    Tani mjafton të shkruani rreshtin në të gjitha skriptet e mbrojtura
    kërkojnë "auth.php" ;
    Në këtë shembull, supozohet se seanca tashmë ka filluar dhe lidhja me bazën e të dhënave është krijuar, duke përdorur Klasën për punë të sigurt dhe të përshtatshme me MySQL. Ai gjithashtu supozon se fjalëkalimi është hash duke përdorur funksionin e rekomanduar password_hash.
    Shembull i një skedari të mbrojtur:

    sesioni_fillimi ();
    përfshijnë "safemysql.class.php" ;
    $db = new safemysql([ "db" => "test" ]);
    përfshijnë "auth.php" ;
    ?>
    sekret

    shkyç

    OPS! Lidhje shumë të dobishme:
    http://www.php.net/manual/en/ref.session.php - informacioni më i fundit dhe më i fundit në lidhje me mbështetjen e sesioneve në PHP në dokumentacionin zyrtar, plus komentet e shumta të përdoruesve. Lexim shumë i rekomanduar.
    http://phpclub.ru/manrus/f/ref.session.html - Një përkthim SHUMË i vjetëruar i këtij kapitulli në Rusisht, nga dokumentacioni i përkthyer nga Alexander Piramidin.
    http://phpclub.ru/detail/article/sessions
    Një artikull me titullin patetik "E vërteta për seancat". Lë një përshtypje të dyfishtë. Në fillim, autori flet SHUMË i kapshëm për mekanizmin e seancave, por metodat që ai ofron deri në fund të artikullit janë krejtësisht të turbullta.

    Artikulli i librit shkollor nga Dmitry Borodin nga faqja
    http://php.spb.ru/ NUK rekomandohet fuqimisht.
    Djema, ajo është tmerrësisht e vjetëruar. Jo vetëm që ka pasaktësi aktuale, por seancat në PHP nuk kanë funksionuar për një kohë të gjatë.
    Shumë faleminderit Dima për të, ishte artikulli i parë mbi seancat në Rusisht, e studiova vetë, por tani më duhet ta dërgoj në një pushim të merituar.
    Gjithashtu, për fat të keq, shumë artikuj të tjerë që janë në internet dhe nuk përditësohen prej vitesh janë të vjetëruar.

  • Përshëndetje i dashur komunitet.

    Para së gjithash, dua t'ju falënderoj për një burim shumë të dobishëm. Më shumë se një herë kam gjetur këtu shumë ide interesante dhe këshilla praktike.

    Qëllimi i këtij artikulli është të nxjerrë në pah kurthet e përdorimit të seancave në PHP. Sigurisht, ka dokumentacion PHP dhe shumë shembuj, dhe ky artikull nuk pretendon të jetë një udhëzues i plotë. Është krijuar për të zbuluar disa nga nuancat e punës me sesione dhe për të mbrojtur zhvilluesit nga humbja e kohës.

    Rasti më i zakonshëm i përdorimit për seancat është, natyrisht, autorizimi i përdoruesit. Le të fillojmë me zbatimin më themelor në mënyrë që ta zhvillojmë atë vazhdimisht kur shfaqen detyra të reja.

    (Për të kursyer hapësirë ​​dhe kohë, në shembujt do të kufizohemi në vetë funksionet e sesionit, në vend që të ndërtojmë një aplikacion testimi të plotë këtu me një hierarki të bukur klase, trajtim shterues të gabimeve dhe gjëra të tjera të drejta).

    Funksioni startSession() ( // Nëse sesioni ka filluar tashmë, ndaloni ekzekutimin dhe ktheni TRUE // (parametri session.auto_start në skedarin e cilësimeve php.ini duhet të fiket - vlera e paracaktuar) nëse (session_id()) kthe e vërtetë; përndryshe ktheje session_start(); // Shënim: Përpara versionit 5.3.0, session_start() u kthye TRUE edhe nëse ndodhi një gabim. // Nëse jeni duke përdorur një version nën 5.3.0, bëni një kontroll shtesë për session_id() // pas thirrjes sesion_start() ) funksion shkatërronSession() ( if (session_id()) ( // Nëse ka një seancë aktive, fshini kukit e sesionit, setcookie(sesion_name(), session_id(), time() -60*60*24); // dhe shkatërro sesionin session_unset(); session_destroy(); ) )

    Shënim: Supozohet se lexuesi ka njohuri bazë për sesionet PHP, kështu që ne nuk do të mbulojmë këtu parimin e funksionimit të funksioneve session_start() dhe session_destroy(). Detyrat e paraqitjes së formularit të hyrjes dhe vërtetimit të përdoruesit nuk lidhen me temën e artikullit, kështu që ne gjithashtu do t'i heqim ato. Më lejoni t'ju kujtoj se për të identifikuar përdoruesin në çdo kërkesë të mëpasshme, duhet të ruajmë identifikuesin e përdoruesit në variablin e sesionit (për shembull, me emrin userid) në momentin e hyrjes me sukses, i cili do të jetë i disponueshëm në të gjitha kërkesat pasuese. brenda jetëgjatësisë së seancës. Është gjithashtu e nevojshme të zbatohet përpunimi i rezultatit të funksionit tonë startSession(). Nëse funksioni është kthyer FALSE - shfaqni formularin e hyrjes në shfletues. Nëse funksioni u kthye TRUE dhe ekziston një variabël sesioni që përmban ID-në e përdoruesit të vërtetuar (në rastin tonë, userid), shfaqni faqen e përdoruesit të vërtetuar (për më shumë mbi trajtimin e gabimeve, shihni shtimin e 2013-06-07 në seksionin mbi sesionin variablat).

    Ndërkohë që gjithçka është e qartë. Pyetjet fillojnë kur kërkohet të zbatohet kontrolli i mungesës së aktivitetit të përdoruesit (koha e seancës), për të lejuar disa përdorues të punojnë njëkohësisht në një shfletues dhe gjithashtu për të mbrojtur seancat nga përdorimi i paautorizuar. Kjo do të diskutohet më poshtë.

    Kontrolli i pasivitetit të përdoruesit me mjetet e integruara PHP

    Pyetja e parë që shpesh lind midis zhvilluesve të të gjitha llojeve të konzollave për përdoruesit është përfundimi automatik i seancës në rast të pasivitetit nga ana e përdoruesit. Nuk ka asgjë më të lehtë sesa ta bësh këtë me veçoritë e integruara të PHP. (Ky opsion nuk është shumë i besueshëm dhe fleksibël, por ne do ta konsiderojmë atë për hir të plotësisë).

    Funksioni startSession() ( // Koha e paaktivitetit të përdoruesit (në sekonda) $sessionLifetime = 300; nëse (session_id()) kthehet e vërtetë; // Cakto jetëgjatësinë e kukive ini_set ("session.cookie_lifetime", $sessionLifetime); // Nëse përdoruesi është joaktiv caktohet koha e skadimit, caktoni jetëgjatësinë e sesionit në server // Shënim: Për një server prodhimi, rekomandohet të paracaktoni këto parametra në skedarin php.ini nëse ($sessionLifetime) ini_set("session.gc_maxlifetime", $sessionLifetime ); nëse (session_start( )) (setcookie(sesion_name(), session_id(), time()+$sessionLifetime); kthe e vërtetë; ) përndryshe kthej false; )

    Disa shpjegime. Siç e dini, PHP përcakton se cilin sesion do të fillojë bazuar në emrin e cookie-t të kaluar nga shfletuesi në kokën e kërkesës. Shfletuesi, nga ana tjetër, e merr këtë cookie nga serveri, ku vendoset nga funksioni session_start (). Nëse cookie në shfletues ka skaduar, ajo nuk do të kalojë në kërkesë, që do të thotë se PHP nuk do të jetë në gjendje të përcaktojë se cilin sesion të fillojë dhe ta trajtojë atë si krijimin e një sesioni të ri. Parametri i cilësimeve të PHP-së session.gc_maxlifetime, i cili është caktuar në kohëzgjatjen e mosaktivitetit të përdoruesit, cakton jetëgjatësinë e sesionit PHP dhe kontrollohet nga serveri. Kontrolli i jetëgjatësisë së sesionit funksionon si më poshtë (këtu shembulli i ruajtjes së sesionit në skedarë të përkohshëm konsiderohet si opsioni më i zakonshëm dhe i paracaktuar në PHP).

    Kur krijohet një sesion i ri, një skedar me emrin sess_ krijohet në drejtorinë e vendosur si drejtoria e sesionit në parametrin e cilësimeve të PHP-së session.save_path. , ku - identifikuesi i sesionit. Më tej, në çdo kërkesë, në momentin e fillimit të një sesioni tashmë ekzistues, PHP përditëson kohën e modifikimit të këtij skedari. Kështu, në çdo kërkesë pasuese, PHP, nga diferenca midis kohës aktuale dhe kohës së fundit të modifikimit të skedarit të sesionit, mund të përcaktojë nëse sesioni është aktiv ose kohëzgjatja e tij ka skaduar tashmë. (Mekanizmi për heqjen e skedarëve të vjetër të sesionit diskutohet më në detaje në seksionin vijues.)

    Shënim: Duhet të theksohet këtu se parametri session.gc_maxlifetime ndikon në të gjitha seancat brenda të njëjtit server (më saktë, brenda të njëjtit proces kryesor PHP). Në praktikë, kjo do të thotë që nëse ka disa sajte që funksionojnë në server dhe secila prej tyre ka afatin e vet të mosaktivitetit të përdoruesit, atëherë vendosja e këtij parametri në një nga faqet do të bëjë që ai të vendoset për sajte të tjera. E njëjta gjë vlen edhe për pritjen e përbashkët. Për të shmangur këtë situatë, drejtoritë e veçanta të sesioneve përdoren për çdo sajt brenda të njëjtit server. Vendosja e shtegut në direktorinë e sesionit bëhet duke përdorur parametrin session.save_path në skedarin e cilësimeve php.ini, ose duke thirrur funksionin ini_set(). Pas kësaj, sesionet e çdo sajti do të ruhen në drejtori të veçanta dhe parametri session.gc_maxlifetime i vendosur në një nga faqet do të ndikojë vetëm në sesionin e tij. Ne nuk do ta shqyrtojmë këtë rast në detaje, veçanërisht pasi kemi një opsion më fleksibël për të kontrolluar pasivitetin e përdoruesit.

    Kontrollimi i pasivitetit të përdoruesit me variablat e sesionit

    Duket se versioni i mëparshëm, me gjithë thjeshtësinë e tij (vetëm disa rreshta shtesë kodi), jep gjithçka që na nevojitet. Por, çka nëse jo çdo kërkesë mund të konsiderohet si rezultat i aktivitetit të përdoruesit? Për shembull, faqja ka një kohëmatës që bën periodikisht një kërkesë AJAX për të marrë përditësime nga serveri. Një kërkesë e tillë nuk mund të konsiderohet si aktivitet i përdoruesit, që do të thotë se zgjatja automatike e jetëgjatësisë së sesionit nuk është e saktë në këtë rast. Por ne e dimë se PHP përditëson automatikisht kohën e modifikimit të skedarit të sesionit sa herë që thirret funksioni session_start(), që do të thotë se çdo kërkesë do të zgjasë jetëgjatësinë e sesionit dhe nuk do të ndodhë kurrë koha e mosveprimit të përdoruesit. Për më tepër, shënimi i fundit nga seksioni i mëparshëm mbi hollësitë e parametrit sesion.gc_maxlifetime mund të duket tepër konfuz dhe i vështirë për t'u zbatuar nga dikush.

    Për të zgjidhur këtë problem, ne do të braktisim përdorimin e mekanizmave të integruar PHP dhe do të prezantojmë disa variabla të reja të sesionit që do të na lejojnë të kontrollojmë vetë kohën e pasivitetit të përdoruesit.

    Funksioni startSession($isUserActivity=true) ($sessionLifetime = 300; nëse (session_id()) kthehet i vërtetë; // Cakto jetëgjatësinë e cookie-t derisa shfletuesi të mbyllet (ne do të kontrollojmë gjithçka në anën e serverit) ini_set("sesion .cookie_lifetime", 0) ; nëse (! session_start()) kthen false; $t = time(); nëse ($sessionLifetime) ( // Nëse koha e mosaktivitetit të përdoruesit është caktuar, // kontrolloni kohën e kaluar që nga përdoruesi i fundit aktiviteti // (koha e kërkesës së fundit kur u përditësua ndryshorja e sesionit të aktivitetit të fundit) nëse (isset($_SESSION["lastactivity"]) && $t-$_SESSION["lastactivity"] >= $sessionLifetime) ( // Nëse koha e kaluar që nga aktiviteti i fundit i përdoruesit është // më i madh se koha e pasivitetit, atëherë sesioni ka skaduar dhe ju duhet të përfundoni seancën shkatërroniSession(); ktheni false; ) tjetër ( // Nëse afati nuk ka përfunduar ende eja, // dhe nëse kërkesa erdhi si rezultat i aktivitetit të përdoruesit, // përditësoni variablin e fundit të aktivitetit me vlerën e vr aktuale emri, // duke zgjatur kështu kohën e seancës me një sesion tjetër Lifetime sekonda nëse ($isUserActivity) $_SESSION["lastactivity"] = $t; ) ) kthehen e vërtetë; )

    Le të përmbledhim. Në çdo kërkesë kontrollojmë nëse afati nuk është arritur që nga aktiviteti i fundit i përdoruesit deri në momentin aktual dhe nëse është, shkatërrojmë seancën dhe anulojmë funksionin, duke e kthyer FALSE. Nëse koha nuk është arritur dhe parametri $isUserActivity me vlerën TRUE i kalohet funksionit, ne përditësojmë kohën e aktivitetit të fundit të përdoruesit. Gjithçka që duhet të bëjmë është të përcaktojmë në skriptin e thirrjes nëse kërkesa është rezultat i një aktiviteti të përdoruesit dhe nëse jo, telefononi funksionin startSession me $isUserActivity të vendosur në FALSE.

    Përditësim nga 07-06-2013
    Trajtimi i rezultatit të funksionit sesionStart().

    Komentet tërhoqën vëmendjen për faktin se kthimi FALSE nuk jep një kuptim të plotë të shkakut të gabimit, dhe kjo është absolutisht e drejtë. Unë nuk publikova trajtimin e detajuar të gabimeve këtu (vëllimi i artikullit tashmë nuk është i vogël), pasi kjo nuk lidhet drejtpërdrejt me temën e artikullit. Por duke pasur parasysh komentet, do ta sqaroj.

    Siç mund ta shihni, funksioni sesionStart mund të kthejë FALSE në dy raste. Ose sesioni dështoi të fillonte për shkak të ndonjë gabimi të brendshëm të serverit (për shembull, cilësimet e pasakta të sesionit në php.ini), ose sesioni mbaroi. Në rastin e parë, duhet ta ridrejtojmë përdoruesin në një faqe gabimi që deklaron se ka probleme në server dhe një formular kontakti për mbështetjen. Në rastin e dytë, duhet ta transferojmë përdoruesin në formularin e hyrjes dhe të shfaqim një mesazh të përshtatshëm në të se koha e seancës ka skaduar. Për ta bërë këtë, duhet të fusim kodet e gabimit dhe të kthejmë kodin përkatës në vend të FALSE, dhe në metodën e thirrjes, ta kontrollojmë dhe të veprojmë në përputhje me rrethanat.

    Tani, edhe nëse sesioni ekziston ende në server, ai do të shkatërrohet herën e parë kur aksesohet nëse afati i pasivitetit të përdoruesit ka skaduar. Dhe kjo do të ndodhë pavarësisht nga jeta e sesionit të caktuar në cilësimet globale të PHP.

    Shënim:Çfarë ndodh nëse shfletuesi mbyllet dhe skedari i sesionit shkatërrohet automatikisht? Kërkesa për serverin herën tjetër që të hapet shfletuesi nuk do të përmbajë skedarin e sesionit dhe serveri nuk do të jetë në gjendje të hapë sesionin dhe të kontrollojë kohën e paaktivitetit të përdoruesit. Për ne, kjo është e barabartë me krijimin e një sesioni të ri dhe nuk ndikon në asnjë mënyrë funksionalitetin dhe sigurinë. Por lind një pyetje e drejtë - kush atëherë do ta shkatërrojë seancën e vjetër, nëse deri më tani e kemi shkatërruar pas skadimit të afatit? Apo do të mbetet përgjithmonë në drejtorinë e sesioneve? Për të pastruar seancat e vjetra, PHP ka një mekanizëm të quajtur grumbullimi i mbeturinave. Ai funksionon në kohën e kërkesës së radhës në server dhe pastron të gjitha seancat e vjetra bazuar në datën kur skedarët e sesionit janë modifikuar për herë të fundit. Por mekanizmi i grumbullimit të mbeturinave nuk aktivizohet me çdo kërkesë në server. Frekuenca (më saktë, probabiliteti) i nisjes përcaktohet nga dy parametrat e cilësimeve session.gc_probability dhe session.gc_divisor. Rezultati i ndarjes së parametrit të parë me të dytin është probabiliteti i aktivizimit të mekanizmit të grumbullimit të plehrave. Kështu, në mënyrë që mekanizmi i pastrimit të sesionit të lansohet në çdo kërkesë në server, këto parametra duhet të vendosen në vlera të barabarta, për shembull, "1". Kjo qasje siguron që drejtoria e sesioneve të jetë e pastër, por padyshim është shumë e shtrenjtë për serverin. Prandaj, në sistemet e prodhimit, session.gc_divisor është vendosur si parazgjedhje në 1000, që do të thotë se mekanizmi i grumbullimit të mbeturinave do të funksionojë me një probabilitet prej 1/1000. Nëse eksperimentoni me këto cilësime në skedarin tuaj php.ini, mund të vëreni se në rastin e mësipërm, kur shfletuesi mbyllet dhe pastron të gjitha skedarët e tij të personalizimit, ka ende sesione të vjetra të mbetura në drejtorinë e sesioneve për pak kohë. Por kjo nuk duhet t'ju shqetësojë, sepse. siç është përmendur tashmë, kjo në asnjë mënyrë nuk ndikon në sigurinë e mekanizmit tonë.

    Përditësim nga 07-06-2013

    Parandaloni varjen e skripteve për shkak të kyçjes së skedarit të sesionit

    Në komente, u ngrit pyetja për varjen e ekzekutimit të njëkohshëm të skripteve për shkak të bllokimit të skedarit të sesionit (si opsioni më i mrekullueshëm - sondazh i gjatë).

    Për të filluar, vërej se ky problem nuk varet drejtpërdrejt nga ngarkesa e serverit ose numri i përdoruesve. Sigurisht, sa më shumë kërkesa, aq më ngadalë ekzekutohen skriptet. Por kjo është një varësi indirekte. Problemi shfaqet vetëm brenda një sesioni, kur serveri merr disa kërkesa në emër të një përdoruesi (për shembull, njëra prej tyre është sondazh i gjatë, dhe pjesa tjetër janë kërkesa të zakonshme). Çdo kërkesë përpiqet të hyjë në të njëjtin skedar sesioni dhe nëse kërkesa e mëparshme nuk e zhbllokoi skedarin, atëherë tjetra do të mbetet në pritje.

    Për të mbajtur në minimum bllokimin e skedarit të sesionit, rekomandohet shumë që të mbyllet sesioni duke thirrur funksionin session_write_close() menjëherë pasi të kenë përfunduar të gjitha manipulimet me variablat e sesionit. Në praktikë, kjo do të thotë që nuk duhet të ruani gjithçka në variablat e sesionit dhe t'u referoheni atyre gjatë ekzekutimit të skriptit. Dhe nëse keni nevojë të ruani disa të dhëna pune në variablat e sesionit, atëherë lexoni ato menjëherë në fillim të seancës, ruajini ato në variablat lokale për përdorim të mëvonshëm dhe mbyllni seancën (që do të thotë mbyllja e seancës duke përdorur funksionin session_write_close dhe jo shkatërrimi i tij duke përdorur session_destroy).

    Në shembullin tonë, kjo do të thotë që menjëherë pas hapjes së sesionit, kontrollimit të jetëgjatësisë së tij dhe ekzistencës së një përdoruesi të autorizuar, ne duhet të lexojmë dhe ruajmë të gjitha variablat shtesë të sesionit të nevojshëm për aplikacionin (nëse ka), më pas mbyllim seancën duke thirrur session_write_close( ) dhe vazhdoni të ekzekutoni një skenar, pavarësisht nëse është një sondazh i gjatë ose një kërkesë e rregullt.

    Mbrojtja e seancës nga përdorimi i paautorizuar

    Le të imagjinojmë një situatë. Një nga përdoruesit tuaj fikson një trojan që grabit skedarët e skedarëve të shfletuesit (në të cilin ruhet sesioni ynë) dhe e dërgon atë në emailin e specifikuar. Sulmuesi merr cookie-n dhe e përdor atë për të falsifikuar një kërkesë në emër të përdoruesit tonë të autorizuar. Serveri e merr dhe e përpunon me sukses këtë kërkesë sikur të ishte nga një përdorues i autorizuar. Nëse verifikimi shtesë i adresës IP nuk zbatohet, një sulm i tillë do të çojë në një hakim të suksesshëm të llogarisë së përdoruesit me të gjitha pasojat që pasojnë.

    Pse u bë e mundur kjo? Natyrisht, për shkak se emri dhe identifikuesi i seancës janë gjithmonë të njëjta për të gjithë jetëgjatësinë e seancës, dhe nëse i merrni këto të dhëna, atëherë mund të dërgoni lirisht kërkesa në emër të një përdoruesi tjetër (natyrisht, brenda kohëzgjatjes së këtij sesioni) . Ky mund të mos jetë lloji më i zakonshëm i sulmit, por teorikisht duket mjaft i realizueshëm, veçanërisht duke marrë parasysh që një Trojan i tillë nuk ka nevojë as për të drejtat e administratorit për të grabitur skedarët e shfletuesit të përdoruesit.

    Si mund të mbroheni nga sulmet e këtij lloji? Përsëri, padyshim, duke kufizuar jetëgjatësinë e identifikuesit të sesionit dhe duke ndryshuar periodikisht identifikuesin brenda të njëjtit sesion. Ne gjithashtu mund të ndryshojmë emrin e sesionit, duke fshirë plotësisht të vjetrin dhe duke krijuar një sesion të ri, duke kopjuar të gjitha variablat e sesionit nga ai i vjetër në të. Por kjo nuk ndikon në thelbin e qasjes, prandaj, për thjeshtësi, ne kufizohemi vetëm në identifikuesin e sesionit.

    Është e qartë se sa më e shkurtër jetëgjatësia e identifikuesit të sesionit, aq më pak kohë do të ketë një sulmues për të marrë dhe aplikuar cookie për të falsifikuar një kërkesë të përdoruesit. Idealisht, një identifikues i ri duhet të përdoret për çdo kërkesë, i cili do të minimizojë mundësinë e përdorimit të sesionit të dikujt tjetër. Por ne do të shqyrtojmë rastin e përgjithshëm, kur koha e rifreskimit të ID-së së sesionit vendoset në mënyrë arbitrare.

    (Le të heqim pjesën e kodit që tashmë është shqyrtuar).

    Funksioni startSession($isUserActivity=true) (// Kohëzgjatja e ID-së së sesionit $idLifetime = 60; ... nëse ($idLifetime) ( // Nëse jetëgjatësia e ID-së së sesionit është caktuar, // kontrolloni kohën e kaluar që kur seanca ishte krijuar ose rigjenerimi i fundit // (koha e kërkesës së fundit kur u përditësua variabli i seancës) if (isset($_SESSION["starttime"])) ( if ($t-$_SESSION["starttime"] >= $idLifetime) ( / / Koha e seancës id ka skaduar // Gjeneroni një id të ri session_regenerate_id(true); $_SESSION["starttime"] = $t; ) ) other ( // Ne arrijmë këtu nëse sesioni sapo është krijuar // Vendosni gjenerimin e id-it të sesionit koha në orën aktuale $_SESSION["starttime"] = $t; ) ) kthehet e vërtetë; )

    Pra, kur krijojmë një sesion të ri (i cili ndodh në momentin e një hyrjeje të suksesshme të përdoruesit), ne vendosim variablin e seancës starttime, e cila ruan kohën e gjeneratës së fundit të identifikuesit të sesionit për ne, në një vlerë të barabartë me kohën aktuale. të serverit. Më tej, në çdo kërkesë, kontrollojmë nëse ka kaluar mjaft kohë (idLifetime) nga gjenerimi i fundit i identifikuesit dhe nëse ka kaluar, ne gjenerojmë një të ri. Kështu, nëse gjatë kohëzgjatjes së caktuar të identifikuesit, një sulmues që ka marrë një cookie të autorizuar të përdoruesit nuk ka kohë për ta përdorur atë, serveri do ta konsiderojë kërkesën e rreme si të paautorizuar dhe sulmuesi do të dërgohet në faqen e hyrjes.

    Shënim: ID-ja e re e sesionit shkon në cookie-n e shfletuesit kur thirret session_regenerate_id(), e cila dërgon një cookie të re, të ngjashme me funksionin session_start(), kështu që nuk kemi nevojë ta përditësojmë vetë cookie-n.

    Nëse duam t'i sigurojmë seancat tona sa më shumë që të jetë e mundur, mjafton të vendosim jetëgjatësinë e identifikuesit në një, ose madje të heqim funksionin session_regenerate_id () nga kllapat dhe të heqim të gjitha kontrollet, të cilat do të çojnë në rigjenerimin e identifikues në çdo kërkesë. (Unë nuk e kam testuar ndikimin e kësaj qasjeje në performancën dhe mund të them vetëm se funksioni session_regenerate_id(true) kryen në thelb vetëm 4 veprime: gjenerimi i një identifikuesi të ri, krijimi i një titulli me kuki të sesionit, fshirja e të vjetrit dhe krijimi një skedar të ri sesioni).

    Digresioni lirik: Nëse trojani është aq i zgjuar sa nuk do t'i dërgojë cookie sulmuesit, por vetë organizon dërgimin e një kërkese të rreme të parapërgatitur menjëherë pas marrjes së cookie-t, metoda e përshkruar më sipër ka shumë të ngjarë të mos jetë në gjendje të mbrojë kundër një të tillë. sulm, sepse ndërmjet kohës kur Trojani merr cookie-n dhe dërgon kërkesën e rreme, praktikisht nuk do të ketë asnjë ndryshim dhe ka të ngjarë që në këtë pikë ID-ja e sesionit të mos rigjenerohet.

    Aftësia për të punuar njëkohësisht në një shfletues në emër të disa përdoruesve

    Detyra e fundit që do të doja të merrja në konsideratë është mundësia e punës së njëkohshme në një shfletues nga disa përdorues. Kjo veçori është veçanërisht e dobishme gjatë fazës së testimit kur ju duhet të imitoni përdoruesit e njëkohshëm dhe është e dëshirueshme ta bëni këtë në shfletuesin tuaj të preferuar, në vend që të përdorni të gjithë arsenalin e disponueshëm ose të hapni disa raste të shfletuesit në modalitetin e fshehtë.

    Në shembujt tanë të mëparshëm, ne nuk e caktuam në mënyrë eksplicite emrin e sesionit, kështu që u përdor emri i paracaktuar PHP (PHPSESSID). Kjo do të thotë që të gjitha sesionet që kemi krijuar deri tani kanë dërguar cookie në shfletuesin me emrin PHPSESSID. Natyrisht, nëse emri i cookie-t është gjithmonë i njëjtë, atëherë nuk ka asnjë mënyrë brenda të njëjtit shfletues për të organizuar dy sesione me të njëjtin emër. Por nëse do të përdornim emrin tonë të sesionit për secilin përdorues, atëherë problemi do të zgjidhej. Pra, le ta bëjmë atë.

    Funksioni startSession($isUserActivity=true, $prefix=null) ( ... nëse (session_id()) kthehet true; // Nëse një prefiks përdoruesi kalohet në parametrat, // vendosni një emër unik sesioni që përfshin këtë prefiks, // përndryshe vendosni një emër të përbashkët për të gjithë përdoruesit (për shembull, MYPROJECT) emri i sesionit ("MYPROJECT".($prefiks ? "_".$prefiks: "")); ini_set("session.cookie_lifetime", 0); nëse (! session_start()) kthen false; ...)

    Tani e vetmja gjë që mbetet për të bërë është të siguroheni që skripti thirrës të kalojë një parashtesë unike për çdo përdorues në funksionin startSession(). Kjo mund të bëhet, për shembull, duke kaluar një prefiks në parametrat GET/POST të çdo kërkese, ose përmes një cookie shtesë.

    konkluzioni

    Si përfundim, do të jap kodin e plotë përfundimtar të funksioneve tona për të punuar me sesionet PHP, duke përfshirë të gjitha detyrat e diskutuara më sipër.

    Funksioni startSession($isUserActivity=true, $prefiks=null) ( $sessionLifetime = 300; $idLifetime = 60; nëse (session_id()) kthehet i vërtetë; emri i sesionit ("MYPROJECT".($prefiksi ? "_".$prefiksi: "")); ini_set ("session.cookie_lifetime", 0); nëse (! session_start()) kthen false; $t = time(); if ($sessionLifetime) ( if (isset($_SESSION["lastactivity"] ) && $t-$_SESSION["lastactivity"] >= $sessionLifetime) (structSession(); kthe false; ) tjetër (nëse ($isUserActivity) $_SESSION["lastactivity"] = $t; ) ) nëse ($idLifetime ) ( if (isset($_SESSION["starttime"])) ( if ($t-$_SESSION["starttime"] >= $idLifetime) ( session_regenerate_id(true); $_SESSION["starttime"] = $t; ) ) else ($_SESSION["fillimi"] = $t; ) ) kthen true; ) funksioni shkatërronSession() ( if (session_id()) ( session_unset(); setcookie(sesion_name(), session_id(), time() -60*60*24); session_destroy(); ) )

    Shpresoj se ky artikull do të kursejë pak kohë për ata që nuk janë thelluar kurrë në mekanizmin e seancave dhe do të japë një kuptim të mjaftueshëm të këtij mekanizmi për ata që sapo kanë filluar të njihen me PHP.

    Sesionet në PHP, ose si ruhen të dhënat për një përdorues ose blerës që ka hyrë në sajt, kur kaloni midis faqeve të sajtit pa shumë vështirësi. Mësimi është shumë i rëndësishëm. E rëndësishme për krijimin e 95% të faqeve.

    Çfarë është sesioni në php

    Sesionet përdoren për të ruajtur informacione rreth të dhënave të përkohshme (për shembull, që përdoruesi ka vizituar sitin) kur lundroni midis faqeve të të njëjtit sajt. Kur përdorni sesione, të dhënat ruhen në skedarë të përkohshëm në server.
    Më shpesh, seancat (dhe cookies, nga rruga, gjithashtu) përdoren kur krijohen dyqane në internet, forume, tabela buletinesh, rrjete sociale, bloge dhe burime të tjera. Komoditeti i sistemit të sesionit qëndron në ruajtjen e informacionit të përkohshëm të përdoruesit/blerësit të regjistruar, të dhënat për të cilat janë në akses të shpejtë për një kohë të caktuar. Një seancë ka një datë të natyrshme skadimi - derisa shfletuesi të mbyllet. Nëse mbyllni vetëm faqen, atëherë kur hapni faqen, të dhënat për përdoruesin / blerësin do të jenë ende të disponueshme.

    Logjika e seancës

    Sesioni (ose sesioni) është një lloj ruajtjeje të përkohshme të të dhënave. Ju paralajmëroj menjëherë, ia vlen të kurseni një sasi të vogël të dhënash. Për shembull, identifikimi dhe fjalëkalimi i përdoruesit që hyn ose numri i tij serial në bazën e të dhënave.

    Shembull pune
    1. Përdoruesi vendos një emër përdoruesi dhe fjalëkalim dhe hyn në faqe
    2. Të dhënat me hyrje dhe fjalëkalim ruhen në seancën e njërës prej faqeve të faqes:

    Skedari indeks.php

    sesioni_fillimi (); // çdo skedar në të cilin dëshironi të përdorni të dhënat e sesionit duhet të përmbajë komandën "start sesion" në fillim të kodit

    $login = "admin";
    $password = "kalim";
    $_SESSION["login"] = $login; // ruani variablin që përmban hyrjen
    $_SESSION["fjalëkalim"] = $fjalëkalim; // ruani variablin që përmban fjalëkalimin

    3. Kur shkoni në një faqe tjetër të sajtit, këto të dhëna do të jenë gjithashtu të disponueshme:

    Skedari shembull.php(ose ndonjë faqe tjetër)

    Echo "Identifikimi juaj ".$_SESSION["login"]; // printon "Identifikimi juaj është admin", edhe pse ne nuk kemi shkruar asnjë të dhënë në këtë faqe!
    Shihni, është e thjeshtë!

    4. Nëse dëshironi të pastroni të dhënat e sesionit, atëherë thjesht:

    Skedari shembull.php

    sesioni_fillimi (); // "fillo seancën" përsëri

    Unset($_SESSION["identifikimi"]); // kështu që ndryshorja ishte e çregjistruar ose "shkatërruar"
    echo "Identifikimi juaj është ".$_SESSION["login"]; // shfaq "Identifikimi juaj" . Meqenëse e kemi shkatërruar në rreshtin e fundit, nuk ka të dhëna

    sesion_shkatërrim(); // shkatërroni seancën. Të gjitha të dhënat, duke përfshirë $_SESSION["password"] janë zhdukur. Kur ato kërkohen, do të shfaqet një gabim.
    Në përgjithësi, një transferim i tillë është i ngjashëm me metodën POST, por nuk keni më nevojë të shkruani shumë kod shtesë, dhe të gjitha të dhënat e transferuara nga faqja në faqe ruhen në skedarë të përkohshëm në server. Përsëri, seancat duhet të përmbajnë sasi të vogla të dhënash, kështu që ato janë të përshtatshme për ruajtjen e hyrjes / fjalëkalimit, karrocat e blerjeve dhe vëllime të tjera të vogla.

    Kalimi i një vlere ose grupi duke përdorur një sesion PHP

    Ju mund të shkruani në seancë jo vetëm një varg, por edhe një grup të dhënash. Thjesht mos e teproni me madhësinë e grupit, pasi e gjithë kjo do të ndikojë në performancën dhe hapësirën e zënë në server.

    Ripërdorimi i faqes fillestare indeks.php

    sesioni_fillimi ();

    $r = grup ("një", "dy", "tre");

    $_SESSION["arr"] = $r;

    Në faqen ku do të shfaqet gjithçka
    Ne i ruajmë të dhënat në seancë dhe ndjekim lidhjen në një faqe tjetër, ku do të shfaqen të gjitha të dhënat.

    Skedari i destinacionit, faqe test.php ku të hapet grupi

    sesioni_fillimi ();
    print_r($_SESSION["arr"]);
    // dalje
    /*
    varg
    => një
    => dy
    => tre
    */
    ?>
    Ju mund të dëshironi të pastroni . Në përgjithësi, gjithçka duhet të jetë e qartë.

    Funksione të tjera për të punuar me sesione

    sesioni_çregjistror(varg)- sesioni harron vlerën e ndryshores së dhënë globale;
    sesion_shkatërrim()- sesioni është shkatërruar (për shembull, nëse përdoruesi u largua nga sistemi duke shtypur butonin e daljes);
    sesioni_set_cookie_params (jeta int [, shtegu i vargut [, domeni i vargut]])- duke përdorur këtë funksion, mund të caktoni se sa do të zgjasë seanca duke vendosur unix_timestamp që përcakton kohën e vdekjes së sesionit.

    Lista e funksioneve për të punuar me sesione (sesion) në php
    session_cache_expire - Rikthen skadimin e cache-it aktual
    session_cache_limiter - Merr dhe/ose vendos kufizuesin aktual të cache-it
    session_commit - pseudonimi për session_write_close()
    session_decode - Deshifroni të dhënat e sesionit nga një varg
    session_destroy - Shkatërron të gjitha të dhënat e regjistruara për një sesion
    session_encode - Enkripton të dhënat aktuale të sesionit si një varg
    session_get_cookie_params - Merr parametrat e skedarëve të sesionit
    session_id - Merr dhe/ose vendos ID-në e sesionit aktual
    session_is_registered - përcakton nëse ndryshorja është e regjistruar në seancë
    session_module_name - Merr dhe/ose vendos modulin aktual të sesionit
    Emri_sesionit - Merr dhe/ose vendos emrin e sesionit aktual
    session_regenerate_id - Modifikon ID-në e sesionit aktual me atë të krijuar rishtazi
    session_register - Regjistron një ose më shumë variabla për sesionin aktual
    Sesion_save_path - Merr dhe/ose cakton shtegun e ruajtjes së sesionit aktual
    session_set_cookie_params - Vendos parametrat e kukive të sesionit
    session_set_save_handler - Vendos funksionet e ruajtjes së sesioneve në nivel të përdoruesit
    sesion_fillimi - inicializon të dhënat e sesionit
    session_unregister - Çregjistron një variabël nga sesioni aktual
    session_unset - Zhvendos të gjitha variablat e sesionit
    session_write_close - shkruan të dhënat e sesionit dhe fundin e sesionit

    Shembuj të sesioneve

    Numri i shikimeve të faqeve gjatë seancës. Një shembull i mirë i punës. Megjithatë, pas mbylljes së shfletuesit, numërimi mbrapsht do të fillojë përsëri.

    Numri i vizitave në një faqe brenda një seance

    // Një shembull i thjeshtë i përdorimit të seancave pa cookie.
    emri i sesionit ("test");
    sesioni_fillimi ();
    $_SESSION["count"] = @$_SESSION["count"] + 1;
    ?>

    Kundër


    Në sesionin aktual të punës me shfletuesin, ju hapët këtë faqe
    kohë(et).
    Mbyllni shfletuesin për të rivendosur këtë numërues.
    Klikoni këtu për të rifreskuar faqen!
    Me çdo tranzicion, numëruesi do të rritet me 1)

    Faleminderit për vëmendjen! Fat i mirë në përpjekjet tuaja!

    Përpara se të përcaktojmë termin "sesion", le të bëjmë një sfond të vogël se pse kishte nevojë për seanca fare, le të shohim një veçori të protokollit HTTP.

    Një nga veçoritë kryesore të protokollit HTTP është se ai nuk e detyron serverin të ruajë informacionin për klientin midis kërkesave, domethënë të identifikojë klientin. Ky është i ashtuquajturi protokoll pa shtetësi. Komunikimi ndërmjet klientit dhe serverit përfundon sapo të përfundojë përpunimi i kërkesës aktuale. Çdo kërkesë e re për serverin supozohet të jetë krejtësisht unike dhe e pavarur, edhe nëse është dërguar në mënyrë të përsëritur nga i njëjti burim.

    Po sikur të lëmë natyrën pa shtetësi të protokollit HTTP dhe të mos identifikojmë përdoruesin? Gjendjet e sesionit mund të shmangen lehtësisht nëse faqja juaj përmban informacione statike (anonime), të tilla si një artikull lajmesh që përbëhet nga tekst dhe imazhe. Në një kontekst të tillë, nuk është e nevojshme të lidhen pyetje të shumta me të njëjtin përdorues. Në fund të fundit, përmbajtja e artikullit nuk do të ndryshojë në asnjë mënyrë, qofshin dhjetë kërkesa nga një pajisje, ose dhjetë kërkesa nga njerëz të ndryshëm nga pajisje të ndryshme.

    Por, sapo të transferojmë informacionin personal në server, duhet të bëjmë disi që serveri të lidh të gjitha kërkesat tona me ne dhe në të ardhmen të përcaktojë saktë të gjitha kërkesat që vijnë nga ne. Nëse kjo nuk bëhet, atëherë me çdo kërkesë të re ne do të detyrohemi të ritransmetojmë të dhënat e nevojshme personale. Për shembull, një hyrje për të futur llogarinë tuaj personale në faqe, ose informacione të tilla si emri, adresa e dorëzimit, kur bëni një blerje në një dyqan online.

    Vetëm në situata të tilla, kur kërkohet të personalizohen kërkesat nga një klient, ne do të përdorim sesione.

    Sesioni (seancë)- kjo është një periudhë e caktuar kohore brenda së cilës një aplikacion ueb mund të përcaktojë të gjitha kërkesat nga një klient.

    Kur një klient paraqet fillimisht të dhënat personale në një kërkesë, krijohet një sesion i ri në server për atë klient. Gjatë gjithë jetës së sesionit, të gjitha kërkesat nga ky klient do të njihen në mënyrë unike dhe do të lidhen me të. Pas kësaj kohe, komunikimi me klientin do të humbasë, dhe kërkesa e radhës nga ai do të përpunohet si absolutisht unike, jo e lidhur me ato të mëparshme.

    Për shembull, kur bëni një blerje në një dyqan online, informacioni personal i përdoruesit ruhet në sesion ndërsa ai shfleton faqen. Këto janë artikujt e zgjedhur në karrocë, adresa e dorëzimit, detajet e kontaktit, etj.

    Tani le të shohim se si mund ta zbatojmë këtë teknikisht. Në përgjithësi, ekzistojnë disa teknika për menaxhimin e seancave të klientit, numri i tyre dhe mënyra e zbatimit varet kryesisht nga platforma e internetit ose teknologjia që funksionon në server. Në këtë tutorial, ne do të mbulojmë sa vijon:

    1. fushat e fshehura të formës në formën HTML
    2. biskota
    3. sesioni (sesioni, gjendja e sesionit)

    Le të përpiqemi t'i zbatojmë ato duke përdorur platformën ASP.NET. Le të shqyrtojmë shkurtimisht dy mekanizmat e parë dhe t'i kushtojmë vëmendje të veçantë të tretit, pasi është më i besueshëm, i përshtatshëm dhe i sigurt.

    Fushat e fshehura të formularit në formën HTML

    Thelbi i kësaj qasjeje është se ne ofrojmë navigim të faqes duke përdorur forma standarde html. Dhe me çdo kërkesë të radhës, ne ruajmë të dhënat nga ajo e mëparshme në fusha të fshehura në formular. Për shembull:

    @duke përdorur (Html.BeginForm("Forms2", "Home", FormMethod.Post)) (

    Porositja e një pjate

    }
    publike ActionResult Forms2() ( ViewBag.UserName = Request.Form["username"]; ktheje View(); )
    @using (Html.BeginForm("Forms3", "Home", FormMethod.Post)) (

    @($"Përshëndetje (ViewBag.UserName)! Çfarë do të porosisni?")

    }

    Në këtë shembull, ne marrim emrin e përdoruesit në formën e parë html. Tjetra në kontrollues në metodë Format 2 () ne e marrim këtë vlerë nga koleksioni Forma dhe ia kaloni pamjes nëpërmjet një objekti View Bag. Kjo pamje gjeneron kodin për formularin e ri dhe ruan emrin e përdoruesit në një fushë të fshehur. Kështu, vlera e emrit të përdoruesit do të kalojë në formën e tretë së bashku me informacionin shtesë - vlera e fushës me emrin "Emri i ushqimit". etj.

    Le të shohim veçoritë e kësaj qasjeje. Praktikisht nuk ka asnjë plus, përveç se kjo teknikë mund të zbatohet shumë shpejt. Por përsëri, qasjet e tjera gjithashtu mund të zbatohen shumë shpejt. Por ka disa kundër, dhe mjaft domethënëse:


    Biskota

    publike ActionResult Cookies2() ( cookie HttpCookie = HttpCookie e re ("username", HttpUtility.UrlEncode(Request.Form["username"])); cookie.Expires = DateTime.UtcNow.AddHours.A.Cookies(1); cookie); ktheje View();
    @using (Html.BeginForm("Cookies3", "Home", FormMethod.Post)) (

    @($"Përshëndetje (HttpUtility.UrlDecode(Request.Cookies["userName"]?.Vlera))! Çfarë po porositni?")

    }

    Në këtë qasje, ne nuk i ruajmë të dhënat e sesionit direkt në formular, përkundrazi përdorim mekanizmin standard të cookie-ve midis klientit dhe serverit. Cookies ruajnë të gjitha të dhënat e përdoruesit.

    Kur zgjedhim këtë qasje, përsëri, problemi kryesor mbetet siguria e të dhënave tona që transferojmë në server - ato janë të lehta për t'u zëvendësuar ose vjedhur, ato janë të paqarta. Gjithashtu, nëse cilësimet e privatësisë së shfletuesit të klientit çaktivizojnë pranimin e kukive nga sajtet, atëherë ky opsion i menaxhimit të sesionit nuk do të funksionojë fare.

    Kështu, dekurajohet shumë transferimi i të dhënave të rëndësishme dhe sekrete në dy mënyrat e para, si hyrjet, fjalëkalimet, numrat e kartës, numrat e llogarisë, të dhënat e pasaportës, vendbanimi etj.

    Mekanizmi i menaxhimit të sesioneve nga ana e serverit (Session, SessionState)

    Le të analizojmë se si funksionon mekanizmi i sesionit nga ana e serverit dhe nga ana e klientit.

    Me cilësimet standarde për funksionimin e gjendjes së sesionit, i ashtuquajturi. përdoret për të gjurmuar një sërë kërkesash nga një klient. cookie sesioni. Algoritmi është si më poshtë:

    1. Absolutisht për çdo kërkesë të re në server (nuk ka rëndësi nëse janë klientë të ndryshëm apo një) ASP.NET gjeneron një identifikues unik të sesionit.
      ID-ja e sesionit është një numër i krijuar rastësisht i koduar duke përdorur një algoritëm të veçantë në një varg me 24 karaktere. Vargu përbëhet nga fjalë për fjalë nga A në Z me shkronja të vogla, si dhe nga numrat nga 0 në 5. Një shembull identifikues është hjnyuijl1pam3vox2h5i41in
    2. Nëse gjatë kërkesës aktuale të dhënat e klientit NUK ruhen për punë të mëtejshme me të, atëherë jeta e seancës së këtij klienti përfundon (në fakt, pa filluar). Në këtë rast, identifikuesi i sesionit i krijuar më parë bëhet i pavlefshëm (sepse nuk është përdorur). Në përgjigje të një kërkese të tillë, klienti nuk merr asgjë për ta lidhur atë me një seancë të re.
    3. Nëse të dhënat e klientit (për shembull, emri, adresa e transportit) ruhen në server, ASP.NET i lidh të dhënat e ruajtura me një ID sesioni të krijuar më parë. Më pas, krijohet një skedar i veçantë i sesionit, dhe ky identifikues shkruhet gjithashtu në të. Kjo cookie shtohet në përgjigje të një kërkese dhe ruhet në shfletuesin e klientit. Kështu, krijohet një lidhje midis klientit dhe informacionit të tij të personalizuar në server. Është krijuar një sesion i ri për këtë klient.
    4. Me çdo kërkesë të mëpasshme, klienti dërgon një identifikues personal të sesionit në server nëpërmjet një cookie. Serveri përputhet me identifikuesit dhe "njeh" klientin brenda seancës aktuale.
    5. Për sa kohë që klienti transmeton çelësin e tij personal, seanca konsiderohet aktive. Sesioni mund të përfundojë për arsye të ndryshme, për shembull, me dorë në anën e serverit ose pasi të ketë kaluar një kohë e caktuar (përfundimi i kohës).

    Le të kalojmë nga teoria në praktikë. Le të programojmë këtë algoritëm dhe të shohim se si funksionon. Për ta bërë këtë, ne përdorim një klasë të veçantë HttpSessionState. Kur punoni në një kontrollues, mund të përdorni veçorinë HttpContext.Session. Puna me sesionin është shumë e thjeshtë, si me çdo NameValueCollection:

    Session["username"] = Kërkesë.Forma["username"]; bool isSessionNew = Session.IsNewSession; string sessionId = Session.SessionID;

    Në këtë pjesë të kodit, ne shkruajmë emrin e përdoruesit në gjendjen e sesionit. Ne e marrim këtë emër nga forma html që ai na dërgoi. Për më tepër, përmes veçorive, do të zbulojmë nëse ky sesion sapo është krijuar, domethënë brenda kërkesës aktuale (nëse po, atëherë vlera e vetive IsNewSession do të jetë e vërtetë) dhe një identifikues unik të sesionit. Ky identifikues, pas përpunimit të kërkesës, do të shkruhet automatikisht në skedarin e sesionit (nëse jo tashmë) dhe do t'i dërgohet klientit si përgjigje.

    Në shfletuesin e klientit, mund të vëzhgoni cookie-n përkatës dhe ID-në e sesionit të tij:

    Në kërkesën tjetër nga ky klient, le të lexojmë emrin e tij të ruajtur më parë nga sesioni. Ne gjithashtu do ta mbyllim me forcë seancën. Puna me këtë klient ka përfunduar, për shembull, të gjitha të dhënat janë përpunuar dhe mallrat janë dërguar.

    String Emri i përdoruesit = Sesioni["Emri i përdoruesit"].ToString(); //përpunimi i kërkesës... Sesioni.Abandon();

    Siç mund ta shihni, puna me seancat është shumë e thjeshtë dhe e përshtatshme. Shumica e proceseve që lidhen me përpunimin e sesioneve ndodhin automatikisht në sfond. Natyrisht, zhvilluesi mund të ndërhyjë në çdo fazë të përpunimit të sesionit dhe të bëjë rregullimet e veta.

    Le të hedhim një vështrim në vetitë dhe metodat më interesante të klasës HttpSessionState që përdoren më shpesh në punën tonë:

    artikull- kthen një element të dhënash sipas indeksit të tij
    artikull- kthen një element të dhënash me çelësin e tij
    Hiq (indeks)- fshin një element të dhënash sipas indeksit të tij
    Hiq (çelësin)- fshin një element të dhënash me çelësin e tij
    Qartë()- fshin të gjitha të dhënat
    Numëroni- kthen numrin total të artikujve të të dhënave për sesionin aktual
    Braktis()- mbyllni me forcë seancën
    ID e sesionit- kthen ID-në e sesionit aktual
    IsNewSession- kthen true nëse sesioni është krijuar brenda kërkesës aktuale
    timeout- kthen numrin e minutave të lejuara ndërmjet kërkesave përpara përfundimit të seancës për shkak të një afati kohor (parazgjedhja, 20 minuta)

    Ju mund të ndryshoni cilësimet për një sesion ose në mënyrë programore në kod përmes anëtarëve të klasës HttpSessionState, ose përmes konfigurimit të aplikacionit (). Për shembull:

    Në konfigurimin e mësipërm, ne treguam se koha e seancës do të jetë 40 minuta, të dhënat e sesionit të përdoruesit do të ruhen në RAM, do të përdoren skedarët e sesionit, dhe gjithashtu kemi ndryshuar emrin standard të skedarëve të tillë në emrin tonë.

    Dhe një shënim më i rëndësishëm përsa i përket sigurisë. Kur përfundoni një sesion përdoruesi me Session.Abandon(); skedari i sesionit, i cili ruan identifikuesin e sesionit SessionId, nuk fshihet në shfletuesin e përdoruesit. Kjo do të thotë që nëse përdoruesi fillon një sesion të ri në të ardhmen e afërt pa mbyllur shfletuesin, atëherë sesionit të tij të ri do t'i caktohet i njëjti SessionId. Është e dëshirueshme që çdo sesion të ri të caktohet gjithmonë një identifikues i ri unik, për këtë duhet të fshijmë manualisht skedarin e sesionit pas mbylljes së seancës:

    Sesioni.Clear(); //pastroni sesionin Session.Abandon(); //anuloni sesionin //pastroni manualisht skedarët e skedarëve si kështu Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")); //ose shkurtoni jetëgjatësinë Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddYears(-30); //ASP.NET_SessionId është emri standard i cookie-t të sesionit, ju mund ta keni tuajin

    Kështu gjurmohet gjendja e sesionit të përdoruesit në platformën ASP.NET duke përdorur sesionet. Kjo qasje është standarde dhe rekomandohet kur është e nevojshme të ruhet informacioni rreth përdoruesit dhe të identifikohet ai midis kërkesave për serverin.

    Me ndihmën e sesionit PHP, serveri ju identifikon dhe ju lejon të kryeni veprimet e nevojshme: ndryshimin e informacionit në faqe të ndryshme web, shtimin e informacionit të ri, etj. Pasi të keni përfunduar punën tuaj në sit, ju fshini seancën aktuale duke klikuar në " Dilni»:

    Çfarë është një sesion PHP?

    Një seancë PHP është një mënyrë për të ruajtur informacionin në variablat e sesionit që mund të përdoret për të vërtetuar kundrejt faqeve të shumta të internetit. Ndryshe nga cookies, informacioni i sesionit nuk ruhet në kompjuterin e përdoruesit. Në vend të kësaj, sesioni krijon një skedar në server në një drejtori të përkohshme.

    Ky informacion, i ruajtur gjatë gjithë sesionit, është i disponueshëm për të gjitha faqet e internetit të burimit. Në server, vendndodhja e skedarit të përkohshëm përcaktohet nga parametri session.save_path në skedarin e konfigurimit php.ini.

    Kur krijohet një sesion PHP, kryhen tre veprimet e mëposhtme:

    • Kur krijohet një sesion, PHP gjeneron një identifikues unik, i cili është një varg i rastësishëm prej 32 numrash heksadecimal. ID-ja e jetës së sesionit PHP duket diçka si kjo: 9c8foj87c3jj973actop1re472e8774;
    • Serveri dërgon një cookie, të quajtur PHPSESSID, në kompjuterin e përdoruesit për të ruajtur një varg unik identifikues sesioni;
    • Serveri gjeneron një skedar në drejtorinë e përkohshme të specifikuar që përmban emrin e identifikuesit unik të sesionit me prefiksin sess_g. sess_9c8foj87c3jj973actop1re472e8774.

    Këto cilësime ndihmojnë skriptin PHP të marrë vlerat e variablave të sesionit nga skedari. Në anën e klientit, PHPSESSID përmban ID-në e sesionit. Ai konfirmon emrin e skedarit që do të kërkohet në një direktori të caktuar në anën e serverit, nga i cili variablat e sesionit mund të nxirren dhe të përdoren për verifikim.

    Përdoruesi mund ta përfundojë seancën duke shtypur butonin e daljes, i cili thërret funksionin session_destroy(). Kur përdoruesi mbyll shfletuesin, sesioni PHP mbyllet automatikisht. Përndryshe, serveri do ta përfundojë seancën pas periudhës së caktuar kohore.

    Sintaksa e sesionit në PHP

    Me autorizimin e PHP përmes një sesioni, ai krijohet duke përdorur funksionin session_start() dhe fshihet duke përdorur funksionin session_destroy(). Ndryshorja globale PHP, e njohur si $_SESSION, përdoret për të vendosur variablat e sesionit. Ju mund të rivendosni të gjitha vlerat e vendosura për variablat e sesionit duke përdorur funksionin session_unset().

    Operacionet e sesionit

    Ne do të shikojmë operacionet e mëposhtme duke përdorur një sesion PHP, si dhe shembuj të tyre.

    • Fillimi i një sesioni PHP dhe vendosja e variablave të sesionit të tij: fillon një sesion i ri PHP duke përdorur funksionin session_start(). Pasi të jetë krijuar një sesion, mund të vendosni variablat e sesionit të tij me $_SESSION. Ne kemi vendosur vlerat për variablat " ID e përdoruesit” — “php_user"Dhe" fjalëkalimin” — “tutoriale”:

    Sesionet PHP - krijimi Filloi seanca PHP dhe u vendosën variablat e sesionit!"; ?>

    Rezultati: Ekzekutimi i kodit PHP të mësipërm në server do të prodhojë mesazhin e mëposhtëm:


    • Marrja e vlerave të ndryshueshme të sesionit PHP: Ju mund të merrni vlerat e variablave që kemi vendosur gjatë sesionit të fundit të hyrjes në PHP. Kur hapim një sesion PHP në fillim të çdo faqeje ( sesioni_fillimi ()) duhet të përfshijë kodin më poshtë. Ne i marrim dhe shfaqim këto vlera duke përdorur ndryshoren globale $_SESSION:

    Sesioni PHP - marrja e vlerave
    "; echo "Fjalëkalimi është " . $_SESSION["fjalëkalimi"] . "."; ?>

    Rezultati: Kur ekzekutojmë kodin e mësipërm PHP në server, do të marrim mesazhin e mëposhtëm si rezultat. Shfaqen vlerat e variablave të sesionit që kemi vendosur më herët, pasi është krijuar sesioni PHP.


    • Përditësimi i vlerave të ndryshueshme të sesionit PHP: Gjatë një sesioni, mund të përditësoni vlerat e variablave të tij. Së pari duhet të hapim një sesion PHP në fillim të çdo faqeje ( sesioni_fillimi ()). Në kodin më poshtë, ne përditësojmë vlerat e variablave " ID e përdoruesit” — “new_php_user"Dhe" fjalëkalimin” — “arsimimi”.

    Ju mund të printoni një grup variablash të sesionit dhe vlerat e tyre duke përdorur funksionin print_r($_SESSION), siç tregohet më poshtë:

    Sesioni PHP - ndryshimi i vlerave
    "; print_r($_SESSION); ?>

    Rezultati: Kur të ekzekutojmë kodin e mësipërm PHP në server, do të marrim mesazhin e mëposhtëm. Do të japë një grup variablash të sesionit me vlerat e tyre të reja:


    • Fshirja e një sesioni PHP dhe rivendosja e të gjitha variablave të sesionit: Mund të rivendosni një sesion PHP me funksionin session_unset() dhe të fshini sesionin aktual me funksionin session_destroy():

    Sesioni PHP - fshi
    Sesioni PHP dhe të gjitha variablat e sesionit janë fshirë me sukses!

    "; ?>

    Rezultati: Kur ekzekutojmë kodin e mësipërm PHP në serverin e internetit, ai do të nxjerrë mesazhin e mëposhtëm si rezultat:


    konkluzioni

    Në këtë artikull, ne folëm për funksione të ndryshme për të punuar me seancat PHP, sintaksën e tyre. Ndryshe nga cookies, informacioni i sesionit ruhet në anën e serverit. Kjo i bën seancat PHP më të besueshme.

    Artikujt kryesorë të lidhur