Zasedání. Podrobný popis činnosti a vysvětlení mechanismu. Zabezpečení ID relace v organizaci PHP inurl guestbook php phpsessid

Session in PHP aneb jak se při procházení mezi stránkami webu bez větších obtíží ukládají data o uživateli nebo zákazníkovi, který vstoupil na web. Lekce je velmi důležitá. Relevantní pro vytvoření 95% stránek.

Co je relace v php

Session se používají k ukládání dočasných dat (například, že uživatel vstoupil na web) při procházení mezi stránkami stejného webu. Při používání relací se data ukládají do dočasných souborů na server.
Při vytváření internetových obchodů, fór, diskusních panelů, sociálních sítí, blogů a dalších zdrojů se nejčastěji používají relace (a také soubory cookie). Pohodlí systému relací je ukládat dočasné informace o přihlášeném uživateli / zákazníkovi, o kterých jsou data po určitou dobu v rychlém přístupu. Relace má přirozené datum vypršení platnosti - dokud se prohlížeč nezavře. Pokud zavřete pouze stránku, pak při otevření webu budou údaje o uživateli / kupujícím stále k dispozici.

Logika relace

Relace (nebo relace) je druh dočasného úložiště dat. Ihned vás varuji, že stojí za to uložit malé množství dat. Například přihlašovací jméno a heslo přihlášeného uživatele nebo jeho sériové číslo v databázi.

Ukázka práce
1. Uživatel zadá uživatelské jméno a heslo a vstoupí na web
2. Údaje s přihlašovacím jménem a heslem jsou uloženy v relaci jedné ze stránek webu:

Soubor index.php

Session_start (); // každý soubor, ve kterém chcete použít data relace, musí na začátku kódu obsahovat příkaz "start session"

$ login = "admin";
$ heslo = "projít";
$ _SESSION ["login"] = $ přihlášení; // uložte proměnnou obsahující přihlášení
$ _SESSION ["heslo"] = $ heslo; // uložte proměnnou obsahující heslo

3. Když přejdete na jinou stránku webu, budou k dispozici také tato data:

Soubor příklad.php(nebo jakákoli jiná stránka)

Opakujte „Vaše přihlášení“. $ _ SESSION [„přihlášení“]; // zobrazí „Vaše přihlášení je admin“, přestože jsme na této stránce nezaznamenali data!
Vidíte, je to jednoduché!

4. Pokud chcete vymazat data relace, stačí:

Soubor příklad.php

Session_start (); // "znovu spusťte relaci"

Unset ($ _ SESSION ["login"]); // takto byla proměnná neregistrována nebo „zničena“
echo „Vaše přihlášení“. $ _ SESSION [„přihlášení“]; // zobrazí „Vaše přihlášení“. Protože jsme to zničili v posledním řádku, neexistují ani data.

Session_destroy (); // zničit relaci. Všechna data včetně $ _SESSION ["heslo"] jsou pryč. Na požádání se zobrazí chyba
Obecně je takový přenos podobný metodě POST, ale již nemusíte psát mnoho zbytečného kódu a všechna data přenesená ze stránky na stránku jsou uložena v dočasných souborech na serveru. Opět platí, že relace by měly obsahovat malé množství dat, takže jsou vhodné pro ukládání uživatelského jména / hesla, nákupního košíku a dalších malých objemů.

Předání hodnoty nebo pole pomocí relace PHP

V relaci můžete zapsat nejen řetězec, ale také pole dat. Nepřehánějte to s velikostí pole, protože to vše ovlivní výkon a obsazené místo na serveru.

Znovu použijeme určitou úvodní stránku index.php

Session_start ();

$ r = pole („jedna“, „dvě“, „tři“);

$ _SESSION ["arr"] = $ r;

Na stránku, kde se vše zobrazí
Data jsme uložili do relace a následujeme odkaz na jinou stránku, kde zobrazíme všechna data.

Příjemce souboru, stránka test.php kde pole otevřeme

Session_start ();
print_r ($ _ SESSION ["arr"]);
// bude výstup
/*
Pole
=> jeden
=> dva
=> tři
*/
?>
Možná budete chtít oprášit výukový program. Obecně by mělo být vše jasné.

Další funkce pro práci s relacemi

session_unregister (řetězec)- relace zapomene hodnotu zadané globální proměnné;
session_destroy ()- relace je zničena (například pokud uživatel opustil systém stisknutím tlačítka pro odhlášení);
session_set_cookie_params (int životnost [, cesta řetězce [, doména řetězce]]- pomocí této funkce můžete nastavit, jak dlouho bude relace trvat, nastavením unix_timestamp definujícím čas úmrtí relace.

Seznam funkcí pro práci s relacemi (relacemi) v php
session_cache_expire - Vrátí vypršení platnosti aktuální mezipaměti
session_cache_limiter - Získejte a / nebo nastavte aktuální limit mezipaměti
session_commit - alias pro session_write_close ()
session_decode - Dekóduje data relace z řetězce
session_destroy - zničí všechna data registrovaná pro relaci
session_encode - šifruje data aktuální relace jako řetězec
session_get_cookie_params - Získejte parametry cookie relace
session_id - získá a / nebo nastaví aktuální ID relace
session_is_registered - určuje, zda je v relaci zaregistrována proměnná
session_module_name - získá a / nebo nainstaluje modul aktuální relace
session_name - získá a / nebo nastaví název aktuální relace
session_regenerate_id - Upraví aktuální ID relace s nově vygenerovaným
session_register - registruje jednu nebo více proměnných pro aktuální relaci
session_save_path - získá a / nebo nastaví cestu k uložení aktuální relace
session_set_cookie_params - nastavuje parametry cookie relace
session_set_save_handler - nastavuje funkce ukládání relací na úrovni uživatele
session_start - inicializuje data relace
session_unregister - Zruší registraci proměnné z aktuální relace
session_unset - Uvolní všechny proměnné relace
session_write_close - zapíše data relace a konec relace

Příklady relací

Počítadlo zobrazení stránky během relace. Jasný příklad práce. Po zavření prohlížeče však odpočítávání začne znovu.

Počítadlo návštěv jedné stránky v rámci jedné relace

// Jednoduchý příklad použití relací bez cookies.
session_name ("test");
session_start ();
$ _SESSION ["count"] = @ $ _ SESSION ["count"] + 1;
?>

Čelit

V aktuální relaci s prohlížečem jste otevřeli tuto stránku
čas (s).
Chcete -li toto počítadlo resetovat, zavřete prohlížeč.
Kliknutím sem obnovíte stránku!
Při každém přechodu se počítadlo zvýší o 1)

Děkuji za pozornost! Hodně štěstí ve vašem úsilí!

Relace jsou ve skutečnosti velmi jednoduché. Musíte jen pochopit, k čemu slouží a jak jsou uspořádány. Odpovězme si nejprve na první otázku.
Možná víte, že webový server neudržuje trvalé spojení s klientem a každý požadavek je zpracován jako nový, bez komunikace s předchozími.

To znamená, že nemůžete sledovat požadavky od stejného návštěvníka, ani pro něj ukládat proměnné mezi zobrazeními jednotlivých stránek. K vyřešení těchto dvou problémů byly vynalezeny relace.
Stručně řečeno, relace jsou v kostce mechanismus, který vám umožňuje jednoznačně identifikovat prohlížeč a vytvořit soubor pro tento prohlížeč na serveru, který ukládá proměnné relace.

Nebudu podrobně popisovat potřebu takového mechanismu. Jde o případy, jako je nákupní košík v internetovém obchodě, autorizace, a také ne zcela triviální problémy, jako je například ochrana interaktivních částí webu před spamem.

V zásadě je docela snadné vytvořit si vlastní analogovou relaci, ne tak funkční jako vestavěný PHP, ale v podstatě podobnou. Na cookies a databázi.

Při požadavku na skript zjišťujeme, zda soubor cookie přišel s konkrétním názvem. Pokud žádné soubory cookie neexistují, nastavte je a do databáze zapište nový řádek s uživatelskými údaji. Pokud existují soubory cookie, pak čteme z databáze. S dalším požadavkem odstraníme staré záznamy z databáze a nyní máme připravený mechanismus relace. Není to vůbec těžké. Existují však určité nuance, díky nimž je vhodnější použít vestavěný mechanismus relace.

Nejprve musíte nějak identifikovat prohlížeč. Chcete -li to provést, musíte mu dát jedinečný identifikátor a požádat ho, aby jej přenesl s každou žádostí. Stydím se přiznat, ale když jsem se poprvé dozvěděl o relacích, myslel jsem si, že se jedná o nějaký speciální mechanismus, nový způsob komunikace mezi prohlížečem a serverem - „relace“. Že je identifikátor relace předán nějakým zvláštním způsobem. Ale zklamání bylo kruté ...

Relace používají standardní, dobře známé metody přenosu dat. Ve skutečnosti prostě neexistují žádní další.
Identifikátor je regulární proměnná. Ve výchozím nastavení je jeho název PHPSESSID.
Úkolem PHP je odeslat jej do prohlížeče a vrátit jej s dalším požadavkem. Z již zmíněné sekce FAQ je zřejmé, že proměnnou lze předat pouze dvěma způsoby: v souborech cookie nebo požadavku POST / GET.
PHP používá obě možnosti.

Za to mohou dvě nastavení v php.ini:

session.use_cookies - pokud se rovná 1, pak PHP předá identifikátor cookies, pokud 0 - pak ne.
session.use_trans_sid pokud se rovná 1, pak jej PHP předá připojením k adrese URL a formulářům, pokud 0 - pak ne.

Tyto a další parametry relace můžete změnit stejným způsobem jako ostatní nastavení PHP - v souboru php.ini, stejně jako pomocí příkazu ini_set () nebo v konfiguračních souborech webového serveru

Pokud je povolen pouze první, pak na začátku relace (při každém hovoru session_start ()) cookies jsou nastaveny pro klienta. Prohlížeč správně vrací tento soubor cookie při každém dalším požadavku a PHP má identifikátor relace. Pokud prohlížeč nevrací soubory cookie, problémy začínají. V takovém případě PHP bez přijetí souborů cookie s identifikátorem spustí novou relaci po celou dobu a mechanismus nebude fungovat.

Pokud je povolen pouze druhý, soubory cookie nejsou nastaveny. A co se stane, je, že kvůli tomu v podstatě stojí za to použít vestavěný mechanismus relace. Poté, co skript odvede svou práci a stránka je plně vytvořena, PHP vše prohlédne a ke každému odkazu a každému formuláři připojí ID relace. Vypadá to nějak takto:

Index

promění v

Index

a do formulářů se přidá skryté pole

Teoreticky v našich domácích relacích s vámi o souborech cookie a databázi můžete ručně přiřadit přenos ID všem odkazům sami - a pak naše vlastní relace budou fungovat bez ohledu na soubory cookie. Ale vidíte - je příjemnější, když tuto práci dělá někdo jiný? ;-)

V posledních verzích PHP jsou obě možnosti ve výchozím nastavení povoleny. Jak PHP v tomto případě postupuje? Kuchař je vždy vystaven. A odkazy se automaticky doplňují pouze v případě, že PHP nenašlo soubory cookie s ID relace. Když uživatel během této relace navštíví web poprvé, uloží se mu soubory cookie a přidají se odkazy. Na další žádost, pokud jsou podporovány cookies, PHP vidí cookies a zastaví vyplňování odkazů. Pokud cookies nefungují, pak PHP pokračuje v správném přidávání id do odkazů a relace není ztracena.
Uživatelé, kteří používají soubory cookie, uvidí dlouhý odkaz s ID pouze jednou.

Po dokončení přenosu identifikátoru. Nyní zbývá svázat soubor s daty na straně serveru. PHP to udělá za nás. Stačí napsat:

session_start ();
$ _SESSION ["test"] = "Ahoj světe!" ;

A PHP zapíše testovací proměnnou do souboru přidruženého k této relaci.

Zde je velmi důležitý bod.

Pole $ _ZASEDÁNÍ- speciální.
Ve skutečnosti obsahuje proměnné, které chceme zpřístupnit v různých skriptech.
Chcete -li proměnnou umístit do relace, stačí ji přiřadit k prvku pole $ _SESSION.
Abyste získali jeho hodnotu, stačí odkázat na stejný prvek. Níže bude uveden příklad.

Sběr odpadků - PHP se také podílí na odstraňování zastaralých souborů. Stejně jako kódování dat a spoustu dalších užitečných věcí. Díky této péči je práce s relacemi velmi snadná.
Tady jsme ve skutečnosti a přišli jsme na příklad práce relací.
Příklad je velmi malý:

session_start ();

echo „Aktualizovali jste tuto stránku“... $ _SESSION ["počítadlo"] ++. „jednou.“;
ozvěna "
Aktualizace ";
?>

Zkontrolujeme, zda máme v relaci proměnnou čítače, pokud ne, pak ji vytvoříme s hodnotou 0 a poté vydáme její hodnotu a zvýšíme ji o jednu. Zvýšená hodnota bude zapsána do relace a při příštím volání skriptu bude mít proměnná hodnotu 1 atd. Všechno je velmi jednoduché.

Abyste měli přístup k proměnným relací na jakýchkoli stránkách webu, musíte na začátek KAŽDÉHO souboru, do kterého potřebujeme relace, napsat POUZE JEDEN (!) Řádek:

session_start ();

session_start ();
pokud ($ _SESSION ["autorizováno"]<> 1 ) {
header ("Umístění: /auth.php");
výstup;
}

Odebírání proměnných z relace. Pokud máte register_globals = vypnuto, napište

unset ($ _ SESSION ["var"]);

Pokud ne, tak poblíž s tím musíte napsat:

session_unregister ("var");

Je velmi důležité pochopit, k čemu by sezení měla sloužit a k čemu nikoli.

Nejprve si pamatujte, že relace lze použít pouze tehdy, když je uživatel potřebuje, a ne mu překážet. Ostatně identifikátoru se může kdykoli zbavit!
Například při kontrole, že osoba vyplňuje formulář, nikoli skript, má uživatel zájem o to, aby relace fungovala - jinak nebude moci formulář odeslat! Ale pro omezení počtu požadavků na skript již relace není vhodná - škodlivý skript jednoduše nevrátí identifikátor.

Za druhé. Je důležité jasně pochopit skutečnost, že relace je relací práce s webem, jak tomu člověk rozumí. Přišel, pracoval, zavřel prohlížeč - relace skončila. Jako filmová relace. Pokud chcete vidět další - kupte si nový lístek. Zahajte novou relaci. K tomu existuje také technické vysvětlení. Je zaručeno, že mechanismus relace funguje pouze do zavření prohlížeče. Cookies přeci nemusí klientovi fungovat a v tomto případě samozřejmě všechny odkazy doplněné identifikátorem po jeho zavření zmizí.

Relace však může zmizet bez zavření prohlížeče. Vzhledem k omezením popsaným v tomto článku nemůže modul relace detekovat, když uživatel zavřel prohlížeč. K tomu slouží časový limit - předem určený čas, po kterém usoudíme, že uživatel web opustil. Ve výchozím nastavení je tento parametr 24 minut.

Chcete -li uložit informace o uživateli na delší dobu, použijte soubory cookie a v případě potřeby databázi na serveru. Zejména takto fungují všechny populární autorizační systémy:

Po identifikaci uživatele začne relace a je v ní přenášen znak autorizace.
- Pokud je nutné uživatele „zapamatovat“, pak je mu nastaven soubor cookie, který ho identifikuje.
- Při příštím vstupu uživatele na web musí pro přihlášení buď zadat heslo, nebo jej systém sám rozpozná podle dříve nastavených souborů cookie a relace se spustí. Nová relace, spíše než pokračování staré.

Za třetí, nemá cenu začínat relace bez rozdílu pro každého, kdo vstupuje na web. Tím vytvoříte zcela zbytečnou zátěž. Nepoužívejte relace pro maličkosti - například u čítačů. To, co spilogue volá relace, je samozřejmě založeno na statistikách hovorů a nepoužívá mechanismus relací podobný PHP.

Vezměme si navíc vyhledávač, který indexuje váš web. Pokud vyhledávací robot soubory cookie nepodporuje, pak PHP ve výchozím nastavení doručí na odkazy PHPSESSID, což nemusí být velmi příjemné pro vyhledávač, který podle pověstí stejně neupřednostňuje dynamické odkazy, ale zde obecně při každém hovoru - nová adresa!

Pokud se relace používají k omezení přístupu do uzavřené části webu, pak je vše pouze vyhledávač a nemělo by být indexováno. Pokud musíte stejnou stránku ukázat oprávněným i neautorizovaným uživatelům, pak zde pomůže takový trik - spustit relaci pouze těm, kteří zadali heslo, nebo těm, kteří již relaci zahájili.

Chcete -li to provést, místo jen session_start () píšeme:

if (isset ($ _ REQUEST [session_name ()])) session_start ();

relaci tedy zahájíme pouze těm, kteří odeslali identifikátor.
V souladu s tím je nutné jej odeslat uživateli poprvé - v době autorizace.

Pokud je název a bouda správná - napište session_start () !

Nejčastější chyby, kterých se PHP při pokusu o práci s relacemi dopouští, jsou:
Dva z nich,

Varování: Nelze odeslat cookie relace - záhlaví již byla odeslána
Varování: Nelze odeslat omezovač mezipaměti relace - záhlaví již odeslána

způsobené ze stejného důvodu, je v této skutečnosti popsáno řešení

Varování: open (/ tmp \ sess_SID, O_RDWR) se nezdařilo: Žádný takový soubor nebo adresář (2) v plné_script_path na čísle řádku

předtím vypadala

Varování: Nepodařilo se zapsat data relace (soubory). Ověřte, zda je aktuální nastavení session.save_path správné (/ tmp) ,

pokud je přeložen z angličtiny, vysvětluje problém podrobně: cesta zadaná v php.ini k adresáři, kde jsou zapsány soubory relací, není k dispozici. Tuto chybu lze nejsnadněji opravit. Stačí napsat adresář, který existuje a je zapisovatelný, např.

session.save_path = c: \ windows \ temp

A nezapomeňte poté Apache restartovat.

Jak se ukazuje, lidská inteligence nemá žádné limity, a proto musím vysvětlit:
třetí chybová zpráva (adresář nelze najít) nevyhnutelně povede k prvním dvěma, protože chybová zpráva je odeslána do prohlížeče a nemůžete po ní používat záhlaví. Nespěchejte proto hledat předčasný závěr, ale nejprve napište správnou cestu!

Dalším nejčastějším problémem při práci s relacemi je velké dědictví register_globals. NEDÁVEJTE proměnným skriptu stejné názvy jako indexy pole $ _SESSION!

S register_globals = on se hodnoty navzájem přepíší a vy budete zmatení.

Pokud to nefunguje, ale ani se nezobrazují žádné zprávy, přidejte na začátek skriptu dva řádky, které jsou zodpovědné za zobrazení VŠECH chyb na obrazovce - je docela možné, že jsou chyby, ale vy prostě nevidíte jim.

ini_set ("chyby zobrazení", 1);
error_reporting (E_ALL);

nebo zobrazit chyby v souboru error_log. Téma zobrazování chybových zpráv je obecně mimo rozsah tohoto článku, takže se ujistěte, že je alespoň vidíte. V této části si můžete přečíst trochu více podrobností o řešení potíží.

Pokud jste si jisti, že nejsou žádné chyby, ale daný příklad stejně nefunguje, pak je možné, že PHP neumožňuje přenos id přes url, a cookies z nějakého důvodu nefungují.
Podívejte se, co máte s cookies.

Obecně platí, že pokud vaše relace „nefungují“, zkuste nejprve ručně přenést identifikátor relace, tj. Vytvořit odkaz a přiřadit mu identifikátor:

session_start ();
if (! isset ($ _ SESSION ["counter"])) $ _SESSION ["counter"] = 0;
echo „Aktualizovali jste tuto stránku“... $ _SESSION ["počítadlo"] ++. „jednou.

Aktualizace ";
?>

Přitom se ujistěte, že není povolena direktiva session.use_only_cookies, která brání PHP v přijetí ID relace, pokud byla předána přes URL.

Pokud tento příklad nefunguje, problém je buď v banálu překlepy(polovina „problémů“ s relacemi pochází z nesprávně napsaného názvu proměnné) nebo v příliš staré verzi PHP: podpora relace se objevila ve verzi 4.0 a pole $ _ZASEDÁNÍ- v 4.1 (Dříve používané $ HTTP_SESSION_VARS).

Pokud to funguje, problém je v souborech cookie. Sledovat - jaké soubory cookie server vkládá do prohlížeče, zda je prohlížeč vrací. Hledání je velmi užitečné při sledování výměny záhlaví HTTP mezi prohlížečem a serverem.

Vysvětlení, jak cookies fungují, přesahuje rámec tohoto a příliš mnoho textu, ale alespoň zajistěte, aby server odesílal cookies s identifikátorem a prohlížeč se vrátil. A zatímco identifikátory se navzájem shodují =)
Nastavení cookies by mělo vypadat

Soubor cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6;

Soubor cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; cesta = /

(pokud požadujete skript, který není z kořenového adresáře)
Odpověď serveru by měla vypadat takto

Cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6

Cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; b = b

pokud prohlížeč vrací jiné cookies než ID relace.

Pokud příklad odtud funguje, ale váš vlastní kód ne, pak problém zjevně není v relacích, ale v algoritmu. Podívejte se, kde jste proměnnou ztratili, krok za krokem odtud přeneste příklad, odlaďte svůj skript.

Další problém může nastat, pokud používáte přesměrování záhlaví nebo navigaci v JavaScriptu.
Faktem je, že PHP automaticky připojuje identifikátor relace pouze k odkazům ve formuláři , ale nedělá to pro záhlaví, javascript, meta tagy.

Proto je třeba přidat identifikátor ručně, například takto:

header ("Umístění: /script.php?". název_relace (). "=". session_id ());

Velmi vzácným problémem a není zcela jasné, odkud pochází, je to, že nastavení session.save_handler má jinou hodnotu než soubory. Pokud tomu tak není, opravte to.

Kromě souborů cookie mechanismus relace odesílá také záhlaví, která zakazují ukládání do mezipaměti stránky (stejný omezovač mezipaměti). U html je to správné a nezbytné. Když se ale pokusíte odeslat soubor se skriptem, který kontroluje autorizaci, Internet Explorer odmítne jej stáhnout. Je to kvůli tomuto titulu. Volání
session_cache_limiter ("soukromé");
musí problém vyřešit před zahájením relace.
Kupodivu, ale v poli $ _ZASEDÁNÍ nemůžete používat číselné indexy - $ _SESSION [1], $ _SESSION ["10"]- relace nebudou fungovat.
Někde mezi 4,2 a 5,0 nebylo možné nastavit session.use_trans_sid pomocí ini_set ()... Od verze 5.0 je to již možné znovu.
Před verzí 4.3.3 cookies PHP zasílalo cookies pouze v případě, že požadavek na začátku relace neobsahoval identifikátor. Nyní jsou soubory cookie odesílány při každém hovoru relace_start

Pokud máte další dotazy nebo vám není něco jasné - vítejte v našem

Od samého začátku všichni přijímali PHP s přehledem, ale jakmile začali vytvářet dostatečně velké projekty v tomto jazyce, vývojáři čelili novému problému - v PHP neexistoval koncept globálních proměnných! To znamená, že byl spuštěn skript, odeslán vygenerovanou stránku klientovi a všechny prostředky použité tímto skriptem byly zničeny. Pro ilustraci řekněme, že na stejném webu jsou dvě stránky, index.php a dothings.php. Zdroje pro tyto stránky vypadají takto:

index.php dothings.php

Pokud spustíte tyto dva skripty, pak na první stránce uvidíme nápis „Byl jsem přiřazen index.php“ a druhá stránka bude prázdná.

Vývojáři webových stránek bez váhání začali používat cookies k ukládání globálních proměnných na straně klienta. Proces vypadal nějak takto: uživatel přijde na domovskou stránku webu, provede nějakou akci a všechny informace související s tímto uživatelem, které mohou být vyžadovány na jiných stránkách webu, budou uloženy v jeho prohlížeči ve formě cookie. Tato metoda má docela vážné nevýhody, kvůli kterým se mnoho vývojářů otočilo zády k PHP najednou. Potřebujeme například autorizovat uživatele, aby mu umožnil přístup k omezeným (nebo pouze jeho vlastním) částem webu. Budete muset uživateli zaslat soubor cookie, který bude sloužit jako jeho následný identifikátor na webu. Tento přístup se stává velmi těžkopádným a nepohodlným, jakmile stránka začne shromažďovat stále více informací o chování uživatelů, protože všechny informace zaslané uživateli by měly být přednostně zakódovány tak, aby je nebylo možné padělat. V poslední době bylo možné předstíráním cookie „naskládat“ více než jeden chat a někdy se dokonce dostat do pošty někoho jiného. Navíc jsou na světě stále zvláštní lidé, jejichž prohlížeč soubory cookie nepodporuje.

Nebudu se zabývat technologickými problémy struktury mechanismu relací, ale pouze popíšu, jak správně pracovat s relacemi v PHP.

Jak pracovat s relacemi?

Pokud vyzkoušíte příklady z článku (nebo vašich skriptů) na jakémkoli komerčním hostingu, neměly by být problémy s prací s relacemi. Pokud si server nastavíte sami (ať už jde o skutečný server nebo emulátor), mohou se objevit chyby s následujícím obsahem:

"Varování: otevřené ( / var / state / php / sess_6f71d1dbb52fa88481e752af7f384db0, O_RDWR) se nezdařilo: Žádný takový soubor nebo adresář (2)".

Znamená to jen, že vaše PHP je nesprávně nakonfigurováno. Tento problém můžete vyřešit zapsáním správné cesty (do existujícího adresáře) pro ukládání relací do souboru php.ini a restartováním serveru.

Jakýkoli skript, který bude používat proměnné (data) z relací, by měl obsahovat následující řádek:

Session_start ();

Tento příkaz řekne serveru, že daná stránka potřebuje všechny proměnné, které jsou spojeny s daným uživatelem (prohlížečem). Server převezme tyto proměnné ze souboru a zpřístupní je. Je velmi důležité otevřít relaci před odesláním jakýchkoli dat uživateli; v praxi to znamená, že je vhodné zavolat funkci session_start () na samém začátku stránky, například:

Session_start (); ?> ... Chcete -li nastavit adresář, do kterého se budou ukládat soubory relací, použijte funkci session_save_path (): session_save_path ($ _ SERVER ["DOCUMENT_ROOT"]. "/ Session"); session_start ();

Jakmile relace začne, můžete nastavit globální proměnné. Při přiřazování hodnoty jakémukoli poli v poli $ _SESSION se proměnná se stejným názvem automaticky zaregistruje jako proměnná relace. Toto pole je k dispozici na všech stránkách využívajících relaci. Pojďme například analyzovat program:

index.php Vše OK. Relace byla načtena! Pojďme projít, uvidíme, co tam je:

dothings.php

Když jsou tyto soubory spuštěny postupně, první skript "index.php" vytvoří následující výsledek:

Vše OK. Relace byla načtena! Pojďme projít, uvidíme, co tam je:

A druhý „dothings.php“ je tento:

Byl jsem požádán na index.php

Proměnná $ a je nyní k dispozici na všech stránkách tohoto webu, které zahájily relace.

Další užitečné funkce a techniky pro práci s relacemi:

zrušit nastavení ($ _ SESSION ["a"])- relace „zapomíná“ na hodnotu proměnné nastavené relací;
session_destroy ()- relace je zničena (například pokud uživatel opustil systém stisknutím tlačítka „Konec“);
session_set_cookie_params (int životnost [, cesta řetězce [, doména řetězce]]- pomocí této funkce můžete nastavit, jak dlouho bude relace „žít“ nastavením unix_timestamp definujícím čas, kdy relace „zemře“. Ve výchozím nastavení relace „žije“, dokud klient nezavře okno prohlížeče.
session_write_close ()- záznam proměnných relace a její ukončení. Je to nutné k otevření webu v novém okně, pokud stránka provádí dlouhé zpracování a zablokovala soubor relace pro váš prohlížeč.

Příklady

Nyní přejdeme k praktické aplikaci mechanismu relace. Zde se podíváme na několik poměrně jednoduchých, ale užitečných příkladů.

Autorizace uživatele

Otázky týkající se autorizace uživatelů pomocí relací PHP jsou neustále kladeny na konferencích webového programování. Mechanismus autorizace uživatelů v systému pomocí relací je z bezpečnostního hlediska docela dobrý (viz část).

Náš příklad bude sestávat ze tří souborů: index.php, authorize.php a secretplace.php. Soubor index.php obsahuje formulář, kde uživatel zadá své uživatelské jméno a heslo. Tento formulář předá data do souboru authorize.php, který v případě úspěšné autorizace umožní uživateli přístup k souboru secretplace.php a v opačném případě zobrazí chybovou zprávu.

Příklady: index.php Zadejte heslo

authorize.php stránka ... záhlaví ("Umístění: secretplace.php"); výstup; )) // pokud něco není v pořádku, pak uživatel obdrží // chybovou zprávu. ?> Zadali jste nesprávné heslo!

secretplace.php Ahoj,, jste na tajné stránce !!! :)

Bezpečnostní

Jsme tedy schopni přenést identifikátor z jedné stránky (skript PHP) na jinou (až do dalšího volání z našeho webu), což znamená, že můžeme rozlišit všechny návštěvníky stránek. Vzhledem k tomu, že identifikátor relace je velmi velký počet (128 bitů), prakticky neexistuje šance, že by byl hrubou silou. Útočníkovi tedy zbývají následující možnosti:

v počítači uživatele je trojský kůň, který krade čísla relací;
Útočník zachycuje provoz mezi počítačem uživatele a serverem. Samozřejmě existuje zabezpečený (šifrovaný) protokol SSL, ale ne každý ho používá;
soused přišel k počítači našeho uživatele a ukradl číslo relace.

Takové situace, založené na skutečnosti, že někdo někomu něco ukradne, obecně nepatří do kompetence programátora. O to by se měli postarat správci a samotní uživatelé.

PHP však lze často oklamat. Podívejme se na možné hackerské body v programu autorizace uživatelů:

Soubor authorize.php - pokus uhádnout heslo pomocí skriptu třetí strany;
Soubor secretplace.php je pokusem oklamat program zadáním hodnot proměnné $ logging_user do adresního řádku prohlížeče, například:
"http://www.yoursite.ru/secretplace.php? logged_user = hacker"

V našem programu jsou tedy jasně viditelné dvě „díry“, jedna je malá a nijak zvlášť nápadná, ale druhá je prostě obrovská, přes kterou většina hackerů leze tam, kam nepotřebují.

Jak „zalepit“ díru číslo 1?

Nebudeme psát tuny kódu, abychom zablokovali IP adresu atd., Ale stačí zkontrolovat, odkud požadavek pochází, respektive ze které stránky požadavek pochází, pokud se jedná o libovolnou stránku z našeho webu, pak je vše v pořádku, ale ve všech ostatních případech to nepustíme dovnitř. Opravme soubor authorize.php:

authorize.php V2 stránka ... záhlaví ("Umístění: secretplace.php"); výstup; )))?> Zadali jste nesprávné heslo!

Jak se zbavit „díry“ číslo 2?

Předpokládejme, že máte webovou stránku, kde se každý smrtelník může zaregistrovat a zveřejnit příspěvek na fóru. Přirozeně mají někteří uživatelé (administrátoři, moderátoři) ve fóru více příležitostí než ostatní, například mohou mazat zprávy od jiných uživatelů. Úroveň přístupu uživatele ukládáte do relace v proměnné $ user_status, kde $ user_status = 10 odpovídá plnému přístupu do systému. Útočníkovi, který přijde na web, stačí, aby se pravidelně registroval a poté přidal do adresního řádku prohlížeče ? user_status = 10... Takže máte na svém fóru nového administrátora!

V zásadě lze pomocí adresního řádku nastavit libovolnou proměnnou skriptu, jednoduše přidáním otazníku a názvu proměnné s její hodnotou za celou adresu do skriptu. Opravme náš kód, abychom se tomu vyhnuli:

secretplace.php V2 proměnná není nastavena ($ _ SESSION ["logged_user"]); // otevření relace session_start (); / * nemůžete jen přejít na tuto stránku ... pokud není uživatelské jméno zaregistrováno, přesměrujeme jej na stránku index.php, kde zadáte přihlašovací jméno a heslo ... zde ve skutečnosti můžete udělat hodně, pro zapamatujte si například IP uživatele a po třetím pokusu o přístup k souborům ji zablokujte. * / if (! isset ($ _ SESSION ["logged_user"])) (header ("Location: index.php"); exit;)?> Ahoj,, jste na tajné stránce!

Výsledky

Mechanismus relace je docela skvělá funkce jazyka PHP. Relace jsou jednoduché a velmi flexibilní. Mimochodem, existuje jedna, na několika místech zdokumentovaná možnost relací PHP (k dispozici od verze 4.0.3) - do relací můžete ukládat nejen proměnné, ale i objekty.

Příklady

?>
// Automatické vkládání SID do odkazů. ini_set ("session.use_trans_sid", true); session_start (); ?> Klikněte zde!
Klikněte zde !!

// Příklad práce s relacemi. session_start (); // Pokud je web právě navštíven, vynulujte počítadlo. if (! isset ($ _ SESSION ["count"])) $ _SESSION ["count"] = 0; // Zvýšení počitadla v relaci. $ _SESSION ["count"] = $ _SESSION ["count"] + 1; ?>

Čelit

čas (s).
Chcete -li počítadlo vynulovat, zavřete prohlížeč.
"target =" _blank "> Otevřete podřízené okno prohlížeče.
// Jednoduchý příklad použití relací bez cookies. session_name ("test"); session_start (); $ _SESSION ["count"] = @ $ _ SESSION ["count"] + 1; ?>

Čelit

V aktuální relaci s prohlížečem jste otevřeli tuto stránkučas (s).
Chcete -li toto počítadlo resetovat, zavřete prohlížeč.
?"> Kliknutím sem stránku obnovíte!

Relace jsou jednoduchým způsobem, jak ukládat informace pro jednotlivé uživatele s jedinečným ID relace. To lze použít k zachování stavu mezi požadavky na stránky. ID relací se obvykle odesílají do prohlížeče prostřednictvím cookie relace a slouží k načítání dostupných dat o relaci. Absence ID relace nebo cookie relace říká PHP, aby vytvořilo novou relaci a vygenerovalo nové ID relace.

Relace používají jednoduchou technologii. Když je vytvořena relace, PHP buď získá existující relaci pomocí předaného identifikátoru (obvykle ze souboru cookie relace), nebo pokud nebylo předáno nic, bude vytvořena nová relace. PHP zaplní superglobal $ _SESSION informacemi o relaci po zahájení relace. Když PHP skončí, automaticky serializuje obsah superglobalu $ _SESSION a odešle k uložení pomocí obslužného programu relace k záznamu relace.

Ve výchozím nastavení PHP používá k ukládání relací interní obslužný program souborů, který je nastaven v proměnné INI session.save_handler. Tento obslužný program ukládá data na server v adresáři uvedeném v konfigurační směrnici session.save_path.

Relace lze spustit ručně pomocí funkce session_start ()... Pokud je direktiva session.auto_start nastavena na 1, relace se automaticky spustí na začátku požadavku.

Relace obvykle končí, když PHP dokončí provádění skriptu, ale lze ji také ukončit ručně pomocí funkce session_write_close ().

Varování

Pozornost

Komentář:
Relace využívající soubory (výchozí v PHP) blokují soubor relace ihned po otevření relace pomocí této funkce session_start () nebo nepřímo zadáním session.auto_start. Po zablokování nemůže žádný jiný skript přistupovat ke stejnému souboru relace, dokud není zavřen, nebo když skript skončí nebo když je vyvolána funkce. session_write_close ().

To je s největší pravděpodobností problém pro weby, které intenzivně používají AJAX a podávají více souběžných požadavků. Nejjednodušší způsob, jak tento problém vyřešit, je zavolat funkci session_write_close () jakmile byly provedeny všechny požadované změny v relaci, nejlépe blíže k začátku skriptu. Můžete také použít jiný mechanismus relace, který podporuje souběžnost.

Nechápu proč, ale zkusil jsem všechny / odpovědi google .. Nic jsem nenašel. Zde je situace:

Localhost kód

Výsledek:

Sekvenční session_id () mezi stránkami aplikace a obnovením stránky. $ _COOKIE ["PHPSESSID"] odpovídá session_id ()

Přímý server

Session_start (); echo session_id (); print_r ($ _ COOKIE ["PHPSESSID"]);

Výsledek:

session_id () se mění při každém požadavku, načtení stránky nebo návštěvě jiné stránky. $ _COOKIE ["PHPSESSID"] je NULL / prázdné. Stejný kód je použit v horní části stránky. žádný další obsah.

Z tohoto problému mě pořádně bolela hlava, jaký typ konfigurace serveru nebo chyba to může způsobovat? Proč je soubor cookie PHPSESSID prázdný?

Jakákoli pomoc, prosím, kluci!

EDIT: Na svém lokálním vzdáleném serveru jsem vytvořil jednoduchý testovací soubor se 3 řádky. Nesouvisí to s mým kódem. $ _COOKIE ["PHPSESSID"] je stále prázdný a při každé aktualizaci se na skutečném hostiteli objeví nový session_id ().

error_reporting SET TO ALL Získám toto na živém hostiteli:

Upozornění: Nedefinovaný index: PHPSESSID v /home/vivaplug/public_html/dev/wp-content/plugins/test.php na řádku 5

Záhlaví Google Chrome

LOCALHOST

Adresa URL požadavku: http: //localhost/wp-content/plugins/test.php Metoda požadavku: ZÍSKAT stavový kód: 200 OK Žádost Zdroj zobrazení záhlaví Přijmout: text /html, aplikace /xhtml + xml, aplikace /xml; q = 0,9, image / webp, * / *; q = 0,8 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US, en; q = 0,8 Cache-Control: no-cache Connection: keep-live Cookie: PHPSESSID = 68b7m4arpsacks4aetgmd3rs93 Host: localhost Pragma: no-cache User-Agent: Mozilla / 5.0 (Windows NT 6.1) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 30.0.1599.101 Safari / 537.36 Response Headersview source Cache-Control: no-store, no- cache, must-revalidate, post-check = 0, pre-check = 0 Připojení: Keep-Alive Content-Type: text / html Datum: Út, 5. listopadu 2013 07:10:51 GMT vyprší: Čt, 19. listopadu 1981 08 : 52: 00 GMT Keep-Alive: timeout = 5, max = 100 Pragma: no-cache Server: Apache / 2.4.4 (Win32) PHP / 5.4.16 Transfer-Encoding: chunked X-Powered-By: PHP / 5.4 .16

ODSTRANIT SERVER

Adresa URL požadavku: http: //vivaplugins.com/dev/wp-content/plugins/test.php Metoda požadavku: ZÍSKAT stavový kód: 200 OK Požadovat zdroj zobrazení záhlaví Přijmout: text/html, aplikace/xhtml + xml, aplikace/xml; q = 0,9, image / webp, * / *; q = 0,8 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US, en; q = 0,8 Cache-Control: max-age = 0 Připojení: keep- naživu Host: vivaplugins.com User-Agent: Mozilla / 5.0 (Windows NT 6.1) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 30.0.1599.101 Safari / 537.36 Response Headersview source Age: 0 Cache-Control: no-store, no -cache, must-revalidate, post-check = 0, pre-check = 0 Content-Encoding: gzip Content-Type: text / html Date: Tue, 05 Nov 2013 07:07:49 GMT Pragma: no-cache Server: Advanced Hosting by http://www.unixy.net/varnish Přenosové kódování: blokové Vary: Accept-Encoding Via: 1,1 lak X-Cache: HIT X-Cache-Hits: 2 X-Cacheable: ANO X-Powered-By : PHP / 5.4.20 X-lak: 1984840969 1984839805