HTTP -аутентіфікація в PHP можлива тільки при запуску РНР як Apache-модуля і, отже, недоступна в CGI-версії. У РНР-скрипт для Apache-модуля можна використовувати функцію header () для відправки повідомлення "Authentication Required" в клієнтський браузер, що викликає появу в ньому вікна введення Username / Password. Після того як користувач ввів username і password, URL містить PHP-скрипт, буде викликаний знову зі змінними $ PHP_AUTH_USER, $ PHP_AUTH_PW і $ PHP_AUTH_TYPE, в яких встановлені ім'я користувача, пароль і тип аутентифікації, відповідно. В даний час підтримується тільки аутентифікація "Basic". Див. Також про функції header ().
Приклад фрагмента скрипта, який форсує аутентифікацію клієнта:
Приклад 17-1. HTTP Приклад аутентифікації
Примітка: Будь ласка, будьте уважні при кодуванні рядків HTTP header'а. Щоб максимально гарантувати сумісність з усіма клієнтами, ключове слово "Basic" має бути записано з першої "B" в верхньому регістрі, керуюча / realm рядок має полягати в подвійні лапки (НЕ одинарні), і точно один пробіл повинен передувати коду "401" в рядку "HTTP / 1.0 401" header'а.
Замість простого висновку $ PHP_AUTH_USER і $ PHP_AUTH_PW, вам, можливо, знадобиться перевірити правильність username і password шляхом запиту БД або знаходження користувача в dbm-файлі.
Простежте за роботою браузерів Internet Explorer. Вони дуже чутливі до порядку header'ов. Відправка WWW-Authenticate header до HTTP / 1.0 401 header в даний момент є певним трюком.
Щоб запобігти написання будь-ким скрипта, який розкриває пароль до сторінки, аутентифицироваться за допомогою традиційного зовнішнього механізму, змінні PHP_AUTH НЕ будуть встановлені, якщо зовнішня аутентифікація включена для даної конкретної сторінки. У цьому випадку змінна $ REMOTE_USER може використовуватися для ідентифікації зовні аутентіфіціруемого користувача.
Зауваження про конфігурацію: PHP використовує наявність директиви AuthType для визначення того, чи діє зовнішня аутентифікація. Виключіть цю директиву для контексту, де вам необхідно використовувати аутентифікацію PHP (інакше кожна спроба аутентифікації зазнає невдачі).
Зауважте, однак, що вищесказане не запобігає викрадення тим, хто контролює нерозпізнаних URL, пароля з аутентіфіцированний URL на цьому ж сервері.
І Netscape Navigator, і Internet Explorer будуть очищати локальний кеш аутентифікації вікон браузера для сфери / realm при отриманні відповіді 401 сервера. Це може "log out" (виконати вихід) користувачів, форсуючи повторне введення ними username і password. Деякі використовують це для "time out" логінів, або надають кнопку "log-out".
Приклад 17-2. HTTP аутентифікація, форсує нові name / password
Це поведінка не вимагається стандартом HTTP Basic authentication, тому ви ніколи не повинні залежати від цього. Тестування для Lynx показало, що Lynx НЕ зачищає показники аутентифікації при відповіді 401 сервера, тому натискання back, а потім знову forward, відкриє ресурс, якщо показник аутентифікації не змінилися. Користувач, проте, може натиснути клавішу '_' для очищення його інформацією аутентифікації.
Також зауважте, що це не працює на Microsoft IIS-сервері і з CGI-версією PHP через обмеження IIS.
Примітка: Якщо safe mode включений, uid скрипта додається до частини realm шапки WWW-Authenticate.