Vaatame seansi kontseptsiooni (HTTP seanss, Session). Ehk teisisõnu kasutajaseanss. Miks on oluline mõista, kuidas seansid toimivad? Ja vaatame, kuidas saame seansi olekutega ASP.NET platvormil töötada.
Enne mõiste "seanss" defineerimist vaatame veidi tausta, miks üldse tekkis vajadus seansside järele, ja kaalume ühte HTTP-protokolli funktsiooni.
HTTP-protokolli üks põhiomadusi on see, et see ei kohusta serverit päringute vahel kliendi kohta teavet salvestama, st klienti tuvastama. See on nn kodakondsuseta protokoll. Ühendus kliendi ja serveri vahel katkeb kohe, kui praeguse päringu töötlemine on lõpetatud. Eeldatakse, et iga uus päring serverile on täiesti kordumatu ja sõltumatu, isegi kui see saadetakse korduvalt samast allikast.
Mis siis, kui jätaksime HTTP-protokolli olekuta olemuse ega tuvastaks kasutajat? Seansi olekuid saab hõlpsasti vältida, kui teie sait esitab staatilist (anonüümset) teavet, näiteks tekstist ja piltidest koosnevat uudisteartiklit. Selles kontekstis on täiesti ebavajalik siduda mitu taotlust ühe kasutajaga. Artikli sisu ju ei muutu kuidagi, olgu selleks siis kümme päringut ühest seadmest või kümme päringut erinevatelt inimestelt erinevatest seadmetest.
Kuid niipea, kui hakkame isikuandmeid serverisse edastama, peame kuidagi tagama, et server seostab kõik meie päringud meiega ja tuvastab tulevikus õigesti kõik meilt tulevad päringud. Kui te seda ei tee, oleme sunnitud iga uue taotluse korral vajalikud isikuandmed uuesti edastama. Näiteks sisselogimine veebisaidil isikliku konto sisestamiseks või teave, nagu nimi, tarneaadress, e-poes ostu sooritamisel.
Just sellistes olukordades, kui meil on vaja ühe kliendi taotlusi isikupärastada, kasutame seansse.
Seanss (seanss)- see on teatud ajavahemik, mille jooksul veebirakendus saab määrata kõik ühe kliendi päringud.
Kui klient esitab päringus esmakordselt isikuandmed, luuakse selle kliendi jaoks serveris uus seanss. Seansi jooksul tuvastatakse kõik selle kliendi päringud unikaalselt ja seostatakse sellega. Selle aja möödudes kaob ühendus kliendiga ning tema järgmist päringut käsitletakse täiesti unikaalsena, mis ei ole kuidagi eelmistega seotud.
Näiteks veebipoes ostu sooritades salvestatakse kasutaja isikuandmed seansi ajal, kui ta lehel navigeerib. Need on ostukorvis valitud kaubad, tarneaadress, kontaktandmed jne.
Nüüd vaatame, kuidas saame seda tehniliselt rakendada. Üldiselt on kliendiseansside haldamiseks mitmeid tehnikaid, nende arv ja realiseerimisviis sõltuvad suuresti serveris töötavast veebiplatvormist või tehnoloogiast. Selles õpetuses käsitleme järgmist.
- HTML-vormi peidetud väljad
- küpsised
- seanss (seanss, seansi olek)
Proovime neid rakendada platvormi ASP.NET abil. Vaatame lühidalt kahte esimest mehhanismi ja pöörame erilist tähelepanu kolmandale, kuna see on usaldusväärsem, mugavam ja turvalisem.
Varjatud vormiväljad
Selle lähenemisviisi põhiolemus seisneb selles, et pakume saidil navigeerimist standardsete HTML-vormide abil. Ja iga järgneva päringuga salvestame eelmise päringu andmed vormi peidetud väljadele. Näiteks:
Telli roog
}Public ActionResult Forms2() ( ViewBag.UserName = Request.Form["kasutajanimi"]; tagasta vaade(); )
@($"Tere pärastlõunast (ViewBag.UserName)! Mida te tellite?")
}Selles näites saame kasutajanime esimesel html-vormil. Järgmine kontrolleris meetodis Vormid2() leiame selle väärtuse kogust Vorm ja edastage see objekti kaudu vaatele ViewBag. See vaade genereerib uue vormi koodi ja salvestab kasutajanime peidetud väljale. Seega kantakse kasutajanime väärtus kolmandale vormile koos lisateabega - nimega välja väärtus "toidunimi". Ja nii edasi.
Vaatame selle lähenemisviisi funktsioone. Praktiliselt pole eeliseid, välja arvatud see, et seda tehnikat saab väga kiiresti rakendada. Kuid jällegi saab väga kiiresti rakendada ka teisi lähenemisviise. Kuid on mõned puudused ja üsna olulised:
Küpsised
Public ActionResult Cookies2() ( HttpCookie küpsis = new HttpCookie("kasutajanimi", HttpUtility.UrlEncode(Request.Form["kasutajanimi"])); cookie.Expires = DateTime.UtcNow.AddHours(1); Vastus.Add.(Cookies.Add. küpsis); tagasta vaade(); )
@($"Tere pärastlõunast (HttpUtility.UrlDecode(Request.Cookies["kasutajanimi"]?.Value))! Mida tellite?")
}Selle lähenemisviisi puhul ei salvesta me seansiandmeid otse vormile, vaid kasutame kliendi ja serveri vahel tavalist küpsiste mehhanismi. Kõik kasutajaandmed salvestatakse küpsistesse.
Selle lähenemisviisi valimisel jääb taas peamiseks probleemiks meie andmete turvalisus, mida me serverisse edastame - neid saab hõlpsasti asendada või varastada, see on selge tekstina. Samuti, kui kliendi brauseri privaatsusseaded keelavad saitidelt küpsiste vastuvõtmise, ei tööta see seansi säilitamise valik üldse.
Seega ei ole väga soovitatav edastada olulisi ja salajasi andmeid kasutades kahte esimest meetodit, nagu sisselogimised, paroolid, kaardinumbrid, kontonumbrid, passiandmed, elukoht jne.
Serveri seansi haldusmehhanism (session, SessionState)
Vaatame, kuidas seansimehhanism serveri ja kliendi poolel töötab.
Seansi oleku standardseadistuste korral kasutatakse nn seansi olekut ühe kliendi päringute seeria jälgimiseks. seansi küpsis. Algoritm on järgmine:
- Absoluutselt iga uue serveri päringu jaoks (olenemata sellest, kas tegemist on erinevate või samade klientidega) genereerib ASP.NET kordumatu seansi identifikaatori.
Seansi ID on juhuslikult genereeritud arv, mis on spetsiaalse algoritmi abil kodeeritud 24-kohaliseks stringiks. String koosneb väiketähtedest A kuni Z ja numbritest 0 kuni 5. Identifikaatori näide on hjnyuijl1pam3vox2h5i41in - Kui praeguse päringu ajal EI salvestata kliendi andmeid nendega edasiseks tööks, siis lõpeb selle kliendi seansi eluiga (tegelikult isegi alustamata). Sel juhul muutub varem loodud seansi identifikaator kehtetuks (kuna seda ei kasutatud). Vastuseks sellisele päringule ei saa klient midagi selle seostamiseks uue seansiga.
- Kui kliendiandmed (nt nimi, tarneaadress) on serverisse salvestatud, seob ASP.NET salvestatud andmed eelnevalt loodud seansi identifikaatoriga. Järgmisena luuakse spetsiaalne seansiküpsis ja see identifikaator salvestatakse ka sellesse. See küpsis lisatakse vastusena päringule ja salvestatakse kliendi brauserisse. See loob ühenduse kliendi ja tema isikupärastatud teabe vahel serveris. Selle kliendi jaoks on loodud uus seanss.
- Iga järgneva päringuga saadab klient küpsiste kaudu serverisse isikliku seansi identifikaatori. Server sobitab identifikaatorid ja "tunnistab" kliendi praeguse seansi jooksul.
- Kuni klient edastab oma isikliku võtme, loetakse seanss aktiivseks. Seanss võib lõppeda erinevatel põhjustel, näiteks käsitsi serveri poolel või pärast teatud määratud aja möödumist (timeout).
Liigume teooriast praktikasse. Programmeerime selle algoritmi ja vaatame, kuidas see töötab. Selleks kasutame eriklassi HttpSessionState. Kontrolleris töötades saate kasutada atribuuti HttpContext.Session. Seansiga töötamine on väga lihtne, nagu iga NameValueCollectioni puhul:
Session["kasutajanimi"] = Taotluse vorm["kasutajanimi"]; bool isSessionNew = Session.IsNewSession; string sessionId = Session.SessionID;
Selles kooditükis salvestame kasutajanime seansi olekus. Me võtame selle nime html-vormilt, mille ta meile saatis. Lisaks saame atribuutide kaudu teada, kas see seanss on just loodud, st praeguse päringu sees (kui jah, siis on atribuudi IsNewSession väärtus tõene) ja unikaalse seansi identifikaatori. See identifikaator salvestatakse pärast päringu töötlemist automaatselt seansiküpsisesse (kui seda veel pole) ja saadetakse kliendile vastusena.
Kliendi brauseris näete vastavat küpsist ja selle seansi ID-d:
Selle kliendi järgmise päringu ajal loeme selle seansist varem salvestatud nime. Samuti lõpetame seansi jõuga. Töö selle kliendiga on lõpetatud, näiteks kõik andmed on töödeldud ja kaup saadetud.
String kasutajanimi = Seanss["kasutajanimi"].ToString(); //päringu töötlemine... Session.Abandon();
Nagu näete, on seanssidega töötamine väga lihtne ja mugav. Enamik seansi töötlemisega seotud protsesse toimub taustal automaatselt. Loomulikult saab arendaja sekkuda seansi töötlemise mis tahes etapis ja teha muudatusi.
Vaatame klassi HttpSessionState kõige huvitavamaid omadusi ja meetodeid, mida töös kõige sagedamini kasutatakse:
Üksus- tagastab andmeüksuse selle indeksi järgi
Üksus- tagastab andmeüksuse selle võtme järgi
Eemalda (indeks)- kustutab andmeelemendi indeksi järgi
Eemalda (võti)- kustutab andmeelemendi selle võtmega
Tühjenda ()- kustutab kõik andmed
Count- tagastab praeguse seansi andmeüksuste koguarvu
Loobu ()- lõpetage seanss jõuga
Seansi ID- tagastab praeguse seansi identifikaatori
IsNewSession- tagastab tõene, kui seanss loodi praeguse päringu osana
Aeg maha- tagastab taotluste vahel lubatud minutite arvu enne seansi ajalõppu (vaikimisi 20 minutit)
Seansi sätteid saate muuta programmiliselt koodis klassi HttpSessionState liikmete või rakenduse konfiguratsiooni () kaudu. Näiteks:
Ülaltoodud konfiguratsioonis märkisime, et seansi ajalõpp on 40 minutit, kasutaja seansiandmed salvestatakse RAM-i, kasutatakse seansiküpsiseid ning muutsime ka sellise küpsise standardnime enda omaks.
Ja veel üks oluline märkus turvalisuse osas. Kui lõpetate kasutajaseansi kasutades Session.Abandon(); Seansiküpsist, mis salvestab seansi ID SessionId, kasutaja brauserist ei kustutata. See tähendab, et kui kasutaja alustab peagi uut seanssi ilma brauserit sulgemata, määratakse tema uuele seansile sama SessionId. Soovitatav on määrata igale uuele seansile alati uus kordumatu identifikaator, selleks peame pärast seansi sulgemist seansiküpsised käsitsi kustutama:
Seanss.Clear(); //seansi tühjendamine Session.Abandon(); //tühista seanss //tühjendage küpsised käsitsi niimoodi Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")); //või vähendage eluiga Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddYears(-30); //ASP.NET_SessionId on seansiküpsise standardnimi, teil võib olla oma nimi
Nii jälgitakse seansside abil kasutaja seansi olekut ASP.NET platvormil. See lähenemine on standardne ja seda soovitatakse kasutada siis, kui on vaja salvestada kasutaja kohta teavet ja teda tuvastada serverile esitatavate päringute vahel.
Veebiserver ei hoia kliendiga püsiühendust ning iga päringut käsitletakse uuena, eelnevatega ühenduseta.
See tähendab, et te ei saa jälgida sama külastaja päringuid ega salvestada tema jaoks muutujaid üksikute lehtede vaadete vahel. Nende kahe probleemi lahendamiseks leiutati seansid.
Tegelikult on seansid lühidalt mehhanism, mis võimaldab teil brauserit unikaalselt tuvastada ja loob selle brauseri jaoks serveris faili, kuhu salvestatakse seansimuutujad.
Ma ei kirjelda sellise mehhanismi vajadust üksikasjalikult. Need on õpikujuhtumid nagu ostukorv e-poes, autoriseerimine, aga ka mitte täiesti triviaalsed probleemid, näiteks saidi interaktiivsete osade kaitsmine rämpsposti eest.
Põhimõtteliselt on üsna lihtne teha oma seansside analoog, mis pole nii funktsionaalne kui PHP-sse sisseehitatud, kuid olemuselt sarnane. Küpsiste ja andmebaasi kohta.
Skripti taotlemisel vaatame, kas konkreetse nimega küpsis on vastu võetud. Kui küpsist pole, siis määrake see ja kirjutage andmebaasi uus rida kasutajaandmetega. Kui on küpsis, siis loeme andmed andmebaasist. Teise palvega kustutame andmebaasist vanad kirjed ja nüüd on meil valmis seansimehhanism. See pole üldse raske. Kuid on mõned nüansid, mis muudavad sisseehitatud seansimehhanismi kasutamise eelistatavamaks.
Kui lubatud on ainult esimene, siis seansi alguses (iga kõne session_start()) seatakse kliendile küpsis. Brauser tagastab selle küpsise iga järgneva päringuga õigesti ja PHP-l on seansi identifikaator. Probleemid algavad, kui brauser ei tagasta küpsiseid. Sel juhul, ilma identifikaatoriga küpsist saamata, alustab PHP alati uut seanssi ja mehhanism ei tööta.
Kui ainult teine on lubatud, siis küpsist ei seadistata. Ja see juhtubki, mille nimel tasub tegelikult kasutada sisseehitatud seansimehhanismi. Kui skript on oma töö ära teinud ja leht on täielikult moodustatud, skannib PHP kogu lehe ja lisab igale lingile ja vormile seansi identifikaatori. See näeb välja umbes selline:
Indeks muutub
Indeks
ja vormidele lisatakse peidetud väli
Ja kui klõpsate mis tahes lingil või vormis nuppu, saadab brauser päringusse meile vajaliku muutuja - seansi identifikaatori!
Arusaadavatel põhjustel lisatakse identifikaator ainult suhtelistele linkidele.
Teoreetiliselt saame küpsiste ja andmebaasi omatehtud seanssides määrata kõigile linkidele ID-ülekande käsitsi – ja siis töötavad meie enda seansid küpsistest sõltumata. Kuid kas nõustute – meeldivam on, kui keegi teine seda tööd teeb? ;-)
Vaikimisi on PHP viimastes versioonides mõlemad valikud lubatud. Kuidas PHP sellega hakkama saab? Kokk on alati eksponeeritud. Ja lingid täidetakse automaatselt ainult siis, kui PHP ei tuvastanud seansi identifikaatoriga küpsist. Kui kasutaja külastab saiti selle seansi jooksul esimest korda, asetatakse küpsis ja lingid täidetakse. Järgmise päringu korral, kui küpsiseid toetatakse, näeb PHP küpsist ja lõpetab linkide täitmise. Kui küpsised ei tööta, jätkab PHP linkidele ID õigesti lisamist ja seanss ei lähe kaotsi.
Kasutajad, kellel on küpsised lubatud, näevad pikka linki ID-ga ainult üks kord.
Pheh. ID ülekandmine on lõpetatud.
Nüüd jääb üle vaid andmefail sellega serveri poolel siduda.
PHP teeb seda meie eest. Piisab ainult kirjutamisest
session_start();
$_SESSION [ "test" ]= "Tere maailm!" ;
Ja PHP kirjutab testmuutuja selle seansiga seotud faili.
Siin on väga oluline märkus.
Massiiv $_SESSION- eriline.
Tegelikult sisaldab see muutujaid, mida tahame erinevates skriptides kättesaadavaks teha.
Muutuja seansi paigutamiseks määrake see lihtsalt massiivi elemendile $_SESSION.
Selle väärtuse saamiseks avage lihtsalt sama element. Allpool on näide.
PHP tegeleb ka prügiveoga – eemaldab aegunud failid. Nagu ka andmete kodeerimine ja hunnik muud vajalikku. Selle hoolduse tulemusena on seanssidega töötamine väga lihtne.
Siin jõuame tegelikult näiteni, kuidas seansid toimivad.
Väga väike näide:
session_start();
kaja "Olete seda lehte värskendanud". $_SESSION["loendur"]++. "üks kord.";
kaja"
värskenda";
?>
Kontrollime, kas meil on seansis loenduri muutuja, kui ei, siis loome selle väärtusega 0, seejärel kuvame selle väärtuse ja suurendame seda ühe võrra. Suurenenud väärtus kirjutatakse seansi ja järgmisel korral, kui skripti kutsutakse, on muutuja väärtus 1 jne.
Kõik on väga lihtne.
Saidi mis tahes lehtede seansimuutujatele juurdepääsu saamiseks peate iga faili, milles vajame seansse, algusesse kirjutama AINULT ÜHE (!) rea:
session_start();
Seejärel pääsete juurde massiivi $_SESSION elementidele. Näiteks volituse kontroll näeks välja umbes selline:
session_start();
if ($_SESSION [ "volitatud" ]<>
1
) {
header("Asukoht: /auth.php");
väljumine;
}
Muutujate eemaldamine seansist.
Kui teil on register_globals=off , siis lihtsalt kirjutage
unset($_SESSION [ "var" ]);
Kui mitte, siis lähedal Ma pean temaga kirjutama
session_unregister("var");
Kõige tavalisemad vead, mida PHP seanssidega töötamisel tekitab, on järgmised:
Kaks neist
Hoiatus: seansiküpsist ei saa saata – päised on juba saadetud
Hoiatus: seansi vahemälu piirajat ei saa saata – päised on juba saadetud
põhjustatud samal põhjusel, on lahendust kirjeldatud selles lõimes
Kolmandaks
Hoiatus: open(/tmp\sess_SID, O_RDWR) ebaõnnestus: real_script_path reanumbril sellist faili või kataloogi (2) ei ole(varem nägi ta välja nagu Hoiatus: seansi andmete (failide) kirjutamine ebaõnnestus. Veenduge, et sessiooni.save_path praegune säte on õige (/tmp)),
inglise keelest tõlgituna selgitab see probleemi üksikasjalikult: php.ini määratud kataloogi tee, kuhu seansifailid kirjutatakse, pole saadaval. Seda viga on kõige lihtsam parandada. Lihtsalt registreerige kataloog, mis on olemas ja mida saab kirjutada, näiteks
session.save_path = c:\windows\temp
Ja ärge unustage pärast seda Apache'i taaskäivitada.
Nagu selgub, pole inimese intelligentsusel piire ja seetõttu olen sunnitud selgitama:
teade kolmanda vea kohta (kataloogi ei leita) viib PARATAmatult kahe esimese ilmumiseni, kuna veateade väljastatakse brauserisse ja päistesse pärast seda, kui seda ei saa kasutada. Seetõttu ärge kiirustage ennatlikku järeldust otsima, vaid kirjutage kõigepealt üles õige tee!
Järgmine levinum probleem seanssidega töötamisel on registri_globals raske pärand. ÄRGE andke skriptimuutujatele nimesid, mis ühtivad massiivi $_SESSION indeksitega!
Kui register_globals=on, kirjutavad väärtused üksteist üle ja sa lähed segadusse.
Ja kui register_globals=off, kuvatakse järgmine tõrge: "Teie skript tugineb tõenäoliselt seansi kõrvalmõjule, mis eksisteeris kuni PHP 4.2.3." Kui skriptil on seansimuutuja, millel pole väärtust, ja globaalne muutuja koos sama nimi. Sellest vabanemiseks tuleb muutujad alati enne kasutamist initsialiseerida (või vähemalt nende olemasolu kontrollida) ja mitte anda globaalsetele muutujatele nimesid, mis ühtivad massiivi $_SESSION indeksidega.
Kui see ei tööta, kuid sõnumeid ei kuvata, lisage skripti algusesse kaks rida, mis vastutavad KÕIKIDE vigade kuvamise eest ekraanil - on täiesti võimalik, et vigu on, kuid te lihtsalt ei näe neid.
ini_set("kuva_vead" , 1 );
error_reporting(E_ALL);
või vaadake vigu failis error_log. Üldiselt jääb veateadete kuvamise teema sellest artiklist välja, seega veenduge, et näete neid vähemalt. Vigade leidmise kohta saate veidi rohkem lugeda sellest jaotisest.
Kui olete kindel, et vigu pole, kuid antud näide nagunii ei tööta, siis võib-olla ei luba PHP URL-i kaudu ID-d edastada, ja küpsised mingil põhjusel ei tööta.
Vaata, mis su küpsistega viga on.
Üldiselt, kui teie seansid ei tööta, proovige esmalt seansi identifikaator käsitsi edastada, st looge link ja määrake sellele identifikaator:
session_start();
if (!isset($_SESSION [ "loendur" ])) $_SESSION [ "loendur" ]= 0 ;
kaja "Olete seda lehte värskendanud". $_SESSION["loendur"]++. "üks kord.
värskenda";
?>
Siiski peaksite veenduma, et direktiiv session.use_only_cookies pole lubatud, mis takistab PHP-l seansi ID-d aktsepteerimast, kui see edastati URL-i kaudu
Kui see näide ei tööta, on probleem tühine kirjavead(pooled seansside "probleemidest" tulenevad valesti kirjutatud muutuja nimest) või liiga vanas PHP versioonis: versioonis 4.0 ilmus seansside tugi ja massiiv $_SESSION- 4.1-s (enne seda kasutati $HTTP_SESSION_VARS).
Kui see töötab, on probleem küpsistes. Jälgige, millise küpsise server brauserile seab ja kas brauser selle tagastab. Väga kasulik on otsida, vaadates HTTP-päiste vahetust brauseri ja serveri vahel.
Küpsiste toimimise selgitus jääb selle niigi liiga pika teksti piiridest välja, kuid vähemalt veenduge, et server saadaks identifikaatoriga küpsise ja brauser tagastaks selle. Ja samas kattuvad identifikaatorid omavahel =)
Küpsise seadmine peaks välja nägema selline
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6;
või kuidas
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; tee =/
(kui te ei taotle skripti juurkataloogist)
Serveri vastus peaks välja nägema
Küpsis: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6
või
Küpsis: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; b=b
kui brauser tagastab muid küpsiseid peale seansi ID.
Kui brauser küpsiseid ei tagasta, kontrollige, kas küpsised üldse töötavad.
Veenduge, et kasutataval domeenil on tavaline nimi (vähemalt ühe punktiga ja ilma keelatud tähemärkideta, nagu allkriipsud) ja tühjendage brauseri vahemälu – need on kaks peamist põhjust, miks küpsised ei pruugi töötada.
Kui siit toodud näide töötab, aga sinu enda kood mitte, siis ilmselgelt pole probleem seanssides, vaid algoritmis. Otsige üles, kuhu te muutuja kaotasite, kandke näide siit samm-sammult üle ja siluge skript.
Teine probleem võib tekkida siis, kui kasutate päise ümbersuunamist või JavaScripti navigeerimist.
Fakt on see, et PHP lisab automaatselt seansi identifikaatori ainult sellistele linkidele nagu , kuid ei tee seda päiste, JavaScripti ja metasiltide puhul.
Seetõttu peate identifikaatori käsitsi lisama, näiteks järgmiselt:
header("Asukoht: /script.php?" . session_name(). "=" . session_id());
Samuti on väga haruldane probleem ja on täiesti ebaselge, kust see pärineb, et seadistusel session.save_handler on failidest erinev väärtus. Kui see nii ei ole, parandage see.
Ohutus
Seansi turvalisus on lai teema. Seetõttu keskendun mõnele põhipunktile.
Kõige õpikum on mitte lasta identifikaatorit läbi aadressiriba. See on kirjutatud isegi failis php.ini, kuid see piirab seansside funktsionaalsust. Kui otsustate seda nõuannet järgida, ärge unustage lisaks session.use_trans_sid = 0-le ka session.use_only_cookies = 1
Soovitav on seanss siduda IP-aadressiga: nii ei saa identifikaatori varastamise korral kaabakas seda enamikul juhtudel kasutada.
Soovitatav on kasutada käskkirja session.save_path, mis võimaldab seansifailide salvestamiseks määrata oma kataloogi. See on turvalisem kui nende salvestamine serveri vaikimisi jagatud ajutisse kataloogi.
session_cache_limiter("privaatne");
peab enne seansi alustamist probleemi lahendama.
Seansside abil autoriseerimise näide
Illustreerime kõike ülaltoodut väikese näitega:
Loome faili auth.php:
if (isset($_POST [ "auth_name" ]))
{
$sql = "SELECT * FROM kasutajatest WHERE name=?s";
$rida = $db -> getRow($sql, $_POST["auth_name"]);
if ($row && password_verify ($_POST [ "auth_pass" ], $row [ "pass" ])) (
$_SESSION [ "kasutaja_id"] = $rida [ "id"];
}
header("Asukoht: http://" . $_SERVER [ "HTTP_HOST" ]. $_SERVER [ "REQUEST_URI" ]);
väljumine;
}
if (isset($_GET [ "action" ]) AND $_GET [ "action" ]== "logout" ) (
session_start();
session_destroy();
header("Asukoht: http://" . $_SERVER [ "HTTP_HOST" ]. "/" );
väljumine;
}
if (!isset($_SESSION [ "kasutaja_id" ])) (
?>
väljumine;
}
Nüüd pole vaja muud teha, kui kirjutada rida kõikidesse kaitstud skriptidesse
nõuda "auth.php" ;
See näide eeldab, et seanss on juba alanud ja ühendus andmebaasiga on loodud klassi abil turvaliseks ja mugavaks MySQL-iga töötamiseks. Samuti eeldatakse, et parool on räsitud, kasutades soovitatavat funktsiooni password_hash.
Kaitstud faili näide:
session_start();
sisaldama "safemysql.class.php" ;
$db = uus safemysql ([ "db" => "test" ]);
sisaldama "auth.php" ;
?>
saladus
Logi välja
OPS! Väga kasulikud lingid:
http://www.php.net/manual/ru/ref.session.php - uusim ja värskeim teave PHP seansi toe kohta ametlikus dokumentatsioonis ning arvukad kasutajate kommentaarid. Väga soovitatav lugemine.
http://phpclub.ru/manrus/f/ref.session.html – selle peatüki VÄGA vananenud tõlge vene keelde, Aleksander Pyramidini tõlgitud dokumentatsioonist.
http://phpclub.ru/detail/article/sessions
Artikkel haletsusväärse pealkirjaga "Tõde seanssidest". Jätab ambivalentse mulje. Alguses räägib autor VÄGA selgelt seansimehhanismist, kuid tema poolt artikli lõpuks pakutavad meetodid on täiesti ebaselged.
Dmitri Borodini õpikuartikkel saidilt
http://php.spb.ru/ EI OLE tungivalt soovitatav.
Poisid, see on kohutavalt aegunud. See ei sisalda mitte ainult faktilisi ebatäpsusi, vaid PHP seansid pole lihtsalt pikka aega töötanud.
Suur tänu Dimale selle eest, see oli esimene venekeelne artikkel seansside kohta, õppisin sellest ise, aga nüüd pean selle väljateenitud puhkama saatma.
Samuti on kahjuks aegunud ka paljud teised artiklid, mis on Internetis ja mida pole aastaid uuendatud.
Selle lehe õigeks kuvamiseks vajate JavaScripti toega brauserit.
Kasutaja autoriseerimise seansid
Sellele juurdepääsuks peate järgima linki Aktiivsed kasutajad Peatükis Haldus – Koduleht blokis Kasutajad(joonis 2); link Aktiivsed kasutajad Peatükis Administreerimine – Süsteem – Litsentsid järjekorras Konkurentsivõimelised litsentsid(Joonis 3) - see valik on võimalik ainult siis, kui ELMA süsteem kasutabkonkurentsivõimeliste litsentside tüüp ; nupule vajutades Aktiivsed kasutajad Peatükis Administreerimine – kasutajad(joonis 4).
Riis. 2. Jaotis "Haldamine - Kasutajad". Aktiivsete kasutajate nupp
Riis. 3. Jaotis "Haldamine - Süsteem - Litsentsid". Aktiivsete kasutajate link
Riis. 4. Jaotis "Haldamine - Avaleht". Aktiivsete kasutajate link
Kasutajanimi– see väli sisaldab täisnime. kasutaja ELMA süsteemis. Kasutaja nime kõrval olev nupp võimaldab katkestada (vastavast kasutajast välja logida) ja eemaldada nimekirjast info selle kasutaja kõigi seansside kohta.
IP-aadress– see väli sisaldab selle kasutaja IP-aadressi, kellelt süsteemi autoriseerimine teostati. Kui ELMA veebifarmi kasutatakse tööks, kuvatakse iga aktiivse kasutaja kohta nende tegelikud IP-aadressid.
IP-aadressi kõrval olev nupp võimaldab vastava seansi lõpetada ja selle kohta info loendist eemaldada.
IP-aadressi kõrval olev ikoon tähendab, et praegune kasutaja on hetkel süsteemis volitatud. Kui kasutaja viimasest vastusest on möödunud teatud aeg, aktiivne seanss peatatakse. Peatatud seansid on tähistatud ikooniga. Ajalõpu periood, mille järel aktiivne seanss peatatakse, on määratletud jaotises Administreerimine – Süsteem – Süsteemi sätted – Turvaseaded.
Viimane vastus– sellel väljal on info kasutaja poolt süsteemis sooritatud viimase toimingu või lehelt serverisse edukalt saadetud päringu kohta (kord minutis saadetakse veebipäring brauseris avatud lehelt ELMA serverisse kontrollige ühendust ja koguge statistikat).
Kasutaja viimane toiming– see väli sisaldab teavet kasutaja viimase toimingu kohta süsteemis vormingus Kuupäev – Kellaaeg – link kasutaja viimati külastatud lehele. See link on suhteline. Täieliku lingi saamiseks peate sellele lisama serveri aadressi (joonis 5).
Riis. 5. Kasutaja viimati külastatud lehekülje lingi täieliku aadressi moodustamine
Kui kasutaja teatud aja jooksul ei tegutse, lõpetatakse praegune seanss automaatselt. Seansi salvestamise kestuse seaded on konfigureeritud jaotises
Tervitused, kallis kogukond.
Kõigepealt tahan teid tänada väga kasuliku ressursi eest. Rohkem kui korra olen siit leidnud palju huvitavaid ideid ja praktilisi nõuandeid.
Selle artikli eesmärk on tuua esile seansside kasutamise lõkse PHP-s. Loomulikult on olemas PHP dokumentatsioon ja palju näiteid ning see artikkel ei ole mõeldud täielikuks juhendiks. Selle eesmärk on paljastada mõned seanssidega töötamise nüansid ja kaitsta arendajaid tarbetu ajaraiskamise eest.
Kõige tavalisem näide seansside kasutamisest on loomulikult kasutaja autoriseerimine. Alustame kõige elementaarsemast teostusest, et seda järk-järgult uute ülesannete tekkimisel edasi arendada.
(Ruumi ja aja säästmiseks piirdume oma näidetega ainult seansifunktsioonide endiga, selle asemel, et ehitada siia täisväärtuslik testrakendus ilusa klassihierarhia, põhjaliku veakäsitluse ja muu hea kraamiga).
Funktsioon startSession() ( // Kui seanss on juba alanud, peatage täitmine ja tagastage TRUE // (parameeter session.auto_start seadete failis php.ini peab olema keelatud – vaikeväärtus) if (session_id()) return true; else return session_start(); // Märkus. Enne versiooni 5.3.0 tagastas funktsioon session_start() väärtuse TRUE, isegi kui ilmnes tõrge. // Kui kasutate versioonist 5.3.0 vanemat versiooni, tehke täiendav kontroll for session_id() // pärast session_start() ) funktsiooni kutsumist deleteSession() ( if (session_id()) ( // Kui on aktiivne seanss, kustuta seansi küpsised, setcookie(session_name(), session_id(), time( )-60*60*24); // ja hävitada seanss session_unset( ); session_destroy(); ) )
Märge: Eeldatakse, et lugejal on algteadmised PHP seansside kohta, mistõttu me ei käsitle siin funktsiooni session_start() ja session_destroy() tööpõhimõtet. Sisselogimisvormi paigutuse ja kasutaja autentimise ülesanded ei ole artikli teemaga seotud, seega jätame need ka ära. Lubage mul teile lihtsalt meelde tuletada, et kasutaja tuvastamiseks igas järgnevas päringus peame eduka sisselogimise hetkel salvestama kasutaja identifikaatori seansimuutujasse (nimega kasutajatunnus näiteks), mis on saadaval kõigis järgmistes päringutes seansi elu. Samuti on vaja rakendada meie funktsiooni startSession() tulemuse töötlemist. Kui funktsioon tagastab FALSE, kuvage brauseris sisselogimisvorm. Kui funktsioon tagastas TRUE ja volitatud kasutaja identifikaatorit (meie puhul - kasutajatunnust) sisaldav seansimuutuja on olemas - kuvage volitatud kasutaja leht (vegade käsitlemise kohta leiate lisateavet 2013-06-2013-06- lisamisest). 07 seansi muutujaid käsitlevas jaotises).
Siiani on kõik selge. Küsimused algavad siis, kui peate rakendama kasutaja passiivsuse kontrolli (seansi ajalõpp), võimaldama mitmel kasutajal samaaegselt töötada ühes brauseris ja kaitsta seansse volitamata kasutamise eest. Seda arutatakse allpool.
Kasutaja passiivsuse jälgimine sisseehitatud PHP tööriistade abil
Esimene küsimus, mis sageli tekib kasutajate jaoks igasuguste konsoolide arendajate seas, on seansi automaatne lõpetamine kasutaja tegevusetuse korral. Pole midagi lihtsamat, kui seda teha PHP sisseehitatud võimaluste abil. (See valik pole eriti usaldusväärne ega paindlik, kuid kaalume seda täielikkuse huvides).Funktsioon startSession() ( // Kasutaja tegevusetuse ajalõpp (sekundites) $sessionLifetime = 300; if (session_id()) tagastab tõese; // Küpsise kasutusaja määramine ini_set("session.cookie_lifetime", $sessionLifetime); // Kui kasutaja passiivsuse ajalõpp on määratud, määrake seansi eluiga serveris // Märkus. Tootmisserveri puhul on soovitatav need parameetrid eelseadistada failis php.ini if ($sessionLifetime) ini_set("session.gc_maxlifetime", $sessionLifetime) ; if (session_start( )) ( setcookie(session_name(), session_id(), time()+$sessionLifetime); tagasta tõene; ) else return false; )
Paar täpsustust. Nagu teate, määrab PHP brauseri päringu päises saadetud küpsise nime järgi, milline seanss tuleb käivitada. Brauser omakorda saab selle küpsise serverist, kuhu funktsioon session_start() selle paigutab. Kui brauseri küpsis on aegunud, siis seda päringus ei saadeta, mis tähendab, et PHP ei saa määrata, millist seanssi alustada ja käsitleb seda uue seansi loomisena. PHP sätete parameeter session.gc_maxlifetime, mis on võrdne meie kasutaja passiivsuse ajalõpuga, määrab PHP seansi eluea ja seda kontrollib server. Seansi eluea juhtimine toimib järgmiselt (siin käsitleme seansside ajutistes failides salvestamise näidet kui PHP kõige levinumat ja vaikevalikut).
Uue seansi loomisel luuakse PHP sätete parameetris session.save_path seansi salvestuskataloogiks määratud kataloogi fail nimega sess_
Märge: Siinkohal tuleb märkida, et parameeter session.gc_maxlifetime kehtib kõikidele ühe serveri (täpsemalt ühe PHP põhiprotsessi) seanssidele. Praktikas tähendab see seda, et kui serveris töötab mitu saiti ja igaühel neist on oma kasutaja passiivsuse ajalõpp, siis selle parameetri määramine ühel saidil viib selle seadistamiseni ka teistele saitidele. Sama kehtib jagatud hostimise kohta. Selle olukorra vältimiseks kasutatakse sama serveri iga saidi jaoks eraldi seansikatalooge. Seansside kataloogi tee määramine toimub php.ini sätete failis parameetri session.save_path abil või funktsiooni ini_set() kutsumisega. Pärast seda salvestatakse iga saidi seansid eraldi kataloogidesse ja ühe saidi parameeter session.gc_maxlifetime kehtib ainult selle seansi jaoks. Me ei käsitle seda juhtumit üksikasjalikult, eriti kuna meil on paindlikum võimalus kasutaja passiivsuse jälgimiseks.
Kasutaja passiivsuse juhtimine seansimuutujate abil
Näib, et eelmine valik annab kogu oma lihtsuse (vaid paar täiendavat koodirida) kõik, mida vajame. Aga mis siis, kui mitte iga taotlust ei saa pidada kasutaja tegevuse tulemuseks? Näiteks lehel on taimer, mis esitab perioodiliselt AJAX-i päringu, et saada serverist värskendusi. Sellist taotlust ei saa käsitleda kasutaja tegevusena, mis tähendab, et seansi eluea automaatne pikendamine ei ole antud juhul õige. Kuid me teame, et PHP värskendab seansifaili muutmisaega automaatselt iga kord, kui kutsutakse funktsioon session_start(), mis tähendab, et iga päring toob kaasa seansi eluea pikenemise ja kasutaja passiivsuse ajalõpu ei esine kunagi. Lisaks võib eelmise jaotise viimane märkus parameetri session.gc_maxlifetime keerukuse kohta tunduda mõne jaoks liiga segane ja raskesti rakendatav.Selle probleemi lahendamiseks loobume sisseehitatud PHP mehhanismide kasutamisest ja võtame kasutusele mitmed uued seansimuutujad, mis võimaldavad meil ise kontrollida kasutaja passiivsuse aega.
Funktsioon startSession($isUserActivity=true) ($sessionLifetime = 300; if (session_id()) tagastab true; // Määrake küpsise kasutusiga enne brauseri sulgemist (me kontrollime kõike serveri poolel) ini_set("session. cookie_lifetime", 0) ; if (! session_start()) return false; $t = time(); if ($sessionLifetime) ( // Kui kasutaja passiivsuse ajalõpp on määratud, // kontrollige viimasest kasutaja tegevusest möödunud aega // (viimase päringu aeg, mil lastactivity seansi muutujat värskendati) if (isset($_SESSION["lastactivity"]) && $t-$_SESSION["lastactivity"] >= $sessionLifetime) ( // Kui ajast on möödunud aeg kasutaja viimane tegevus, / / on suurem kui passiivsuse ajalõpp, mis tähendab, et seanss on aegunud ja peate seansi lõpetama deleteSession(); return false; ) else ( // Kui ajalõpp ei ole veel toimunud, // ja kui taotlus tuli kasutaja tegevuse tulemusena, // värskendage viimase tegevuse muutujat praeguse ühe aja väärtusega, // pikendades sellega seansi aega teise seansi eluaja sekundi võrra, kui ($isUserActivity) $_SESSION["lastactivity"] = $t; ) ) tagasta tõene; )
Teeme kokkuvõtte. Iga päringu puhul kontrollime, kas viimasest kasutaja tegevusest kuni käesoleva hetkeni on aegumiskuupäev kätte jõudnud ja kui see on saavutatud, siis hävitame seansi ja katkestame funktsiooni täitmise, tagastades FALSE. Kui ajalõpu ei ole saavutatud ja funktsioonile edastatakse parameeter $isUserActivity väärtusega TRUE, värskendame kasutaja viimase tegevuse aega. Peame vaid helistamisskriptis määrama, kas päring on kasutaja tegevuse tulemus, ja kui mitte, kutsuda välja funktsioon startSession, mille parameetri $isUserActivity väärtuseks on seatud FALSE.
Värskendus 2013-06-07Funktsiooni sessionStart() tulemuse töötlemine
Kommentaarides märgiti, et FALSE tagastamine ei anna täielikku arusaama vea põhjusest ja see on täiesti õiglane. Ma ei avaldanud siin üksikasjalikku veakäsitlust (artikli pikkus on juba üsna suur), kuna see pole artikli teemaga otseselt seotud. Kuid arvestades kommentaare, selgitan.
Nagu näete, võib funktsioon sessionStart tagastada FALSE kahel juhul. Seanssi ei saanud käivitada mõne sisemise serveri vea tõttu (nt failis php.ini on valed seansiseaded) või on seansi eluiga aegunud. Esimesel juhul peame suunama kasutaja lehele, kus on kirjas, et serveris on probleeme, ja vorm toega ühenduse võtmiseks. Teisel juhul peame kasutaja viima sisselogimisvormile ja kuvama selles vastava teate, et seanss on aegunud. Selleks peame sisestama veakoodid ja tagastama vastava koodi FALSE asemel ning helistamismeetodis seda kontrollima ja vastavalt tegutsema.
Nüüd, isegi kui seanss serveris on endiselt olemas, hävitatakse see esmakordsel juurdepääsul, kui kasutaja tegevusetuse ajalõpp on aegunud. Ja see juhtub sõltumata sellest, milline seansi kestus on globaalsetes PHP sätetes määratud.
Märge: Mis juhtub, kui brauser suletakse ja seansinime küpsis hävitatakse automaatselt? Päring serverile järgmisel brauseri avamisel ei sisalda seansiküpsist ning server ei saa seanssi avada ja kasutaja passiivsuse ajalõpu kontrollida. Meie jaoks on see samaväärne uue seansi loomisega ega mõjuta funktsionaalsust ega turvalisust kuidagi. Tekib aga õiglane küsimus – kes siis vana seansi hävitab, kui seni oleme selle pärast aegumistähtaja möödumist hävitanud? Või jääb see nüüd igaveseks seansside kataloogis rippuma? Vanade seansside puhastamiseks PHP-s on mehhanism, mida nimetatakse prügikogumiseks. See käivitatakse serverile järgmise päringu ajal ja kustutab kõik vanad seansid seansifailide viimase muutmiskuupäeva alusel. Kuid prügikoristusmehhanism ei käivitu iga serveri poole pöördumisega. Käivitamise sageduse (või õigemini tõenäosuse) määravad kaks sätte parameetrit session.gc_probability ja session.gc_divisor. Esimese parameetri teisega jagamise tulemus on prügikogumismehhanismi käivitamise tõenäosus. Seega selleks, et seansi tühjendamise mehhanism käivitataks iga päringuga serverile, peavad need parameetrid olema seatud võrdsetele väärtustele, näiteks “1”. Selline lähenemine tagab puhta seansikataloogi, kuid on ilmselgelt serveri jaoks liiga kallis. Seetõttu on tootmissüsteemides atribuudi session.gc_divisor vaikeväärtuseks seatud 1000, mis tähendab, et prügikoristusmehhanism töötab tõenäosusega 1/1000. Kui katsetate neid seadistusi failis php.ini, võite märgata, et ülalkirjeldatud juhul, kui brauser sulgeb ja kustutab kõik küpsised, on seansside kataloogis mõneks ajaks veel vanu seansse. Kuid see ei tohiks teid muretseda, sest ... nagu juba öeldud, ei mõjuta see kuidagi meie mehhanismi ohutust.
Värskendus 2013-06-07Skriptide külmumise vältimine seansifailide lukustamise tõttu
Kommentaarides tõstatati probleem samaaegselt töötavate skriptide külmumisest seansifaili blokeerimise tõttu (kõige silmatorkavam variant on pikk küsitlus).
Alustuseks märgin, et see probleem ei sõltu otseselt serveri koormusest ega kasutajate arvust. Muidugi, mida rohkem taotlusi, seda aeglasemalt skripte täidetakse. Kuid see on kaudne sõltuvus. Probleem ilmneb ainult ühe seansi jooksul, kui server saab ühe kasutaja nimel mitu päringut (näiteks üks neist on pikk küsitlus ja ülejäänud on tavalised päringud). Iga päring proovib juurde pääseda samale seansifailile ja kui eelmine päring faili lukustust ei avanud, jääb järgmine taotlus ootama.
Seansifailide lukustamise minimeerimiseks on tungivalt soovitatav seanss sulgeda, kutsudes välja funktsiooni session_write_close() kohe pärast kõigi seansimuutujatega toimingute lõpetamist. Praktikas tähendab see, et te ei tohiks kõike seansimuutujatesse salvestada ja skripti täitmise ajal neile juurde pääseda. Ja kui teil on vaja salvestada mõned tööandmed seansimuutujatesse, lugege need kohe pärast seansi algust, salvestage need hilisemaks kasutamiseks kohalikesse muutujatesse ja sulgege seanss (see tähendab seansi sulgemist funktsiooni session_write_close abil ja mitte hävitamist seansi_destroy abil ).
Meie näites tähendab see, et kohe pärast seansi avamist, selle eluea ja volitatud kasutaja olemasolu kontrollimist peame lugema ja salvestama kõik rakenduse poolt nõutavad täiendavad seansimuutujad (kui need on olemas), seejärel sulgema seansi kõne abil. käsule session_write_close() ja jätkake skripti täitmist, olgu selleks siis pikk küsitlus või tavaline päring.
Seansside kaitsmine volitamata kasutamise eest
Kujutagem ette olukorda. Üks teie kasutajatest saab troojalase, mis röövib brauseri küpsised (millesse meie seanss on salvestatud) ja saadab selle määratud meilile. Ründaja hangib küpsise ja kasutab seda meie volitatud kasutaja nimel päringu võltsimiseks. Server võtab selle päringu edukalt vastu ja töötleb seda nii, nagu oleks see pärit volitatud kasutajalt. Kui IP-aadressi täiendavat kontrollimist ei rakendata, viib selline rünnak kasutaja konto eduka häkkimiseni koos kõigi sellest tulenevate tagajärgedega.Miks see võimalik oli? Ilmselgelt, kuna nimi ja seansi identifikaator on kogu seansi jooksul alati samad ja kui need andmed kätte saate, saate hõlpsasti teise kasutaja nimel päringuid saata (muidugi selle seansi jooksul). See ei pruugi olla kõige levinum ründetüüp, kuid teoreetiliselt tundub see üsna teostatav, eriti kui arvestada, et selline troojalane ei vaja kasutaja brauseri küpsiste röövimiseks isegi administraatoriõigusi.
Kuidas saate end selliste rünnakute eest kaitsta? Jällegi, ilmselgelt, piirates seansi identifikaatori eluiga ja muutes identifikaatorit perioodiliselt sama seansi jooksul. Samuti saame seansi nime muuta, kustutades vana täielikult ja luues uue seansi, kopeerides sinna kõik seansi muutujad vanast. Kuid see ei mõjuta lähenemisviisi olemust, nii et lihtsuse huvides piirdume ainult seansi identifikaatoriga.
On selge, et mida lühem on seansi ID eluiga, seda vähem aega on ründajal küpsiste hankimiseks ja kasutamiseks kasutaja päringu võltsimiseks. Ideaalis tuleks iga päringu jaoks kasutada uut identifikaatorit, mis vähendab kellegi teise seansi kasutamise võimalust. Kuid käsitleme üldist juhtumit, kui seansi identifikaatori regenereerimisaeg on suvaliselt määratud.
(Jätame välja selle osa koodist, millest oli juba juttu).
Funktsioon startSession($isUserActivity=true) (// Seansi identifikaatori eluiga $idLifetime = 60; ... if ($idLifetime) ( // Kui seansi identifikaatori eluiga on määratud, // kontrollige seansi algusest möödunud aega loodud või viimane regenereerimine // (viimase päringu aeg, kui seansimuutuja algusaeg värskendati) if (isset($_SESSION["algusaeg"])) (if ($t-$_SESSION["algusaeg"] >= $ idLifetime) ( // Aeg, mil seansi identifikaator on aegunud // Uue identifikaatori genereerimine session_regenerate_id(true); $_SESSION["algusaeg"] = $t; ) ) else ( // Siia jõuame, kui seanss on just lõppenud loodud // Määra seansi identifikaatori genereerimise aeg praegusele kellaajale $_SESSION["algusaeg"] = $t; ) ) return true; )
Seega määrame uue seansi loomisel (mis toimub siis, kui kasutaja edukalt sisse logib) seansimuutuja algusaeg, mis salvestab meie jaoks seansi identifikaatori viimase põlvkonna aja, väärtuse, mis on võrdne praeguse serveri ajaga. Järgmisena kontrollime iga päringu puhul, kas identifikaatori viimasest genereerimisest on möödunud piisavalt aega (idLifetime) ja kui jah, siis genereerime uue. Seega, kui identifikaatori määratud kasutusaja jooksul ei ole volitatud kasutaja küpsise saanud ründajal aega seda kasutada, loeb server võltspäringu volitatuks ja ründaja suunatakse sisselogimislehele. .
Märge: Uus seansi ID satub brauseri küpsisesse, kui kutsutakse funktsioon session_regenerate_id(), mis saadab sarnaselt funktsiooniga session_start() uue küpsise, nii et me ei pea küpsist ise uuendama.
Kui tahame oma seansse võimalikult turvaliseks muuta, piisab, kui seada identifikaatori elueaks üks või isegi eemaldada sulgudest funktsioon session_regenerate_id() ja eemaldada kõik kontrollid, mis viib identifikaatori taasloomiseni. nõuda. (Ma ei ole testinud selle lähenemisviisi mõju jõudlusele ja võin vaid öelda, et funktsioon session_regenerate_id(true) täidab sisuliselt vaid 4 toimingut: uue identifikaatori genereerimine, seansiküpsisega päise loomine, vana kustutamine ja loomine. uus seansifail).
Lüüriline kõrvalekalle: Kui troojalane osutub nii targaks, et ei saada ründajale küpsiseid, vaid korraldab küpsise saamisel koheselt eelnevalt ettevalmistatud võltspäringu saatmise, ei suuda ülalkirjeldatud meetod suure tõenäosusega sellise eest kaitsta. rünnak, kuna trooja küpsise kättesaamise ja võltspäringu saatmise vahel pole praktiliselt mingit vahet ning on suur tõenäosus, et sel hetkel ei genereerita seansi identifikaatorit uuesti.
Võimalus töötada mitme kasutaja nimel samaaegselt ühes brauseris
Viimane ülesanne, mida tahaksin kaaluda, on mitme kasutaja võimalus töötada üheaegselt ühes brauseris. See funktsioon on eriti kasulik testimisetapis, kui peate jäljendama kasutajate samaaegset tööd, ja seda on soovitatav teha oma lemmikbrauseris, mitte kasutada kogu saadaolevat arsenali või avada mitu brauseri eksemplari inkognito režiimis. .Varasemates näidetes ei määranud me selgesõnaliselt seansi nime, seega kasutati PHP vaikenime (PHPSESSID). See tähendab, et kõik meie seni loodud seansid on saatnud brauserisse küpsise PHPSESSID nime all. Kui küpsise nimi on alati sama, siis pole ilmselgelt võimalik korraldada samas brauseris kahte sama nimega seanssi. Kuid kui kasutaksime iga kasutaja jaoks oma seansi nime, oleks probleem lahendatud. Teeme nii.
Funktsioon startSession($isUserActivity=true, $prefix=null) ( ... if (session_id()) tagastab true; // Kui parameetrites edastatakse kasutaja eesliide, // määrake seda sisaldav kordumatu seansi nimi prefiks, // muidu määrake kõigi kasutajate ühine nimi (näiteks MYPROJECT) session_name("MYPROJECT".($prefix ? "_".$prefix: "")); ini_set("session.cookie_lifetime", 0); if (! session_start()) tagastab false; ... )
Nüüd jääb üle vaid veenduda, et kutsuv skript edastaks funktsioonile startSession() iga kasutaja kordumatu eesliite. Seda saab teha näiteks iga päringu GET/POST parameetrites prefiksi edastamisega või täiendava küpsise kaudu.
Järeldus
Kokkuvõtteks esitan meie PHP-seanssidega töötamise funktsioonide täieliku lõpliku koodi, sealhulgas kõik ülalkirjeldatud ülesanded.Funktsioon startSession($isUserActivity=true, $prefix=null) ( $sessionLifetime = 300; $idLifetime = 60; if (session_id()) tagastab true; session_name("MYPROJECT".($prefix ? "_".$prefix): "")); ini_set("session.cookie_lifetime", 0); if (! session_start()) return false; $t = aeg(); if ($sessionLifetime) ( if (isset($_SESSION["viimane tegevus"] ) && $t-$_SESSION["viimane tegevus"] >= $sessionLifetime) ( hävitaSession(); return false; ) else ( if ($isUserActivity) $_SESSION["lastactivity"] = $t; ) ) if ($idLifetime ) ( if (isset($_SESSION["algusaeg"])) (if ($t-$_SESSION["algusaeg"] >= $idLifetime) ( session_regenerate_id(true); $_SESSION["algusaeg"] = $t; ) ) else ( $_SESSION["algusaeg"] = $t; ) ) return true; ) funktsioon deleteSession() ( if (session_id()) ( session_unset(); setcookie(session_name(), session_id(), time() -60*60*24); session_destroy(); ) )
Loodan, et see artikkel säästab veidi aega neile, kes pole kunagi seansimehhanismi liiga sügavalt süvenenud, ja annab sellest mehhanismist piisavalt ülevaate neile, kes alles alustavad PHP-ga tutvumist.
Peatükk Aktiivsed seansid lehel "Turvaseaded" kuvatakse hiljutiste juhtumite loend juurdepääsu oma Facebooki kontole.
Iga kirje sisaldab sisselogimise kuupäeva ja kellaaega, ligikaudset asukohta, kust sisse logiti, ja kontole sisselogimiseks kasutatud seadme tüüpi. Igast kirjest paremal on ka võimalus seansi lõpetada.
Märge: asukoht on näidatud IP-aadressi alusel, millelt kontole juurde pääseti. Kui soovite teada täpseid üksikasju sisselogimise IP-aadressi kohta, hõljutage lihtsalt kursorit seansi asukoha teabe kohal.
Mida see tähendab, kui ma ei tunne sisenemispunkti ära?
Kui märkate asukoha, mida te ei tunne ära, kontrollige esmalt, et seanss poleks seotud mobiilseadmega. Mobiilseadmete abil sisselogimisel kasutatakse sageli dünaamilist IP-aadressi, mis ei kajasta kasutaja füüsilist asukohta.
Kui te asukohta ei tea ja see pole seotud mobiilseadmega sisselogimisega, võivad põhjused olla järgmised:
Facebooki rakenduse parool
Mis on rakenduse parool
Rakenduse parool on ühekordsed paroolid, mida kasutatakse programmi sisselogimiseks. Rakenduste paroolide kasutamine aitab Facebooki turvaliselt hoida.
Lisaks, kui registreerimise kinnitusteenus on rakenduse parooli kasutamisel lubatud, ei pea ootama koodi vastuvõtmist. Selle asemel võite sisselogimise kinnituse vahele jätta ja kohe sisse logida.
Rakenduse parooli saamiseks toimige järgmiselt.
Facebooki sisselogimise kinnitus
Mis on sisselogimise kinnitamise funktsioon?
Sisselogimise kinnitus on teie Facebooki konto täiendav turvafunktsioon. Sisselogimise teatis, kuid täiendava turvaprotseduuri etapiga.
Pärast sisselogimise kinnituse lubamist võidakse teil paluda sisestada sisselogimiskood alati, kui proovite oma Facebooki kontole pääseda tundmatust arvutist või mobiilseadmest.
Kui olete sisse loginud, on teil võimalus anda sellele seadmele nimi ja salvestada see oma kontole. Ühest ametlikust seadmest sisselogimisel ei pea te koodi sisestama.
Sisselogimise kinnituse funktsiooni lubamiseks toimige järgmiselt.
Märge:Sisselogimise kinnituse lubamiseks peate salvestama oma telefoninumbri oma konto andmetesse.
Kuidas blokeerida juurdepääs Facebookile ilma koodita
Kui te ei soovi, et keegi saaks teie kontole kõikjalt sisse logida, saate selle lubada Registreerimise kinnitus.
Pärast selle funktsiooni lubamist võib teil tekkida vajadus sisestada sisselogimiskood iga kord, kui proovite siseneda oma kontole tundmatust seadmest (nt arvutist või mobiiltelefonist).
Mis juhtub, kui proovin sisse logida teisest arvutist?
Kui proovite sisse logida tundmatust seadmest, kuvatakse teade, mis palub teil sisestada sisselogimiskood.
Kui olete installinud rakenduse Code Generator, avage Facebooki Androidi rakendus ja hankige kood.
Kui rakendus pole installitud, kontrollige oma telefoni turvakoodi, sisestage see ja kasutage teenust. Kui teil on turvakoodi saamisega probleeme, oodake mõni minut ja taotlege linki kasutades uut koodi Saada kood uuesti. Tõrkeotsingu kohta lisateabe saamiseks klõpsake lingil Ma ei saa koodi kätte.
Kuidas saada kinnituskoodi
Kui olete lubanud Sisselogimise kinnitus, saate iga kord, kui seda vajate, SMS-sõnumi sisselogimiskoodiga. Kui kasutate Androidi rakendust, saate alla laadida programmi Code Generator.
Kas ma pean iga kord sisselogimisel koodi sisestama?
Peale turvakoodi sisestamist ja sisselogimist tuleb arvutile või telefonile määrata koodnimi ja see salvestada (kui seadet vajad). Kui saate jätkuvalt koodiviipasid, kui logite sisse mõne salvestatud (ametliku) seadmega, peate võib-olla kohandama oma brauseri seadeid.
Kui kasutate sisselogimise kinnitamise funktsiooni, peab süsteem salvestama teie arvuti ja brauseri andmed, et need oleks järgmisel sisselogimisel äratuntav.
Mõned brauseri funktsioonid seda ei võimalda. Kui kasutate privaatset sirvimisfunktsiooni või kui teie brauser on konfigureeritud sulgemisel teie sirvimisajalugu kustutama.
