Page 178 - 4636

"5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8". Цей рядок не може бути дешифровано й перетворено
назад в "password" навіть її творцем, тому на перший погляд він може видатися не настільки вже
корисним. Що робить функцію shal() корисною, так це те, що її результат строго детермінований.
Для одного й того самого рядка shal() буде повертати той самий результат при кожному її виклику.
Таким чином, замість Рнр-Коду
if (($username == 'username') && (Spassword = 'password')) {
// Пароль збігається )
можна скористатися кодом:
if ((Susername == 'user') &&
(shal($password) == '5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8')) { //
Пароль збігається
)
Перед використанням функції shal() не потрібно знати, як виглядав рядок пароля. Досить
знати, чи збігається введений пароль із тим, для якого застосовувалася shal().
Як уже згадувалося, тверде кодування правильних імен і паролів відвідувачів у сценарії —
невдала ідея. Для їхнього зберігання слід використовувати окремий файл або базу даних.
Якщо для зберігання даних аутентифікації обрана база даних Mysql, можна скористатися Php-
Функцією shal() або Mysql-Функцією SHA1(). Mysql пропонує більший спектр алгоритмів
хенування в порівнянні із РНР, однак усі вони служать однієї й тієї ж мети.
Щоб скористатися функцією SHA1(), Sql-Запит у лістингу 9.2 слід переписати так:
Squery = "select count(*) from authorized_users where name = '".
Sname."' and password = shal('".Spassword."')";
Цей запит підраховує кількість рядків у таблиці authorizedusers, у яких значення поля name
збігається із умістом змінної $name, а значення поля password збігається з результатом застосування
функції SHA1() до змінної Spassword. Якщо ми змушуємо відвідувачів вибирати унікальні імена,
результатом запиту може бути 0 або 1.
Не забувайте, що хеш-функції загалом повертають дані фіксованого розміру. У випадку SHA1()
це 40 символів, представлених у вигляді рядка. Відповідний стовпець у базі даних повинен мати
достатню ширину.
Ще раз переглянувши код у лістингу 10.3, легко помітити, що ми створили одного користувача
('username') з незашифрованим паролем і ще одного користувача (' testuser *) — із зашифрованим
паролем.

10.5 Захист декількох сторінок

Захист більш ніж однієї сторінки за допомогою сценаріїв на зразок показаних у лістингах 9.1 і 9.2
виконується небагато складніше. Оскільки в Нттр-протоколі немаєй механізму відстеження стану, то
не існує автоматичного зв'язку між послідовними запитами, що надходять від того самого відвідувача.
Це ускладнює перенос зі сторінки на сторінку введених користувачем даних, таких як дані
аутентифікації;
Найбільш простий спосіб захисту декількох сторінок — використання механізмів керування
доступом, надаваних веб-сервером. Незабаром ми розглянемо ці механізми.
Щоб самостійно забезпечити такі можливості, потрібно включити частини лістингу 9.1 у код
кожної сторінки, яку необхідно захистити. За допомогою директив autoprependfile і
auto_append_file необхідний файл можна автоматично вставити в початок (prepend) або в
кінець (append) кожного файлу в зазначених каталогах. Що ж відбувається при такому підході, коли
користувач відкриває кілька сторінок сайту? Зрозуміло, що неприпустимо запитувати пароль окремо
для кожної сторінки, яку бажає переглянути користувач.
Введену користувачем інформацію можна було б включити в кожне гіперпосилання на сторінці.
Оскільки користувачі можуть указувати пробіли або інші символи, застосування яких заборонено в

175