Базовая аутентификация | Протокол HTTP

В.3. почему бы просто не переключить кодировку по умолчанию на utf-8?

Сегодня используются сайты, которые по умолчанию используют локальную схему кодировки символов, такую как ISO-8859-1 ([ISO-8859-1]), и ожидают, что пользовательские агенты будут использовать эту кодировку. Аутентификация на этих сайтах перестанет работать, если пользовательский агент переключится на другую кодировку, такую как UTF-8.

Что такое хеширование

Отпечаток (хэш) — это результат работы функции хэширования, которая вернёт для любого значения строку фиксированной длины.Используя специальный математический алгоритм, такая функция умеет преобразовывать любую переданную информацию к строке фиксированной длины (например, 32 или 64 символа).

Причём любому массиву информации, будь это все статьи из Википедии, или одно слово, всегда будет соответствовать уникальный отпечаток. Повторный вызов функции для одного и того же исходника всегда возвращает один и тот же хэш.Обратная операция (получить из отпечатка оригинал) невозможна.

Возьмём простой пример. У нас есть информация, для которой мы хотим получить отпечаток. Пусть такой информацией будет следующая строка:

«Я знаю только то, что ничего не знаю, но другие не знают и этого»

Результат обработки этой строки хэширующей функцией SHA-1 будет таким:6b3cb0df50fe814dee886b4e1c747dda6ce88b37

Хэширующие функции часто используются для контроля целостности информации при передачи по сети. Например, чтобы убедиться в том, что загруженный файл не был повреждён, достаточно получить его хэш и сравнить данный хэш с опубликованным на сайте. Если в файле поменялся хоть один байт, то эти отпечатки будут совершенно разными.Нам же функции хэширования помогут для сравнения паролей.

1. Терминология и обозначения

Ключевые слова «ОБЯЗАН – MUST», «НЕ ОБЯЗАН – MUST NOT», «ТРЕБУЕТСЯ – REQUIRED», «ДОЛЖЕН – SHALL», «НЕ ДОЛЖЕН – SHALL NOT», «СЛЕДУЕТ – SHOULD», «НЕ СЛЕДУЕТ – SHOULD NOT», «РЕКОМЕНДУЕТСЯ – RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ – NOT RECOMMENDED», «ВОЗМОЖЕН – MAY» и «ДОПОЛНИТЕЛЬНО – OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #].

Похожее: Как входить в Windows 10 по паролю с телефона?

Термины “protection space” (пространство защиты) и “realm” (область) определены в разделе 2.2 [RFC7235 #].

Термины «(символьный) репертуар» и «схема кодирования символов» определены в разделе 2 [RFC6365#].

1. «Кодировка» параметр аутентификации

В случае проблем серверы могут использовать параметр аутентификации «charset», чтобы указать схему кодировки символов, которую, как они ожидают, будет использовать пользовательский агент при генерации «прохода пользователя» (последовательность октетов). Эта информация носит исключительно рекомендательный характер.

Единственное допустимое значение – «UTF-8»; он должен сопоставляться без учета регистра (см. [RFC2978 #], раздел 2.3). Это указывает на то, что сервер ожидает, что символьные данные будут преобразованы в форму нормализации Unicode C («NFC»; см.

2. Повторное использование учетных данных

Учитывая абсолютный URI ([RFC3986], раздел 4.3) аутентифицированного запроса, область аутентификации этого запроса получается путем удаления всех символов после последней косой черты (“/”) символа компонента пути (“hier_part”; см.

[ RFC3986], раздел 3). Клиент ДОЛЖЕН предположить, что ресурсы, идентифицируемые URI с совпадением префикса области аутентификации, также находятся в пределах пространства защиты, указанного значением области этого аутентифицированного запроса.

Клиент МОЖЕТ превентивно (в целях профилактики) отправить соответствующее поле заголовка авторизации с запросами ресурсов в этом пространстве без получения другого запроса от сервера. Аналогично, когда клиент отправляет запрос прокси-серверу, он МОЖЕТ повторно использовать идентификатор пользователя и пароль в поле заголовка “Proxy-Authorization” без получения другого запроса от прокси-сервера.

Например, предоставлен аутентифицированный запрос:

2. Информационные ссылки

[ISO-8859-1] International Organization for Standardization, “Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet No. 1”, ISO/IEC8859-1:1998, 1998.

B.1. агенты пользователей

Пользовательские агенты, не использующие ‘charset’, будут продолжать работать, как и раньше, игнорируя новый параметр.

Пользовательские агенты, которые уже используют кодировку UTF-8 по умолчанию, по определению реализуют кодировку.

Другие пользовательские агенты могут сохранять свое поведение по умолчанию и переключаться на UTF-8 при просмотре нового параметра.

B.2. серверы

Серверы, которые не поддерживают символы не-US-ASCII в учетных данных, не требуют каких-либо изменений для поддержки ‘charset’.

Серверы, которые должны поддерживать символы не-US-ASCII, но не могут использовать схему кодирования символов UTF-8, не будут затронуты; они будут продолжать функционировать так же или так же плохо, как и раньше.

Наконец, серверы, которые должны поддерживать символы, отличные от US-ASCII, и могут использовать схему кодирования символов UTF-8, могут включить этот параметр, указав параметр charset в запросе на проверку подлинности. Клиенты, которые понимают параметр charset, затем начнут использовать UTF-8, в то время как другие клиенты будут продолжать отправлять учетные данные в кодировке по умолчанию, с неверными или без учетных данных.

До тех пор, пока все клиенты не будут обновлены для поддержки UTF-8, серверы, вероятно, будут видеть как UTF-8, так и «устаревшие» кодировки в запросах. Когда происходит сбой обработки как UTF-8 (из-за сбоя декодирования как UTF-8 или несоответствия идентификатора пользователя / пароля), сервер может попытаться выполнить откат к ранее поддерживаемой унаследованной кодировке для размещения этих устаревших клиентов.

Cookies

Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру.Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя, идентифицировать его.

Аутентификация

Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов.Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.

Процедура проверки возможности доступа пользователя к определенной части сайта и называется аутентификацией.Весь процесс аутентификации всегда состоит из нескольких шагов:

Выход с сайта

Если на сайте есть вход, то должен быть и выход. Таким выходом будет специальный сценарий, который очистит сессию и переадресует на главную страницу.Чтобы очистить сессию, достаточно очистить массив $_SESSION:$_SESSION = []

Глава 4. аутентификация, часть 1

Аутентификация с помощью ключа API — это метод, который преодолевает слабость использования общих учетных данных, требуя доступа к API с помощью уникального ключа. В этой схеме ключ обычно представляет собой длинную последовательность букв и цифр, отличную от пароля для входа владельца учетной записи. Владелец дает ключ клиенту, так же как отель дает гостю ключ от одноместного номера.

Когда клиент аутентифицируется с помощью ключа API, сервер понимает, что можно разрешить клиенту доступ к данным, но теперь имеет возможность ограничить административные функции, такие как изменение паролей или удаление учетных записей. Иногда ключи используются просто, чтобы пользователю не приходилось выдавать свой пароль. Гибкость обеспечивается аутентификацией API Key для ограничения контроля, а также защиты паролей пользователей.

Итак, где же находится ключ API? Заголовок для него тоже есть, да? К сожалению, нет. В отличие от Basic Auth, который является установленным стандартом со строгими правилами, ключи API были разработаны в нескольких компаниях на заре интернета. В результате аутентификация с помощью ключа API немного похожа на дикий запад; у каждого свой способ делать это.

Однако со временем появилось несколько общих подходов. Один из них заключается в том, чтобы клиент поместил ключ в заголовок Авторизации вместо имени пользователя и пароля. Другой — добавить ключ в URL-адрес (http://example.com? api_key=my_secret_key ). Реже ключ закапывают где-нибудь в теле запроса рядом с данными. Куда бы ни пошел ключ, эффект будет одинаковым — он позволяет серверу аутентифицировать клиента.

Ещё немного терминологии

Следует различать два термина: аутентификация и авторизация.

Как прочитать куки

В PHP максимально упрощён процесс чтения информации из кукисов. Все переданные сервером куки становятся автоматически доступны в специальном глобальном массиве $_COOKIEТак, чтобы получить содержимое куки с именем «visit_count», достаточно обратиться к одноимённому элементу массива $_COOKIE, например вот так:

Обратите внимание: установив в сценарии куку через setcookie, прочитать её можно будет только при следующем посещении страницы.

Как установить куки: функция setcookie

Являясь серверным языком программирования, PHP может управлять заголовками, которые отправляет сервер, а значит может устанавливать и читать куки.Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:

Название этой куки (может состоять только из символов латинского алфавита и цифр);
Значение, которое предполагается хранить;
Срок жизни куки — это обязательное условие.

За установку куки в PHP отвечает функция setcookie, ей нужно передать как минимум три параметра, описанных выше. Пример:

Обратите внимание, что срок жизни указывается в относительной величине. В этом примере кука будет существовать ровно 30 дней с момента установки.

Как устроены сессии

PHP генерирует уникальный идентификатор браузера.
Идентификатор сохраняется в специальную куку и передаётся с каждым запросом.
Все данные, которые записываются в сессию, PHP автоматически сохраняет в специальном файле на сервере.

Благодаря существованию сессий в PHP, мы можем сохранять любые данные так же просто, как присваивать их переменным. Но, в отличие от переменных, эти данные будут сохраняться для пользователя между запросами в пределах сеанса.

Перепишем сценарий для подсчета посещений, но теперь используем сессии:

Приложение а. изменения по сравнению с rfc 2617

Определение схемы было переписано, чтобы соответствовать более новым спецификациям, таким как [RFC7235 #].

Был добавлен новый параметр аутентификации “charset”. Он носит исключительно рекомендательный характер, поэтому существующие реализации не нужно менять, если только они не хотят воспользоваться дополнительной информацией, которая ранее была недоступна.

Пример

Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.

Реализация регистрации пользователя

Вернёмся к форме регистрации.Выше говорилось, что вместо пароля лучше хранить его отпечаток. Для получения отпечатка существуют множество хэшируюших функций. К счастью, нам не надо разбираться в их многообразии, потому что в PHP есть стандартная функция, которая делает ровно то, что нужно.Вот пример как из пароля получить отпечаток, пригодный для хранения в базе:

$passwordHash = password_hash('iloveponies', PASSWORD_DEFAULT);

Вызов этой функции вернёт следующую строку: $2y$10$a1pgDBerBsqD24D7qOAsl.QFTvwxQQGe4r1oWhD7f9yEnDvx4i7tWИменно это значение и следует хранить в БД, вместо пароля.

Регистрация на сайте

Перед тем, как мы начнем добавлять аутентификацию на своем сайте, придётся добавить форму для регистрации нового аккаунта.Аккаунт — это учётная запись пользователя.Чтобы завести аккаунт, требуется пройти регистрацию — это заполнение специальной формы, где пользователь указывает свою почту, пароль, и, возможно, дополнительную информацию.

Сессии

Мы уже умеем сохранять информацию для пользователя между посещениями страницы с помощью кук. Но зачем же нам ещё сессии, и для чего они нужны?Сессии, они же сеансы, это, по сути, просто удобная обёртка над куками. Они также позволяют хранить данные, релевантные пользователю, но с некоторыми отличиями и ограничениями:

Данные хранятся не произвольное время, а только до закрытия вкладки с веб-страницей.
Чтобы сессии работали, в начале каждого сценария надо вызывать функцию session_start().
Доступный объём для хранения информации намного больше.

Запись и чтение информации при использовании сессий выглядит просто как работа со специальным массивом $_SESSION.

Собираем всё вместе

Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.