Сесії — глобальні змінні веб-додатків

Юрій Максименко

Розробники програм мають необхідність декларувати змінні, які були б доступні «завжди й всюди». Якщо точніше — у всіх частинах програми і протягом всього сеансу роботи з програмою. Приміром, дані користувача, котрий залогінився. Не витягати ж кожного разу з бази даних його прізвище!

У веб-додатку задекларувати такі змінні, на щастя, можна. Але не без проблем, вирішенню яких і присвячена ця стаття.

А що, власне, за проблеми?

Проблема з протоколом http. Він не зберігає стани. Тобто, не запам'ятовує попереднього входу відвідувача (і таке можна зрозуміти: це ж скільки б йому довелося запам'ятовувати?). Тому веб-сервер «не впізнає» відвідувача, який навіть просто поновив сторінку.

І що ж робити?

Як чинить людина, коли має проблеми з пам'яттю? Вона записує. На щастя, веб-сервери й браузери теж вміють записувати необхідну нам інформацію. І дарують нам дві можливості: «куки» (cookie) й сесії. До того «куки» пише браузер на комп'ютері користувача, а сесії записує веб-сервер в серверній папці.

Про роботу с куками вичерпно пишуть у багатьох навчальних матеріалах, в тому числі й в уроках «ШАГа», тому я дозволю собі на них довго не спинятись.

Позначу лише обмеження:

• Користувач може заборонити своєму браузеру записувати cookie;
• Ряд браузерів обмежує об'єм cookie чотирма кілобайтами.

Тому надійним механізмом для зберігання глобальних змінних ми назвемо сесії.

Що таке сесія?

Фізично - це файл на диску, в котрий записано змінні й їх значення. Якщо попросити сервер (програмно, звичайно!) записати для нас сесію, він створить файл з унікальним ім'ям, і це ім'я нам повідомить.

А якщо ми попросимо прочитати змінні з файлу, вказавши ім'я - він прочитає змінні й розмістить їх в масив, з яким ми зможемо працювати. До того ж наші зміни цього масиву призведуть до зміни сервером (не нами!) файлу сесії.

Тобто, наступній сторінці ми маємо повідомити ім'я файлу (який загалом називають ідентифікатором сесії).

В нас є три способи передати наступній сторінці ідентифікатора сесії: метод GET, метод POST, cookie.

А можна на прикладах коду?

Можна. Розповімо, як ми можемо надійно підтримати роботу з сесіями в php й в ASP.NET.

php

Якщо сторінка хоче працювати з сесіями, вона має якомога ближче до свого початку запустити функцію session_start(). Параметри цієї функції не потрібні. Викликом цієї функції ми включаємо підтримку роботи з сесіями. Це резерв швидкодії: при опрацюванні сторінок, яким не потрібна сесія, веб-сервер не буде робити зайвих рухів.

Після виклику цієї функції стає доступним масив $_SESSION. Він доступний як для читання, так і для запису. Правда, щоби працювати з ним всередині функції чи методу, треба всередині функції(методу) задекларувати його як глобальний:

global $_SESSION;

Змінюючи цей масив, ми змінюємо зміст файлу сесії (його відредагує інтерпретатор php).

І головне: як передати ідентифікатор сесії наступній сторінці?

Якщо в користувача ввімкнені «куки» — все буде зроблено за вас. Вам треба буде лише не забути викликати функцію session_start().

php спробує прочитати куку на ім'я PHPSESSID, отримати звідти ідентифікатор сесії, прочитати відповідний файл і заповнити для вас масив $_SESSION. Якщо такої «куки» немає, php створить файл сесії й його ім'я запише в «куки»  PHPSESSID - і інша сторінка витягне сесію звідти.

Отже, є «куки» — все просто. Викликав на початку сторінки session_start() — і працюй собі з масивом $_SESSION без зайвих турбот. Розробник офісної програми може дозволити собі такий розкіш: адже він може примусити всіх «куки» ввімкнути.

А якщо «куки» все ж вимкнені?

Автор перерабатывает эту часть статьи

ASP.NET

Нам треба вирішити: віримо ми в те, що в користувача «куки» ввімкнені?

Якщо вирішили повірити, то в класі веб-форми визначено масив Session, робота з яким жодних проблем не складає. Але якщо «куки» все же вимкнені, робота з сесіями буде некоректною.

Якщо не віримо — то в файлі Web.config в секції <configuration> вставляємо тег, який відображає нашу недовіру:

<configuration>
  <system.web>
    <sessionState 
      cookieless="true"
      regenerateExpiredSessionId="true"
      timeout="30" />
  </system.web>
</configuration>

В цьому випадку IIS буде вставляти ідентифікатор сесії в URL, але не як GET-параметр, а на свій кшалт.

Приклад:

http://localhost:4635/(S(bpdntc45qo51bq3iq3lrqzie))/default.aspx

Під час запиту IIS витягне з URL ідентифікатор сесії й ініціалізує масив Session

Можливості програмно попрацювати з ініціалізацією сесії я не знайшов.

До речі

Ідентифікатор сесії, про який ми стільки говорили, може вам знадобитись не тільки для роботи з сесією.

Часто виникає необхідність створити папку чи файл, до того ж так, щоб сеанс роботи одного користувача не затирав папки чи файли іншого. Тут недосвідчені розробники починають нездорові експерименти з поточним часом і випадковими числами...

Зрозуміло, як тут вам допоможе ідентифікатор сесії?

Ні?

Тоді нехай це буде вашим домашнім завданням...

Бібрка, 25 червня 2009 р.