АВТОРИЗАЦІЯ ЗА ДОПОМОГОЮ COOKIES

Cookie - це файл в спеціальному форматі, який присилається сервером браузеру відвідувача сайту, розташованому на цьому сервері (ріс.8.5). Браузер, якщо він підтримує cookie (і ця підтримка в нім не відключена), поміщає його в особливе місце і згодом відправляє назад на сервер під час вступу від нього запиту. Іншими словами, cookie дозволяє серверу зберігати свою інформацію на комп'ютерах відвідувачів і прочитувати її звідти при необхідності. (Сучасні стандарти безпеки передбачають, що кожен сервер (Вірніше, вузол з власним ім'ям (будь-якого рівня)). може отримати назад лише ті cookie, які були встановлені особисто їм, так що навіть про те, які сайти ще відвідував відвідувач, за допомогою cookie взнати не можна.)

Ріс.8.5. Cookie зсередини

Примітка:
Cookie можна встановити (тобто прислати на комп'ютер відвідувача) і засобами РНР. Для цього використовується команда Setcookie, що має параметри: ім'я cookie, інформація, записана в cookie, час життя cookie - вказується кількість секунд, після виділення яких з 1 січня 1970 року cookie не повинен счити-ваться з комп'ютера відвідувача (так вже вимірюється час в операційних системах типа Unix - з початку "епохи Unix" 01,01.1970), адреси сайту і каталога на нім, де cookie має бути дійсний, і вказівка на протокол передачі cookie (детальніше дивитеся в Описі РНР). Рахувати cookie можна простою командою echo ("ім'я cookie"). Можна сказати, що, як тільки cookie встановлений, сценаріям на всіх сторінках того сайту, на якому він був поставлений, стає доступна змінна з тим же ім'ям, що і в cookie, і тим вмістом, який було записано в нім (якщо у файлі налаштування РНР встановлений в on параметр register_globals).
Крім того, значення cookie поміщаються в масив $HTTP_COOKIE_VARS і доступні в його елементах, однойменних з іменами cookie, - Shttp_cookie_vars['umh cookie'] (якщо у файлі налаштування РНР встановлений в on параметр track_vars), а в РНР версії 4.1 і вище - ще і в масив $_С00К1Е.
Для видалення cookie досить записати в нього порожнє значення (це зробить команда Setcookie з єдиним параметром -іменем cookie).
Для установки часу життя cookie можна спочатку взнати поточний "час Unix" командою time(), а потім просто додати до нього ту кількість секунд, яка cookie повинен проіснувати після його установки на комп'ютер відвідувача. Якщо час життя для cookie не встановлений, то він проживе до закриття всіх вікон браузера відвідувача.
Як і відправка заголовків командою Header, установка cookie повинні передувати будь-якому виводу у видаваний документ: як результатів виконання команд РНР, так і простого вмісту сторінки. Інакше виникне помилка.

Як cookie можна використовувати для вирішення обговорюваного в цій главі завдання - авторизації доступу? Та вчень просто - запитавши від відвідувача логін і пароль, записати їх в cookie, а потім на кожній сторінці "захищеної зони" прочитувати їх звідти і перевіряти, чи є такі дані у файлі паролів. Ну і поступати відповідно до результату такого порівняння - наприклад, відправляти ті браузери, які не змогли представити cookie з правильним логіном і паролем, прямо на сторінку авторизації, посилаючи їм за допомогою РНР-функции Header заголовок Location з відповідним параметром, як було показано вище для попереднього варіанту авторизації.
Ось фрагменти сценарію, в яких видно технологія використання cookies. На тій сторінці, звідки повинен здійснюватися вхід в "захищену зону", слід поставити просту форму для введення логіна і пароля (см.ріс.8.6). Наприклад, таку:

<FORM Action="up.php" Method=post> Логін: <INPUT Name="login" Type="text"><br> Пароль: <INPUT Name="pass" Type="password"><br> <INPUT Type="submit" Value="войті"></form>

Ріс.8.6. Авторизація на основі cookies. Просто форма...

На тій сторінці, ім'я якої вказане в параметрі ACTION заголовка форми, введені дані перевіряються, і в тому випадку, якщо такі логін і пароль є у файлі паролів, браузеру відвідувача відсилається cookie, куди ці логін з паролем записуються.

<?php
foreach (file("passw/passwr") as $k)
{
if (substr($k, 0 -2)=="$login $pass")
{
$rez=l;

І ось - сама установка cookie під ім'ям auth. Йому встановлюється "час життя" - 3600 з, тобто година

Setcookie("auth","$login $pass",time()+3 600);
} } ?>

Далі повинен знаходитися сценарій, який залежно від результату авторизації, - тобто значення змінної $rez - виводить різну інформацію. Наприклад, можна відіслати відвідувача назад на вихідну сторінку командою Header ("Location..."), як в прикладі попереднього розділу цієї глави.
На всіх останніх сторінках "захищеної зони" повинен знаходитися сценарій перевірки вмісту змінною auth (тобто тій, чиє ім'я збігається з ім'ям поставленого cookie) - тобто такий самий скрипт, як і на тій, де cookie ставився, лише рядок перевірки повинен виглядати як

if (substr($k, 0 -2)=="$auth")

ну і, природно, самої команди установки cookie бути не повинно. Подальший текст сторінки - на розсуд web-мастера: якщо логін з паролем, отримані з cookie, є у файлі паролів, то, скажімо, вивести форму для закачування файлів, якщо немає - те ввічливе розпрощатися...
Бажано також зробити сторінку "виходу", включивши в неї команду установку cookie без параметрів - Setcookie ("ім'я cookie").
В результаті в тому випадку, якщо відвідувач одного разу прошел авторизацію, то він може спокійно відвідувати сторінки "захищеної зони" до тих пір, поки cookie "живий" на його комп'ютері. Він може закрити вікно браузера і навіть вимкнути комп'ютер, а потім, включивши його, знов зайти на ту ж адресу, використовуючи "Історію" браузера або "Закладки"- і він буде авторизований, якщо час життя cookie не витік. Зате ті, хто "підгляне" ця адреса або вкраде закладку, але не матиме відповідного cookie, авторизовані не будуть.
На відміну від попереднього способу, даний варіант не є абсолютно надійним в плані збереження в таємниці логіна з паролем. По-перше, cookie з цими даними зберігається на комп'ютері відвідувача, а значить, теоретично може бути з нього викрадений (тим, хто просто сяде за цей комп'ютер і скопіює потрібний cookie з тієї теки, де вони зберігаються). По-друге, можливість заходу на web-страницу "захищеної зони" протягом деякого часу без необхідності введення логіна і пароля може привести і до небажаних наслідків - якщо відвідувач забуде зайти на сторінку виходу, то будь-який, хто скористається його комп'ютером до закінчення терміну дії cookie, з точки зору сервера буде сповна легальним користувачем і зможе влаштувати дійсному власникові логіна немало проблем.
Варто сказати, що використовувати ім'я cookie як змінну можна лише в тому випадку, якщо у файлі налаштування РНР - php.ini - є параметр register_globals. Там, де цього параметра немає (наприклад, в РНР версії 4.2 і вище він за умовчанням неактивний), працювати з cookies як із звичайними змінними не вийде. Інформацію, поміщену в них, доведеться отримувати з масиву з назвою SHTTPCOOKIEVARS (створюється автоматично при виявленні cookies від даного сайту), використовуючи ім'я потрібного cookie як індекс:

<?php
foreach (file("passw/passwr") as $k)
{
if (substr($k, 0 -2)==$HTTP_COOKIE_VARS['auth'])
{ $rez=l;
}
}
...

У РНР версії 4.1 і вище замість $HTTP_COOKIE_VARS можна використовувати масив $_СООК1Е.
Сподіваюся, ви зрозуміли, що всі ці перевірки логінів і паролів в cookies і що передаються між вікнами змінних, про які так детально розповідається в цьому і попередньому розділах, призначені для однієї мети - щоб той, хто яким би то не було чином взнав би адресу сторінки з "захищеної зони" і зайшов би на цю сторінку шляхом набору її адреси в адресному рядку браузера (або за допомогою ярлика в "Вибраному"), не міг би побачити на ній те ж саме, що і сумлінно минулі авторизацію відвідувачі. Щоб не доводилося запрошувати від відвідувачів пароль і логін на кожній сторінці, де є можливість зробити ті дії, які украй небажано дозволяти робити всім підряд, - як, наприклад, завантаження файлів або перегляд особистої пошти - а дати відвідувачам можливість, одного разу ввівши авторизаційні дані, вільно переміщатися по "захищеній зоні". Саме це і є основним завданням описаних технологій.