СЕСІЇ

"Сесія" - декілька абстрактне поняття, що означає щось начеб "закінченого періоду роботи з сайтом ". Наприклад, в сесію можуть входити такі дії, як "прихід на сайт - завантаження даних -уход з сайту". Інколи визначення сесії різняться в своєму формулюванні, але суть приблизно така.
Так от - за допомогою команд "Підтримка сесій" РНР можна при заході відвідувача на сайт запам'ятовувати які-небудь змінні і потім ці змінні прочитувати або змінювати на інших сторінках цього сайту. При цьому - звернете увагу - в браузер відвідувача передаються зовсім не самі ці змінні, а якийсь пароль, по якому сервер згодом цей браузер взнає і відновить саме ті значення змінних, які були встановлені для даного відвідувача.
Іншими словами - робота механізму сесій в РНР відбувається так. Коли відвідувач заходить на сайт і для нього встановлюються які-небудь змінні (чи сам він їх вводить або, скажімо, вони беруться з бази даних), то команди почала і реєстрації сесії зберігають ці змінні у визначеному місці на самому сервері (у спеціальному файлі в теці тимчасових файлів сервера, мал. 8.7, 8.8).

Мал. 8.7. Файли з даними сесій в теці тимчасових файлів сервера. Імена файлів відповідають ідентифікаторам сесій

Мал. 8.8. Вміст один з таких файлів. У сесії збережені змінні: legus, wql, wq2, wq3

Якщо у відвідувача браузер приймає cookie, то йому висилається cookie (з певним ім'ям - за умовчанням "PHPSESSID"), що містить так званий "ідентифікатор сесії" (мал. 8.9), а якщо немає, то web-сервер автоматично поміщає даний ідентифікатор в змінну PHPSESSID в кожне заслання (мал. 8.10) на видаваних відвідувачеві сторінках сайту (природно, "внутрішню" - тобто ведучу на інші сторінки того ж самого сайту, з тим же самим доменним ім'ям). Таким чином, ідентифікатор передається на сервер при кожному заході відвідувача на яку-небудь із сторінок сайту. При цьому ідентифікатор вибирається або з відповідного cookie, встановленого відвідувачеві при відкритті сесії, або з адресного рядка заслання, куди цей ідентифікатор автоматично поміщається web-сервером.

Мал. 8.9. Вміст cookie з ідентифікатором сесії

Мал. 8.10. Заслання з ідентифікатором сесії

Як тільки сервер отримує від відвідувача певний ідентифікатор сесії, то він передає сценарію на тій сторінці, на яку зайшов відвідувач, всі встановлені для цього відвідувача збережені змінні, після чого сценарій може їх використовувати, тобто читати, змінювати, знищувати. При переході на наступну сторінку сайту всі зміни будуть збережені.
Кожного разу створюється новий ідентифікатор сесії. Завдяки хорошому алгоритму генерації вірогідність того, що для якої-небудь послідовності символів на певному сервері існуватиме набір збережених змінних, нехтує мала. Ще менше вірогідність збігу двох ідентифікаторів сесій, так що різні відвідувачі сайту ну ніяк не зможуть набути значення змінних один одного.
Безперечно, набір збережених змінних, що відносяться до однієї сесії, існуватиме на сервері не вічно. У параметрах файлу конфігурації РНР - php.ini - вказується, який час життя встановлюється для cookie з ідентифікатором сесії (за умовчанням 0 -т. е. до закриття вікна браузера і всіх відкритих з нього вікон), а також через який час дані сесій з теки тимчасових файлів віддаляються фізично (мал. 8.11). Крім того, існує спеціальна команда "Руйнування сесії", яка при своєму виконанні знищує збережені в теці тимчасових файлів дані сесії і тим самим робить недійсним ідентифікатор сесії. Параметри встановлюваних cookie, зокрема, їх "час життя" також можна задати спеціальною командою в сценарії на РНР, проте час зберігання даних сесії в теці тимчасових файлів визначається параметром в php.ini, отже при використанні віртуального хостингу вам не завжди удасться набудувати роботу з сесіями повністю так, як вам би хотілося.

Ріс.8.11. Файл php.ini, розділ налаштувань параметрів сесій

Щоб використовувати в сценарії на сторінці можливості роботи з сесіями, необхідно включити в нього команду session_start () (оскільки при роботі з сесіями використовуються cookie, то дана команда повинна знаходитися на початку сторінки, перед тими, що якими-небудь виводяться в браузер даними) - як при первинній установці змінних, так і при подальшій роботі з ними (якщо у файлі php.iniустановлен у 1 параметр session.auto_start, то це робити не обов'язково). Щоб вказати, які змінні слід зберігати як дані сесії, слід використовувати команду session register("ім'я першої змінної", "ім'я другої змінної"... і т. д.), а щоб закрити сесію - команду session_destroy (). При закритті сесії змінні, передані сценарію з її допомогою, не обнуляються (останнє робить команда session_unset () ;), так що їх можна використовувати і в останній частині сценарію.
Змінні сесії доступні на сценаріях сайту по своїх початкових іменах - скажімо, якщо командою session_register змінна $а була зареєстрована як сесійна, то її значення буде доступне під тим же самим ім'ям - $а - на всіх сторінках сайту, де використовуються сесії (тобто на їх початку розміщена команда session_start ()).
Змінні сесії доступні в сценаріях сайту по своїх початкових іменах. Скажімо, якщо командою session_register змінна $а була зареєстрована як сесійна, то її значення буде доступне під тим же самим ім'ям - $а - на всіх сторінках сайту, де використовуються сесії (тобто на їх початку розміщена команда session_start ()).
Проте в цілях безпеки краще працювати в сценарії із змінними сесії через автоматично створювані масиви $HTTP_SESSION_VARS і (у РНР версій 4.1 і старше) SSESSION, використовуючи однойменні із змінними елементи цих масивів. Річ у тому, що в цьому випадку сценарій буде захищений від можливих спроб зловмисників передати йому значення цих змінних через вказівку їх в адресному рядку, якщо сесія не була відкрита (у вказані масиви потрапляють ті і лише ті дані, що були отримані з сесією). Така передача може привести, скажімо, до того, що змінна - позначка про успішне проходження авторизації буде отримана сценарієм не з даних сесії (у яких вона може з'явитися лише після успішного введення відвідувачем правильного логіна і пароля), а від зловмисника.