Meny
Är gratis
checka in
den huvudsakliga  /  Internet / Session. Övervakning sessioner, applikationslösenord och inträdesbekräftelse på Facebook-aktiv session

Session. Övervakning sessioner, applikationslösenord och inträdesbekräftelse på Facebook-aktiv session

Webbservern stöder inte en permanent anslutning med klienten, och varje förfrågan behandlas som ny, utan anslutning till den föregående.
Det är det omöjligt att spåra förfrågningar från samma besökare eller spara variabler för det mellan visning enskilda sidor. För att lösa dessa två uppgifter uppfanns sessioner.
Faktum är att sessionen, om i ett nötskal - det här är en mekanism som låter dig entydigt identifiera webbläsaren och skapa en fil för den här webbläsaren på servern där sessionvariablerna lagras.

Jag kommer inte att måla i detalj i en sådan mekanism. Det här är ett sådant resebyrå, som en kundvagn i e-butiken, auktorisation, liksom inte riktigt triviala problem, till exempel skyddet av interaktiva delar av platsen från spam.

I princip är det ganska lätt att göra din egen analoga sessioner, inte som funktionell som inbyggd i PHP, men liknar i huvudsak. På kakor och databas.
När du uppmanade skriptet ser vi om Cook kom med ett visst namn. Om det inte finns några cookies, lägg sedan det och skriv en ny linje till databasen med användardata. Om det finns en kock läser vi data från databasen. Vi tar bort gamla poster från basen från basen och här är vi redo för sessionsmekanismen. Det är helt enkelt. Men det finns några nyanser som föredrar användningen av den inbäddade sessionsmekanismen.

Om bara den första är aktiverad, då när du startar sessionen (varje gång du ringer session_start ()) Cook är installerad på klienten. Webbläsaren ordentligt vid varje förfrågan Denna kockavkastning och PHP har en sessionsidentifierare. Problem börjar om kockens webbläsare inte återkommer. I det här fallet, utan att ta emot cookies med en identifierare, startar PHP en ny session hela tiden, och mekanismen fungerar inte.

Om bara den andra är inkluderad, är kocken inte uppvisad. Och det händer, för det, mestadels, det är faktiskt värt att använda den inbyggda sessionsmekanismen. Efter att skriptet fungerar, och sidan är helt format, visar PHP allt och lägger till varje länk och till varje formulär för att sända sessionsidentifieraren. Det ser ut så här:
Index förvandlas till
Index
och formerna lägger till ett doldt fält

Och webbläsaren när du klickar på någon länk, eller när du klickar på knappen i formuläret, skicka oss en variabel i frågan - sessionidentifieraren!
Av uppenbara skäl läggs identifieraren endast till relativa länkar.

Teoretiskt, i våra hemlagade sessioner på cookies och databasen med dig, kan du tilldela alla referenser till ID - och då kommer våra egna sessioner att fungera oberoende av kock. Men du ser - mer trevlig när någon annan gör det här? ;-)

Standard B. senaste versionerna PHP innehåller båda alternativen. Hur kommer PHP i det här fallet? Cook är alltid uppvisad. Och länk länkar bara om RNR inte hittade en kock med en sessionidentifierare. När användaren på kort tid för den här sessionen kommer till webbplatsen, görs den av Cook, och länkarna kompletteras. Nästa gång du begär, om cookies stöds, ser PHP laga och upphör att komplettera länkarna. Om cookies inte fungerar, fortsätter PHP att ordentligt lägga till ID-länkarna, och sessionen är inte förlorad.
Användare som har cookies kommer att se en lång länk från ID bara en gång.

Fuh. Med överföringen av identifieraren färdig.
Nu är det fortfarande att binda en fil med data på serverns sida.
PHP kommer att göra det för oss. Skriv bara nog
session_start ();
$ _Session ["Test"] \u003d "Hello World!" ;
Och PHP skriver till en fil som är associerad med den här sessionen, testvariabeln.
Här är en mycket viktig anmärkning.
Array $ _Session. - Special.
I det är det faktiskt variabler som vi går för att göra tillgängliga i olika skript.
För att sätta en variabel i sessionen är det tillräckligt att tilldela det ett arrayelement $ _session.
För att få sitt värde - det är tillräckligt att ansöka om samma sak. Ett exempel kommer att vara något lägre.

Skräpavfall - Avlägsnande av föråldrade pHP-filer Också engagerade sig i sig själv. Som med kodning av data och en massa av andra nödvändiga saker. Som ett resultat av denna oro, visar arbetet med sessioner vara mycket enkla.
Så vi kommer faktiskt till exemplet på sessionens arbete.
Exemplet är mycket litet:
session_start ();

eko. "Du uppdaterade den här sidan". $ _Session ["counter"] ++. "En gång.";
echo "
uppdatering ";
?>
Vi kontrollerar om vi har en räknare variabel i sessionen, om inte, då skapar vi det med ett värde av 0, och sedan härleder vi sitt värde och ökar enheten. Det förstorade värdet spelas in i sessionen, och nästa gång du ringer på skriptet kommer variabeln att vara 1, och så vidare.
Allt är väldigt enkelt.

För att få tillgång till en variabel session på alla sidor på webbplatsen måste du bara skriva en (!) Plats i början av varje fil där vi behöver sessioner:
session_start ();
Och ytterligare få tillgång till elementen i $ _SESSION-arrayen. Till exempel kommer auktoriseringskontrollen att se ut så här:
session_start ();
om ($ _session ["auktoriserad"]<> 1 ) {
header ("Plats: /auth.php");
utgång;
}

Ta bort variabler från sessionen.
Om du har registrerat_globals \u003d av, kan du skriva
unset ($ _ session ["var"]);
Om inte, då närliggande Det är nödvändigt att skriva med det
session_unregister ("var");

De vanligaste misstag som ger PRP när man försöker arbeta med sessioner är:
Två av dem,
Varning: Kan inte session cookie - rubriker som redan skickats
Varning: Kan inte session session cache Limiter - rubriker som redan skickats
orsakad av samma anledning beskrivs lösningen i denna fak
Tredje
Varning: Öppna (/ TMP \\ sess_sid, o_rdwr) misslyckades: Ingen sådan fil eller katalog (2) i full_script_path på radnummer (Tidigare såg hon ut VARNING: Misslyckades med att skriva sessionsdata (filer). Kontrollera att den aktuella inställningen av session.Save_Path är korrekt (/ TMP)),
Om du översätter det från engelska, förklarar det i detalj problemet: den väg som anges i php.ini är inte tillgänglig för katalogen där sessionsfilerna är skrivna. Detta fel fixar det enklaste sättet. Registrera bara den katalog som finns och är tillgänglig för inspelning, till exempel,
session.save_path \u003d c: \\ windows \\ temp
Och glöm inte att starta om Apache efter det.

Som det visar sig har människans intelligens inga gränser, och därför måste jag klargöra:
Ett tredje felmeddelande (det är omöjligt att hitta en katalog) leder oundvikligen till utseendet på de två första, eftersom felmeddelandet är utmatningen till webbläsaren och efter det att det är omöjligt att använda rubriker. Därför, rusa inte för att söka för tidig slutsats, och skriv först på rätt sätt!

Nästa prevalensproblem när du arbetar med sessioner är ett tungt äldre register_globals. Ge inte skriptet variabler de namn som matchar indexen för $ _SESSION-arrayen!
När Register_Globals \u003d På, kommer värdena att skriva över varandra, och du är förvirrad.
Och när Register_Globals \u003d av ett annat fel kommer att visas: "Ditt skript är eventuellt beroende av en session-biverkning som existerade till PHP 4.2.3.", I händelse av att det finns en variabel session i skriptet och den globala variabeln med samma namn. För att bli av med det, bör du alltid initiera variabler före användning (eller åtminstone kontrollera efter existens) och inte ge globala variabla namn som matchar indexen för $ _SESSION-arrayen.

Om det inte fungerar, men inga meddelanden visas, lägg sedan till två rader i början av det skript som ansvarar för utgången av alla fel på skärmen - det är ganska möjligt att det finns fel, men du är bara don " t Se dem.
ini_set ("display_errors", 1);
error_reporting (e_all);
Eller se fel i error_log. I allmänhet är ämnet att visa felmeddelanden utöver omfattningen av den här artikeln, så se till att du åtminstone kan se dem. Lite att vända om sökningen efter fel finns i det här avsnittet.

Om du är säker på att det inte finns några fel, men ovanstående exempel fungerar inte ändå, så är det möjligt att PHP inte ingår i PCL passera genom UL, och kakor av någon anledning fungerar inte.
Se vad du har med cookies.
I allmänhet, om du "inte fungerar" sessioner, försök först att överföra identifieraren för sessionen med händerna, det vill säga, gör en länk och attribut till IT-identifieraren:
session_start ();
om (! ISSET ($ _ session ["counter"])) $ _session ["räknare"] \u003d 0;
eko. "Du uppdaterade den här sidan". $ _Session ["counter"] ++. "En gång.

uppdatering ";
?>
Det bör verifieras att direktivet om session.use_only_cookies inte är aktiverat, vilket förbjuder PHP att acceptera sessionsidentifieraren om den överfördes via webbadressen

Om det här exemplet inte tjänar är problemet antingen i banal typsnitt (Halv "problem" med sessioner kommer från ett felaktigt skriftligt variabelt namn), eller också gammal version PHP: Stöd för sessioner uppträdde i version 4.0, och en array $ _Session. - i 4,1 (före det som användes $ Http_session_vars).
Om det fungerar är problemet i cookies. Spårning - Vad en massa sätts av servern i webbläsaren, om webbläsaren returnerar den. Sökningen är mycket hjälpsam och tittar genom att titta på utbytet av http-rubriker mellan webbläsaren och servern.
Förklaringen av kockens arbete går utöver omfattningen av denna och så för stor text, men se åtminstone att kockens server med identifieraren skickar, och webbläsaren återvänder. Och samtidigt sammanfaller identifierare med varandra \u003d)
Installera cookies ska se ut
Set-cookie: PHPSESSID \u003d PRLGDFBVLG5FBSBSHCH6HJ0CQ6;
eller hur
Set-cookie: PHPSESSID \u003d PRLGDFBVLG5FBSBSHCH6HJ0CQ6; väg \u003d /
(Om du begär ett skript inte från rotkatalogen)
Server svar ska se ut
Cookie: PHPSESSID \u003d PRLGDFBVLG5FBSBSHCH6HJ0CQ6
eller
Cookie: PHPSESSID \u003d PRLGDFBVLG5FBSBSHCH6HJ0CQ6; B \u003d B.
Om webbläsaren returnerar andra cookies, utom sessionsidentifieraren.

Om bukettbläddraren inte returnerar - kontrollera om cookies fungerar alls.
Se till att domänen som du överklagar är att ha ett normalt namn (där det finns minst en punkt och inte innehåller förbjudna tecken, som understrykning) och rengör webbläsarens cache - det här är två huvudorsaker till cookies kanske inte fungerar .

Om ett exempel fungerar härifrån, och din egen kod är inte, är problemet uppenbarligen inte i sessioner, men i algoritmen. Leta efter var du förlorat variabeln, över stegen uthärdar ett exempel härifrån, felsöka ditt skript.

Ett annat problem kan uppstå om du använder omdirigering via rubrik eller navigering med JavaScript.
Faktum är att RNR automatiskt lägger till sessionidentifieraren endast till referenserna av arten Men gör det inte för header-s, javascript, metataggar.
Därför måste du lägga till identifieraren med dina händer, till exempel enligt följande:
header ("Plats: /script.php?" Session_name (). "\u003d". Session_id ());

Också, mycket sällsynt och helt oförståelig, från där det framgår av problemet är att sessionen.Save_Handler-inställningen har ett annat värde än filer. Om det inte är så korrekt.

Säkerhet
Säkerhetssessioner - ämnet är omfattande. Därför kommer jag att stanna vid flera huvudpunkter.
Den mest värden - inte att överföra en identifierare genom adresslinje. Detta är skrivet även i php.ini, men det begränsar sessionens funktionalitet. Om du bestämmer dig för att följa detta råd, förutom session.use_trans_sid \u003d 0 glöm inte att session.use_only_cookies \u003d 1
Det är lämpligt att binda sessionen till IP-adressen: På så sätt, om identifieraren är stulen, kommer skurken fortfarande inte att kunna använda dem i de flesta fall.
Det rekommenderas att du använder direktivet om session.save_path, för att ange din egen katalog för att spara sessionsfiler. Detta är säkrare än när de lagras i den allmänna tillfälliga katalogen på standardservern.

Ytterligare information:

  • Förutom kock skickar sessionsmekanismen också rubrikerna som förbjuder sidor caching (samma cachegränsare). För HTML är det korrekt och nödvändigt. Men när du försöker ge ett skript som verifierar auktorisation, skicka filen, så går Internet Explorer att ladda ner den. Det är på grund av denna rubrik. Ring upp
    session_cache_limiter ("privat");
    Innan början av sessionen ska lösa problemet.
  • Som det verkar konstigt, men i arrayen $ _Session. Kan inte använda numeriska index - $ _Session [1], $ _session ["10"] - Kännetecken kommer inte att fungera.
  • Någonstans mellan versionerna 4.2 och 5.0 var det omöjligt att installera session.use_trans_sid med iNI_SET () . Börjar med 5,0, kan du redan igen.
  • Före version 4.3.3. cook PHP. Jag skickade bara ett gäng om när sessionen startar i frågan, fanns det ingen identifierare. Nu skickas kocken varje gång samtal. session_start ()

    Exempel på godkännande med sessioner
    Vi kommer att illustrera allt som väljs av ett litet exempel:
    Skapa en fil auth.php:
    om (Isset ($ _ Post ["auth_name"]))
    {
    $ Sql \u200b\u200b\u003d. "Välj * från användare där namn \u003d? S";
    $ Row \u003d $ dB -\u003e Gettrow ($ SQL, $ _Post ["Auth_Name"]);
    Om ($ Row && Lösenord_Verify ($ _Post ["Auth_Pass"], $ Row ["Pass"])) (
    $ _Session ["user_id"] \u003d $ row ["id"];
    }
    header ("Plats: http: //". $ _Server ["http_host"]. $ _Server ["Request_uri"]);
    utgång;
    }

    om (ISSET ($ _ Hämta ["action"]) och $ _GET ["Action"] \u003d\u003d "Logout") (
    session_start ();
    session_destroy ();
    header ("Plats: http: //". $ _Server ["http_host"]. "/");
    utgång;
    }

    om (! isset ($ _ session ["user_id"])) (
    ?>








    utgång;
    }

    Nu är det tillräckligt att skriva i alla skyddade skript
    kräver "auth.php";
    I det här exemplet antas att sessionen redan har startat och anslutningen till databasen skapas med hjälp av en klass för säkert och bekvämt arbete med MySQL. Det antas också att lösenordet är hasiserat med hjälp av den rekommenderade funktionen av Password_Hash.
    Exempel på en skyddad fil:

    session_start ();
    inkludera "Safemysql.class.php";
    $ dB \u003d NEW SAFEMYSQL (["dB" \u003d\u003e "TEST"]);
    inkludera "auth.php";
    ?>
    hemlighet.

    logga ut.

    Ops! Mycket användbara länkar:
    http://www.php.net/manual/ru/ref.session.php är den senaste och senaste informationen om stöd av sessioner i PHP i officiell dokumentation, plus många användarkommentarer. Det rekommenderas starkt för läsning.
    http://phpclub.ru/manrus/f/ref.session.html är en mycket föråldrad översättning av detta kapitel till ryska, från dokumentationen i översättningen av Alexander Pyramidin.
    http://phpclub.ru/detail/article/sessions
    Artikel med den patetiska titeln "sant på sessioner". Dubbel intryck löv. Inledningsvis talar författaren mycket prisvärt om sessionsmekanismen, men de metoder som han föreslår i slutet av artikeln är helt leriga.

    Chrestoment artikel Dmitry borodin från platsen
    http://php.spb.ru/ är brådskande rekommenderas inte.
    Killar, hon är fruktansvärt föråldrad. Det räcker inte att det finns faktiska felaktigheter i det, så med sessioner i PHP under en lång tid fungerar de helt enkelt.
    Tack så mycket för henne, det var den första artikeln om sessioner på ryska, jag studerade själv på det, men nu är det nödvändigt att skicka det till en välförtjänt vila.
    Också, föråldrade tyvärr, och många andra artiklar som ligger på Internet och inte förnyas efter år.

    • Låt oss titta på en sådan sak som en session (HTTP-session, session). Eller annorlunda, en användarsession. Varför det är viktigt att förstå mekanismen för sessioner. Och låt oss se hur du kan arbeta med sessionstillstånd på ASP.NET-plattformen.

    Innan vi ger definitionen av termen "session", låt oss titta på förhistoria lite, varför gjorde behovet av sessioner, överväga ett kännetecken i HTTP-protokollet.

    En av de viktigaste funktionerna i HTTP-protokollet är att det inte förpliktar servern att spara klientinformationen mellan förfrågningar, det vill säga identifiera klienten. Detta är det så kallade statslösa protokollet. Förhållandet mellan klienten och servern slutar så snart behandlingen av den aktuella frågan är klar. Varje ny begäran till servern är avsedd som helt unik och oberoende, även om den har skickats igen från samma källa.

    Vad händer om du lämnar den högsta delen av HTTP-protokollet och inte identifiera användaren? Utan en sessionstillstånd kan du enkelt göra, om din webbplats är representerad av statisk (DIMEMANDABLE) information, till exempel en nyhetsartikel som består av text och bilder. I ett sådant sammanhang är det absolut valfritt att associera flera förfrågningar med en användare. När allt kommer omkring kommer inte innehållet i artikeln att förändras på något sätt, oavsett tio förfrågningar från en enhet eller tio förfrågningar från olika personer från olika enheter.

    Men så snart vi ska överföra personlig information till servern måste vi på något sätt göra att servern associerar alla våra önskemål från oss, och i framtiden definierade det alla förfrågningar från oss. Om detta inte är gjort, kommer vi med varje ny begäran att tvingas återge de nödvändiga personuppgifterna. Till exempel logga in för att komma in personområde På webbplatsen, eller sådan information som namn, leveransadress, när du köper i nätbutiken.

    Detta är bara i sådana situationer när du behöver personifiera förfrågningar från en klient, vi kommer att använda sessioner.

    Session (session) - Det här är en viss längd, inom vilken webbapplikationen kan definiera alla förfrågningar från en klient.

    När en klient först sänder personuppgifter i frågan, skapas en ny session på servern för den här klienten. Under sessionens livslängd kommer alla förfrågningar från denna klient att erkännas entydigt och förknippas med det. Efter den här tiden kommer kommunikationen med kunden att gå vilse, och nästa begäran från den kommer att behandlas som helt unik, på något sätt i samband med den föregående.

    Till exempel, när man köper i webbutiken sparas användarens personuppgifter i sessionen medan han reser genom webbplatsen. Dessa är utvalda produkter i korgen, leveransadress, kontaktuppgifter, och så vidare.

    Låt oss nu se hur det här kan implementera tekniskt. I allmänhet finns det flera tekniker för att hantera kundens sessioner, deras antal och metod för implementering beror i stor utsträckning på webbplattformen eller tekniken, som fungerar på servern. I den här lektionen anser vi följande:

    1. dolda fält på HTML (dolda formulärfält)
    2. cookies (cookies)
    3. session (session, session stat)

    Låt oss försöka implementera dem med ASP.NET-plattformen. Låt oss kortfattat överväga de två första mekanismerna, och särskild uppmärksamhet kommer att betalas till den tredje, som en mer tillförlitlig, bekväm och säker.

    Dolda fält på HTML (dolda formulärfält)

    Kärnan i detta tillvägagångssätt är att vi tillhandahåller navigering via webbplatsen med standard HTML-formulär. Och med varje nästa förfrågan behåller vi data från den föregående i de dolda fälten på formuläret. Till exempel:

    @Using (html.beginform ("forms2", "hem", formmetod.post)) (

    Orderrätter

    }

    Offentliga ActionResult Forms2 () (Viewbag.username \u003d Request.form ["Användarnamn"]; Returvy ();)

    @Using (html.beginform ("forms3", "hem", formmetod.post)) (

    @ ($ "Good Afternoon (Viewbag.username)! Vad kommer du att beställa?")

    }

    I det här exemplet får vi användarnamnet i den första HTML-formen. Nästa i styrenheten i metoden Forms2 () Vi tar bort detta värde från samlingen Form och sända till representationen genom objektet Viewbag.. I denna uppfattning genereras koden ny form Och i det dolda fältet sparas användarnamnet. Således kommer värdet av användarnamnet att överföras på den tredje formen tillsammans med för mer information - Fältvärde som heter "FoodName". Etc.

    Låt oss överväga funktionerna i detta tillvägagångssätt. Det finns praktiskt taget inga fördelar, förutom att denna teknik kan implementeras mycket snabbt. Men igen kan andra tillvägagångssätt också implementeras mycket snabbt. Men det finns minus, och ganska viktigt:


    Cookies (cookies)

    Offentliga ActionResult Cookies2 () (HttpCookie Cookie \u003d Ny HttpCookie ("Användarnamn", httpputility.urlencode (Request.form ["Användarnamn"]); cookie.expires \u003d DateTime.utcow.Addhours (1); Response.Cookies.add (1); svar. Cookie); returvy ();)

    @Using (html.beginform ("cookies3", "hem", formmetod.post)) (

    @ ($ "God eftermiddag (httputility.urldecode (Request.Cookies [" användarnamn "]?. Värde))! Vad kommer du att beställa?")

    }

    I detta tillvägagångssätt Vi lagrar inte sessionsdata direkt på formuläret, istället använder den vanliga arbetsboken mellan klienten och servern. I cookies och lagrade alla användardata.

    När detta tillvägagångssätt väljs, är det huvudsakliga säkerhetsproblemet fortfarande säkerheten för våra data, som vi passerar till servern - de är lätta att byta ut eller stjäla, de ligger i öppna video. Om klientbrowser sekretessinställningar kopplas från webbplatser från webbplatser, kommer det här alternativet inte att fungera alls.

    Således är det extremt rekommenderat att sända viktiga och hemliga data till de två första sätten, såsom inloggningar, lösenord, kortnummer, konton, passdata, bostadsort etc.

    Servermekanism (Session, SessionState)

    Vi kommer att analysera hur sessionsmekanismen fungerar från serverns sida och från klienten.

    För standardinställningar Sessionsstatusoperationer för att spåra en serie frågor från en klient används av den så kallade. Session cookie. Algoritmen är följande:

    1. Absolut för varje ny begäran till servern (oavsett, olika klienter eller ett) ASP.NET genererar en unik sessionidentifierare.
      Sessionsidentifieraren är ett slumpmässigt genererat nummer som är kodat med en speciell algoritm i en sträng med en längd av 24 tecken. Strängen består av bokstäver från A till Z i små bokstäver, såväl som siffror från 0 till 5. Exempel Identifierare - Hjnyuijl1Pam3vox2H5i41in
    2. Om klientdata under den aktuella förfrågan inte sparas för att ytterligare arbeta med det, slutar den här klientens livslängd (faktiskt utan att starta). Samtidigt blir den tidigare genererade sessionsidentifieraren ogiltig (eftersom den inte användes). Som svar på en sådan begäran får inte klienten något att associera det med en ny session.
    3. Om klientdata (till exempel namn, leveransadressen för varorna) sparas på servern, länkar ASP.NET de sparade data från den tidigare genererade sessionsidentifieraren. Följande är en speciell session cookie, och denna identifierare spelas också in i den. Denna cookie läggs till som svar på begäran och sparas i kundens webbläsare. Således skapas klientens anslutning och dess personliga information på servern. Ny session för den här klienten Skapad.
    4. Varje gång nästa fråga skickar klienten en personlig sessionidentifierare till servern genom cookies. Servern jämför identifierarna och "känner igen" kunden som en del av den aktuella sessionen.
    5. Så länge som kunden förmedlar sin personliga nyckel anses sessionen vara aktiv. Sessionen kan sluta av olika skäl, till exempel manuellt på serverns sida eller efter en viss tid (timeout).

    Från teorin vänder vi oss till. Låt oss programmera den här algoritmen och se hur det utförs. För att göra detta, använd den speciella HTTPSessionState-klassen. När du arbetar i kontrollenheten kan du använda egenskapen httpcontext.session. Att arbeta med sessionen är mycket enkel, som med någon namevaluecollection:

    SESSION ["Användarnamn"] \u003d Request.form ["Användarnamn"]; Bool issessionNew \u003d session.isnewescession; String sessionID \u003d session.sessional;

    I det här avsnittet i koden skriver vi användarnamnet för användaren till sessionsstatus. Vi tar det här namnet från HTML-formuläret som han skickade oss. Dessutom, genom fastigheterna, lär vi oss om den här sessionen just har skapats, det vill säga, som en del av den nuvarande begäran (om så är fallet, kommer värdet av egenskapen att vara lika med sant) och den unika sessionsidentifieraren. Denna identifierare efter bearbetningen kommer frågan automatiskt att spelas in i sessionskakor (om inte än) och skickas till kundsvaret.

    I kundens webbläsare kan du observera lämpliga cookies och identifieraren för dess session:

    I processen med nästa fråga från den här klienten, låt oss läsa sitt tidigare sparade namn från sessionen. Också med våld fullbordad session. Att arbeta med den här klienten är slutförd, till exempel, har alla data bearbetats och produkten skickas.

    String användarnamn \u003d session ["användarnamn"]. ToString (); // begäran bearbetning ... session.Abandon ();

    Som det kan ses är det mycket enkelt och bekvämt att arbeta med sessioner. De flesta processer relaterade till behandlingen av sessionen sker automatiskt i bakgrunden. Naturligtvis kan utvecklaren ingripa vid vilket stadium av sessionen bearbetning och göra sina justeringar.

    Låt oss titta på de mest intressanta egenskaperna och metoderna för HTTPSessionState-klassen, som oftast används i arbetet:

    Artikel. - Returnerar dataobjektet på sitt index
    Artikel. - Returnerar dataelementet med sin nyckel
    Ta bort (index) - Tar bort dataobjektet på sitt index
    Ta bort (tangent) - Avlägsnar dataelementet med sin nyckel
    Klar () - Tar bort alla data
    Räkna - Returnerar det totala antalet dataobjekt för den aktuella sessionen.
    Överge () - tvingligt slutföra sessionen
    SessionID. - Returnerar den aktuella sessionsidentifieraren
    IsNewsession. - Returnerar sant om sessionen skapades som en del av den aktuella förfrågan
    Paus. - Returnerar antalet minuter tillåtna mellan förfrågningar innan sessionen kommer att slutföras på grund av timeout (standard, 20 minuter)

    Du kan ändra inställningarna för sessionen, antingen programmerat i kod via HTTPSessionState-klassmedlemmar eller via en applikationskonfiguration (). Till exempel:

    I konfigurationen ovan angav vi att sessionens timeout kommer att vara 40 minuter, kommer användarens sessionsdata att lagras i slumpmässigt åtkomstminneSessionskakor kommer att användas, även ändrade standardnamnet på sådana kakor på egen hand.

    Och en viktigare säkerhetsanmärkning. När du slutför användarens session av session.Abandon (); SessionID Session Cooking Identifier, raderas inte i användarens webbläsare. Det innebär att om användaren startar en ny session inom en snar framtid, utan att stänga webbläsaren, kommer hans nya session att tilldelas samma sessionID. Företrädesvis tilldelar varje ny session alltid en ny unik identifierare, för detta måste vi manuellt radera sessionskakor efter avslutad session:

    Session.clear (); // Rengör sessionen.Abandandon () // Vi avbryter sessionen // manuellt rengör kakorna som resultatet.Cookies.Add (New HttpCookie ("Asp.net_sessionid", "")); // eller minska livstiden för svaret. Kookies ["asp.net_sessionid"]. löper ut \u003d DateTime.Now.Addyears (-30); //Asp.net_sessionid är standardnamnet på session cookies, du kan ha din egen

    På så sätt spårar du statusen för användarsessionen på ASP.NET-plattformen, med hjälp av sessioner. Detta tillvägagångssätt är standard och rekommenderas för användning när du behöver spara användarinformationen och identifiera den mellan förfrågningarna till servern.

    Hälsningar, respekterad gemenskap.

    Först och främst vill jag tacka en mycket användbar resurs. Mer än en gång hittade många intressanta idéer och praktiska råd här.

    Syftet med denna artikel är att markera undervattensstenen av användningen av sessioner i PHP. Naturligtvis finns det en dokumentation om PHP och många exempel, och den här artikeln låtsas inte full guide. Hon är utformad för att avslöja några nyanser av arbete med sessioner och skydda utvecklare från onödig spendera tid.

    Det vanligaste exemplet på att använda sessioner är naturligtvis användarbehörighet. Låt oss börja med det mest grundläggande genomförandet för att konsekvent utveckla det när nya uppgifter visas.

    (För att spara utrymme och tid kommer vi att begränsa oss själva i exemplen endast av funktionerna i arbetet med sessioner, istället för att bygga en fullfjädrad testansökan här med en vacker hierarki av klasser, omfattande felbehandling och andra rätt saker) .

    Funktion Start Web (Session_Start (); // OBS: Till version 5.3.0, återvände session_start () -funktionen sant även om det är ett fel. // Om du använder en version under 5.3.0, utför ytterligare session_idkontroll ( ) // efter att ha ringt session_start ()) funktion förstörelse () (om (session_id ()) (// om det finns en aktiv session, ta bort cookies session, setcookie (session_name (), session_id (), tid () - 60 * 60 * 24); // och förstör session_unset-sessionen (); session_destroy ();))

    Notera: Det är underförstått att den grundläggande kunskapen om PHP-sessioner på läsaren har därför inte hindret för session_start () och session_destroy () inte att täcka här. Uppgifterna för layoutformuläret och användarautentiseringsformuläret refererar inte till artikelns ämne, så vi kommer också att utelämna dem. Låt mig påminna dig bara om att identifiera användaren i varje efterföljande begäran, måste vi sparas vid tidpunkten för framgångsrik inmatning i sessionsvariabeln (med till exempel användarnamnet) användar-ID, som kommer att finnas tillgängligt i alla efterföljande Begäran inom sessionen. Det är också nödvändigt att genomföra behandlingen av resultatet av vår startsession (). Om funktionen har returnerat falska - för att visa inmatningsformen i webbläsaren. Om funktionen har returnerat, och den sessionsvariabel som innehåller en auktoriserad användaridentifierare (i vårt fall - användarid), finns - för att visa en sida av en auktoriserad användare (för mer om felbehandling, se bilaga från 2013-06-07 i sektionen om session variabler).

    Medan allt är klart. Frågor Börja när det är nödvändigt att genomföra frånvaro av användaraktivitet (session timeout), aktivera samtidig arbete i en webbläsare av flera användare, samt skydda sessioner från obehörig användning. Detta kommer att diskuteras nedan.

    Kontroll av bristen på användaraktivitet med inbyggd PHP

    Den första frågan, som ofta uppstår från utvecklarna av alla slags konsoler för användare - den automatiska slutförandet av sessionen i avsaknad av aktivitet från användaren. Det finns inget lättare än att göra det med de inbyggda PHP-funktionerna. (Det här alternativet skiljer sig inte i synnerhet tillförlitlighet och flexibilitet, men överväga det för fullständigheten av bilden).

    Funktionsstöd () (// Timeout brist på användaraktivitet (i sekunder) $ sessionlifetime \u003d 300; om (session_id ()) returnera sant; // Ställ in Cookie Ini_set ("session.cookie_lifetime", $ sessionlifetime); // Om Timeout brist på användaraktivitetssats, ställ in sessionen på servern // Obs! För produktservern rekommenderas det att förhindra dessa parametrar i php.ini om ("sessionlifetime) ini_set (" session.gc_maxlifetime ", $ sessionlifetime); om (session_start ()) (setCookie (session_name (), session_id (), tid () + $ sessionlifetime); returnera sant;) Returnera falskt;)

    Några förklaringar. Som du vet bestämmer PHP vilken en session du behöver köra, med namnet Cook, som sänds av webbläsaren i begäranrubriken. Webbläsaren tar i sin tur denna cookie från servern där dess session_start () funktionsplatser. Om livslängden för cookies i webbläsaren har löpt ut, kommer den inte att överföras i frågan, vilket innebär att PHP inte kommer att kunna bestämma vilken session som ska lanseras, och det är konsekvent som att skapa en ny session. Parameter pHP-inställningar session.gc_maxlifetime, som är inställd på vår tidsavbrott av bristen på användaraktivitet, sätter livslängden för PHP-sessionen och styrs av servern. Det fungerar kontroll över sessionens livslängd enligt följande (det finns ett exempel på en sessionslagring i temporära filer som det vanligaste och standardalternativet i PHP).

    Vid tidpunkten för att skapa en ny session i katalogen som är installerad som en katalog för lagring av sessioner i PHP-session.Save_Path-inställningsparametern, skapas den fil som heter Sess_. var - Session Identifier. Vid varje förfrågan uppdaterar PHP i varje förfrågan, vid tidpunkten för lanseringen av den redan befintliga sessionen, ändringstiden för den här filen. Således kan i varje nästa PHP-fråga, med skillnad mellan den aktuella tiden och tiden för den sista modifieringen av sessionfilen, avgöra om sessionen är aktiv, eller dess livstid har redan löpt ut. (Avlägsningsmekanismen för gamla sessionfiler beaktas närmare i nästa avsnitt).

    Notera: Det bör noteras här att parametern session.gc_maxlifetime är giltig för alla sessioner inom en server (mer exakt, inom en huvud pHP-process). I praktiken innebär det att om det finns flera webbplatser på servern, och var och en har sin egen timeout av bristen på användaraktivitet, installerar den här parametern på en av platserna och för andra webbplatser. Detsamma gäller den delade värden. För att undvika en sådan situation används separata sessionskataloger för varje webbplats inom en enda server. Ställa in sökvägen till sessionskatalogen är tillverkad med parametern session.save_path i php.ini-inställningsfilen, eller genom att ringa in-funktionen INI_SET (). Efter denna session på varje sida lagras i separata kataloger, och parametern session.gc_maxlifetime installerad på en av platserna kommer endast att vara giltig vid sin session. Vi kommer inte att överväga detta fall i detalj, särskilt eftersom vi har en mer flexibel version av frånvaron av användaraktivitet.

    Kontroll av bristen på användaraktivitet med hjälp av sessionvariabler

    Det verkar, det föregående alternativet med all sin enkelhet (bara ett par ytterligare kodlinjer) ger allt vi behöver. Men vad om inte varje förfrågan kan betraktas som ett resultat av användaraktivitet? Till exempel är en timer inställd på sidan, som regelbundet utför AJAX-förfrågan för att få uppdateringar från servern. En sådan begäran kan inte betraktas som användaraktivitet, vilket innebär att den automatiska förlängningen av sessionens livslängd inte är korrekt i det här fallet. Men vi vet att PHP uppdaterar den session fil modifieringstid automatiskt varje gång session_start () -funktionen kallas, vilket innebär att någon förfrågan kommer att leda till förlängning av sessionens livstid, och bristen på användaraktivitet kommer aldrig att komma. Dessutom kan den sista anteckningen från det föregående avsnittet om parametern i session.gc_maxlifetime verka för någon för att förvirra och komplexa i genomförandet.

    För att lösa detta problem kommer vi att vägra att använda den inbyggda pHP-mekanismer Och vi introducerar flera nya sessionvariabler som gör att vi själv kan kontrollera bristen på användaraktivitet.

    Funktionsstödning ($ IsessionLifetime \u003d True) ($ sessionLifetime \u003d 300; om (session_id ()) returnera sant; // Installera Cooks livstid innan du stänger webbläsaren (du kommer att styra allt på serverns sida) Ini_set ("session.cookie_lifetime", 0); Om (! Session_start ()) returnerar falskt; $ t \u003d tid (); om ($ sessionlifetime) (// om bristen på användaraktivitet anges, // kontrollera den tid som har gått sedan den senaste användaraktiviteten // (den sista frågetiden när den senaste aktivitetssessionsvariabeln uppdaterades) om (ISSET ($ _-session ["lastaktivitet"]) && $ t - $ _ session ["lastaktivitet"]\u003e \u003d $ sessionlifetime) (// om Tiden passerade sedan den senaste användaraktiviteten, / / \u200b\u200bmer timeout brist på aktivitet, vilket innebär att sessionen har löpt ut, och du måste slutföra förstörelsen (); returnera falskt;) annars (// om timeout har ännu inte kommit, / / och om frågan kom som resultat av användarens aktivitet, // uppdatera den variabla lastaktivitetsströmmen BP Emeni, // förlängning av tiden för sessionen är fortfarande på sessionlifetime sekunder om ($ isuseractivity) $ _session ["lastaktivitet"] \u003d $ t; )) Returnera sant; )

    Sammanfatta. I varje förfrågan kontrollerar vi om timeout kommer att nås från det sista användaraktiviteten före det aktuella ögonblicket, och om det uppnås - förstör vi sessionen och avbryta funktionen, återvända falskt. Om timeout inte uppnås, och parametern $ Isuseractivity med värdet av sant - uppdatera tiden för användarens senaste aktivitet. Allt som vi måste göra är att bestämma i det uppringande skriptet om begäran är resultatet av användarens verksamhet, och om inte, ring startsekvensen med värdet av $ Isuseractivity-parametern som är lika med falska.

    Uppdatering från 2013-06-07
    Bearbeta resultatet av sessionStart () -funktionen

    Kommentarerna var inte uppmärksam på att Falskas återbetalning inte helt förstår orsaken till felet, och det är helt rättvist. Jag publicerade inte här en detaljerad behandling av fel (artikelns omfattning och är inte liten), eftersom detta inte gäller direkt för artikelns ämne. Men med tanke på kommentarer, kommer jag att klargöra.

    Som du kan se kan sessionStartfunktionen returnera falska i två fall. Eller sessionen kunde inte lanseras på grund av vissa interna serverfel (till exempel felaktiga sessionsinställningar i php.ini), eller sessionslividen löpte ut. I det första fallet måste vi överföra användaren till sidan med ett fel som det finns problem på servern och formen av hanteringsstöd. I det andra fallet måste vi översätta användaren till inmatningsformuläret och ta det lämpliga meddelandet till det att sessionstiden har löpt ut. För att göra detta måste vi skriva in felkoder och returnera motsvarande kod istället för false, och i uppringningsmetoden, kontrollera det och agera i enlighet därmed.

    Nu, även om sessionen på servern fortfarande existerar, kommer den att förstöras vid första överklagandet om tidningen av bristen på användaraktivitet har löpt ut. Och det här kommer att hända oavsett vilken tid sessionerna är installerade i de globala PHP-inställningarna.

    Notera: Vad händer om webbläsaren stängdes, och cookies med sessionsnamnet förstördes automatiskt? Begäran till servern, nästa gång du öppnar webbläsaren, kommer inte att innehålla cookies session, och servern kommer inte att kunna öppna sessionen och kontrollera bristen på användaraktivitet. För oss motsvarar det att skapa en ny session och påverkar inte funktionaliteten och säkerheten. Men det finns en rättvis fråga - och vem kommer då att förstöra den gamla sessionen, om vi fortfarande förstör det efter utgången av Taima? Eller kommer hon nu att hänga i sessionskatalogen för alltid? För att rengöra de gamla sessionerna i PHP finns det en mekanism som heter Garbage Collection. Det börjar vid tiden för nästa begäran till servern och rensar alla gamla sessioner på grundval av datumet sista ändring Session filer. Men starten på soptäckningsmekanismen uppstår inte vid varje förfrågan till servern. Frekvensen (eller snarare, sannolikheten) för uppstart bestäms av två parametrar av session.gc_probability och session.gc_divisor-inställningarna. Resultatet från uppdelningen av den första parametern till den andra och är sannolikheten för att lansera sopsamlingsmekanismen. Således, så att sessionsrengöringsmekanismen lanseras med varje förfrågan till svårare, måste dessa parametrar ställas in på lika värde, till exempel "1". Detta tillvägagångssätt garanterar renheten i sessionskatalogen, men uppenbarligen är det för överlagd för servern. I standardproduktsystemen är session.gc_divisor-värdet, lika med 1000, vilket innebär att sopsamlingsmekanismen kommer att lanseras med en sannolikhet på 1/1000. Om du experimenterar med dessa inställningar i din PHP.INI-fil kan du märka att i det fall som beskrivs ovan, när webbläsaren stänger och rensar alla dina cookies, i sessionskatalogen, är gamla sessioner fortfarande. Men det borde inte oroa dig, för Som redan nämnts påverkar det inte på något sätt säkerheten hos vår mekanism.

    Uppdatering från 2013-06-07

    Förhindra skript som hänger på grund av sessionfilblockering

    I kommentarerna tog upp frågan om att hänga samtidigt köra skript på grund av att blockera sessionsfilen (som det ljusaste alternativet - lång omröstning).

    För att börja, noterar jag att detta problem inte direkt beror på serverbelastningen eller antalet användare. Naturligtvis utförs de mer förfrågningarna, den långsammare skripten. Men det här är ett cosquidberoende. Problemet visas bara inom samma session när servern kommer flera önskemål på uppdrag av en användare (till exempel en av dem är lång omröstning, och resten är normala förfrågningar). Varje förfrågan försöker komma åt samma session-fil, och om den föregående frågan inte har låst upp filen, kommer nästa att hänga och vänta.

    För att stänga sessionsfilerna för att minimera, rekommenderas det starkt att stänga sessionen genom att ringa funktionen session_write_close () omedelbart efter det att alla åtgärder med sessiva variabler utförs. I praktiken betyder det att det inte ska lagras i sessionvariabler i rad och kontakta dem under hela skriptets utförande. Och om du behöver lagra några arbetsdata i sessionvariabler, läser du omedelbart dem när du startar sessionen, spara till lokala variabler för efterföljande användning och stäng sessionen (det betyder att du stänger sessionen med hjälp av session_write_close-funktionen och inte förstörelse använder session_destroy).

    I vårt exempel betyder det att vi omedelbart efter att ha öppnat sessionen, att kontrollera tiden för sitt liv och existens av en auktoriserad användare, måste läsa och spara alla ytterligare applikationer till sessionvariablerna (om det finns sådana), varefter det är Nära till sessionen genom att ringa session_write_close () och fortsätt körning av skriptet, oavsett om det är lång omröstning eller en vanlig fråga.

    Skydd av sessioner från obehörig användning

    Föreställ dig situationen. En av dina användare clins Troyan, som robs buketten i webbläsaren (där vår session är lagrad) och skickar den till det angivna e-postmeddelandet. Anfallaren får cookies och använder den för en falsk fråga på uppdrag av vår auktoriserade användare. Servern accepterar och behandlar och behandlar den här förfrågan, som om den kom från en auktoriserad användare. Om en ytterligare IP-adresscheck är implementerad, kommer en sådan attack att leda till ett framgångsrikt hackande användarkonto med alla efterföljande konsekvenser.

    Varför var det möjligt? Självklart, eftersom namnet och identifieraren för sessionen alltid är samma samtidigt som du får den här data, kan du enkelt skicka förfrågningar på uppdrag av en annan användare (naturligtvis inom denna sessions livstid). Kanske är det inte den vanligaste typen av attacker, men teoretiskt, allt ser ganska realiserbart, särskilt med tanke på att administratörsrättigheterna inte ens behöver en sådan trojan för att råna användarbrowser cookies.

    Hur kan jag skydda mot attacker av detta slag? Igen, självklart, begränsar livstiden för sessionsidentifieraren och regelbundet ändrar identifieraren inom en session. Vi kan också ändra sessionsnamnet, helt avlägsna det gamla och skapa en ny session genom att kopiera alla sessionsvariabler från den gamla. Men det påverkar inte kärnan i tillvägagångssättet, därför för enkelhet är det begränsat till identifieraren för sessionen.

    Det är uppenbart att ju mindre livstid för sessionsidentifieraren, desto mindre kommer att vara på angriparen att få och tillämpa cookies för falsk användarförfrågan. I det perfekta fallet måste en ny identifierare användas för varje förfrågan, vilket gör att du kan minimera möjligheten att använda någon annans session. Men vi anser det allmänna fallet när sessionsidentifierande regenereringstiden ställs in godtyckligt.

    (Sänka den del av koden som redan har beaktats).

    Funktionsstöd ($ Isuseractivity \u003d True) (// Livstid för identifieraren för sessionen $ iDlifetime \u003d 60; ... om ($ iDlifetime) (// om livslängden för sessionsidentifieraren är inställd, // Kontrollera tiden Det har gått sedan sessionen eller den senaste sessionen Regenerering // (den senaste frågeställningen när sessionen variabel starttid uppdaterades) om (ISSET ($ _ session ["StartTime"]) (om ($ t - $ _ session [ "Starttid"]\u003e \u003d $ iDlifetime) (// Time Lifestyle Session Identifier // Generera en ny session_regenerate_id identifierare (True); $ _session ["Starttid"] \u003d $ t;)) Övrigt (// Här får vi om sessionen har just skapats // Ställ in sessiovid den aktuella tiden $ _session ["Starttid"] \u003d $ t;)) returnera sant;)

    Så, när vi skapar en ny session (som inträffar vid tidpunkten för framgångsrik användarloggning), ställer vi in \u200b\u200bden starttidssessionvariabel som lagras för oss den sista generationen av sessionsidentifieraren, till värdet som är lika med servertiden. Därefter kontrollerar vi i varje förfrågan om tillräckligt med tid (Idlifetime) inte har gått sedan den sista generationen av identifieraren, och om den passerade - genererar vi en ny. Om en angripare som fick cookies av en auktoriserad användare som fick identifieraren för identifieraren av identifieraren inte har tid att använda den, kommer den falska förfrågan att betraktas av servern som en obehörig, och angriparen kommer att falla på Entry Page.

    Notera: Den nya sessionsidentifieraren går in i webbläsarkakorna när du ringer funktionen session_regenerate_id (), som skickar nya cookies, liknar funktionen Session_Start (), så vi behöver inte uppdatera kakor själv.

    Om vi \u200b\u200bvill säkra våra sessioner så mycket som möjligt är det tillräckligt att fastställa identifieringens livstids livslängd eller i allmänhet för att uthärda funktionen session_regenerate_id () för parentes och ta bort alla kontroller, vilket leder till identifieraren regenerering i varje förfrågan. (Jag kontrollerade inte effekten av ett så snabbt tillvägagångssätt, och jag kan bara säga att funktionen session_regenerate_id (True) utför i huvudsak 4 steg: generera en ny identifierare, skapa en rubrik med kocksession, radera den gamla och skapa en ny session fil).

    Lyrisk Digression: Om Troyans visar sig vara så smart att det inte kommer att skicka cookies till en angripare, och han organiserar sändningen av en förutbestämd falsk förfrågan omedelbart efter mottagandet av kock, kommer den ovan beskrivna metoden, sannolikt inte att kunna skydda mot sådana En attack, för mellan tiden för att ta emot trojanska kakor och skicka falska, kommer frågan nästan inte vara skillnad, och sannolikheten är stor att vid denna tidpunkt inte kommer att få regenerering av sessionsidentifieraren.

    Förmågan att samtidigt arbeta i en webbläsare på flera användares vägnar

    Den sista uppgiften som jag skulle vilja överväga är möjligheten att simultan arbete i en webbläsare av flera användare. Den här funktionen är speciellt användbar vid testfasen när du behöver efterlikna den samtidiga användarnas drift, och det är lämpligt att göra det i din favoritwebbläsare och inte använda hela den tillgängliga arsenalen eller öppna flera instanser av webbläsaren i "Incognito "läge.

    I våra tidigare exempel definierade vi inte namnet på sessionen, så standardnamnet i PHP används. Det innebär att alla sessioner som har skapats av oss hittills har skickat Cook-webbläsare under namnet PHPSESSID. Självklart, om tillagningsnamnet alltid är detsamma, så finns det ingen möjlighet inom en webbläsare för att organisera två sessioner med samma namn. Men om vi använde vårt eget sessionsnamn för varje användare skulle problemet lösas. Och gör det.

    Funktionsstöd ($ Isuseractivity \u003d True, $ prefix \u003d null) (... om (session_id ()) returnera sant; // om parametrarna passerar användarfixet, // Ställ in det unika sessionsnamnet, inklusive detta prefix, // Annars installera general för alla användare namn (till exempel myproject) session_name ("myProject". ($ prefix? "_." $ prefix: "")); INI_SET ("session.cookie_lifetime", 0); om (! session_start ()) Returnera falska; ...)

    Nu är det fortfarande att ta hand om att det uppringningsskript som sänds till funktionen StartSession () är ett unikt prefix för varje användare. Detta kan göras, till exempel genom transfixet till get / postparametrarna för varje förfrågan eller via ytterligare cookies.

    Slutsats

    Sammanfattningsvis kommer jag att ge fulländningskoden för våra funktioner att arbeta med sessioner php.som innehåller alla de uppgifter som diskuterats ovan.

    Funktionsstöd ($ Isuseractivity \u003d True, $ prefix \u003d null) ($ sessionlifetime \u003d 300; $ iDlifetime \u003d 60; om (session_id ()) returnera sent; session_name ("myProject". ($ Prefix? "_". $ Prefix: "" ")); INI_SET (" session.cookie_lifetime ", 0); om (! session_start ()) returnera falskt; $ t \u003d tid (); om ($ sessionlifetime) (om (ISSET ($ _ session [" lastaktivitet "]) && $ t - $ _ session [" lastaktivitet "]\u003e \u003d $ sessionlifetime) (förstörelse (); återvända falskt;) annars (om ($ isuseractivity) $ _session [" lastaktivitet "] \u003d $ t;)) om ($ iDlifetime) (om (ISSET ($ _ session ["Starttid"])) (om (om ($ t - $ _-session ["Starttime"]\u003e \u003d $ iDlifetime) (session_regenerate_id (True); $ _session ["Starttime" ] \u003d $ t;)) annars ($ _session ["Starttid"] \u003d $ t;)) returnera sant;) Funktion förstörelse () (IF_Unset (); SetCookie (Session_Name (), session_id (), Tid () -60 * 60 * 24); session_destroy ();))

    Jag hoppas att den här artikeln kommer att spara lite tid till dem som aldrig har ätit i sessionsmekanismen, och kommer att ge tillräckligt med förståelse för den här mekanismen för dem som bara börjar lära känna PHP.

    I modul Aktiv cessia Du kan se en lista med användare som arbetar med kontrollpanelen när som helst. det här ögonblicketIP-adressen från vilken användarens åtkomst och tiden som gått från det ögonblick som det sista kommandot är mottaget från den här användaren.

    Om det behövs kan du slutföra sessionen i den valda användaren.

    Modul "aktiva sessioner"

    Visa aktuell anslutningsinformation

    • Sessions-ID - Ett unikt nummer som identifierar en session med kontrollpanelen. Som standard visas informationen i tabellen i 60 minuter.
    • Användare - Användarnamnet som är anslutet till systemet är för närvarande.
    • Tillgång - Tillgångsnivå för den här användaren till kontrollpanelen (till exempel superuser, serveradministratör, användare, etc.).
    • IP-adress - En avlägsen IP-adress från vilken åtkomst är tillgänglig.
    • Förväntan - Den tid som passerade från det ögonblick som kontrollpanelen mottog det sista kommandot från användaren.
    • Aktiva förfrågningar - Antal aktiva förfrågningar.

    Slutförande av sessionen

    För att slutföra det här eller den sessionen med kontrollpanelen markerar du de önskade raderna i listan över aktiva sessioner och klickar på Slutför.

    För att förhindra oavsiktliga rader, kommer kontrollpanelen att be dig att bekräfta eller avbryta din åtgärd. Om du klickar på "OK" i bekräftelsesfönstret, kommer de valda sessionerna att slutföras.

    Om sessionen slutfördes, för vidare arbete med kontrollpanelen, måste användaren logga in igen.

    Denna blankett är inte ett överklagande att stödja.
    Vi kan inte identifiera dig och svara på ditt meddelande.

    Session (från Lat. - Sessio-möte, engelska - session) - Det här är en tid som täcker användaren på Internet från ögonblicket att öppna den första och till de sista länkarna. Det beräknas som tidsskillnaden mellan de första och slutliga förfrågningarna. Den sista sidan kan dock ses av användaren i olika tidpunkter, varav tiden mätning mellan två förfrågningar blir svårare.

    Hur är sessionen med http och cookies protokoll

    Vad en sådan session kan förklaras genom att trycka ut från HTTP-protokollet. I själva verket har detta protokoll inte ett sätt att bevara staten mellan två operationer. De., Helt enkelt, öppnar en sida, och då kommer HTTP inte att kunna fastställa att båda förfrågningarna hör till en användare. Och här kommer hjälp av en speciell spårningsmetod till hjälp - kontroll av sessioner (av våra sessioner).
    Härifrån, besvarar frågan vilken typ av session, kan vi säga att detta är ett extra logiskt objekt som främjar dataöverföring mellan sekventiella HTTP-förfrågningar från en användare.
    Cookies, som sessionen, lagra information om användaren under dess rörelse på olika sidor och förbättra protokollets funktion. Men till skillnad från den andra, där data lagras i temporära filer på servern, lagrar de dem på en användares dator i form av små fragment.

    För vilka sessioner behöver

    Användningen av sessioner blir oumbärlig när de arbetar med sådana webbplatser som forum, anslagstavlor och nätbutiker, eftersom du i det här fallet behöver spara användardata för flera sidor.

    Steg i sessionen

    All session kan delas upp i tre steg:

    • Öppningssession (när användaren börjar arbeta med en viss webbplats),
    • redovisning för variabla sessioner (när du flyttar till olika sidor),
    • slutförandet av sessionen.

    På grund av det faktum att dessa sessioner lagras på en tredje parts server är det bäst att inte hålla stora mängder information i dem, men att använda cookies.