Авторизация html: Как сделать адаптивную форму входа авторизации

В дизайне интерфейса сайта Zlato.ua соблюдены привычные паттерны размещения элементов входа в личный кабинет

2. Реализуйте авторизацию и регистрацию в одно окно

От 20% до 60% пользователей часто восстанавливают пароли, потому что забывают их. Поэтому стоит использовать одноразовый пароль. Реализуйте авторизацию и регистрацию в одно окно — пользователь вводит свои данные и если он зарегистрирован, то авторизуется, а если нет — то регистрируется. Таким образом вы проявите заботу о клиенте, сделаете процесс проще и безопаснее.

Пример реализации регистрации и авторизации в одно окно на сайте Infoshina

Вот еще несколько решений, которые помогут упростить и ускорить регистрацию и авторизацию на сайте:

• Если пользователь ошибся, обязательно укажите поле, где допущена ошибка (логин, формат телефона и т.д.).
• Внедрите функционал для проверки правильности введения данных еще до отправки формы.

Например, на сайте Zlato.ua пользователь может просмотреть пароль для проверки правильно ли он его ввел или нет до того, как нажмет на кнопку «Войти»

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

3. Предложите авторизацию по номеру телефона

Все больше пользователей предпочитают авторизацию на сайте по номеру телефона, а не через email. Это дополнительная причина использовать одноразовый пароль для авторизации.

Пример реализации регистрации и авторизации в одно окно по номеру телефона на сайте Pratik

В этом случае на указанный пользователем номер телефона приходит SMS с кодом-паролем для входа в личный кабинет. Это и безопасно, и удобно — пользователь подтверждает вход с телефона и при этом ему не надо ничего запоминать. Также можно использовать различные популярные мессенджеры для отправки кода — выберите тот, который максимально удобен именно вашей целевой аудитории.

Так вы уменьшаете порог вхождения новых и постоянных пользователей, что положительно влияет на основные KPI интернет-магазина.

4. Реализуйте авторизацию через социальные сети

Согласно статистике, для авторизации на сайте 44,8% пользователей используют Google и 53% — Facebook. Такой способ авторизации поможет сократить путь пользователя и максимально упростить процесс регистрации и авторизации.

Пример различных вариантов авторизации на сайте Antoshka

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

Но стоит также учесть некоторые нюансы:

• Есть вероятность, что клиент забудет какую именно социальную сеть для авторизации он использовал ранее;
• При удалении аккаунта в социальной сети, пользователь не сможет войти в личный кабинет на вашем сайте.

5. Сохраняйте положение пользователя

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

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

Реализация авторизации без перехода в отдельное окно и с сохранением положения пользователя на сайте ТехноЁж

9 практических советов по оптимизации регистрации на сайте

1. Не требуйте регистрацию

37% пользователей не станут оформлять заказ и уйдут к конкуренту из-за необходимости регистрации. Поэтому сделайте регистрацию необязательной, предоставив пользователям возможность выбора.

Например, при заказе на сайте 966.ua пользователь может выбрать Быструю покупку или Заполнить подробную форму

Также стоит избегать таких формулировок, как «Регистрация» и «Авторизация», замените их на «Войти», «Личный кабинет», «Новый клиент» и т.д.

Пример предложения регистрации на сайте MonAmie

2. Покажите преимущества регистрации

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

Сообщите о преимуществах зарегистрированных пользователей, чтобы убедить пользователя заполнить форму:

• История заказов с возможностью повторить их;
• Проверка статуса заказа;
• Сохранение адресов доставки, контактов получателей, способов оплаты и т.д.;
• Начисление бонусов за покупки, программа лояльности, личная скидка;
• Сохранение понравившихся товаров в «Избранное»;
• История просмотров;
• Участия в закрытых акциях;
• Получение рассылки со специальными и эксклюзивными предложениями, информацией о распродажах, акциях, скидках на интересующие их товары, и прочее.

Пример формы регистрации на сайте Pampikс демонстрацией преимуществ 

3.

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

4. Максимально сократите количество полей в форме регистрации

Не акцентируйте внимание на полях формы регистрации и минимизируйте их количество. Стоит визуально выделить обязательные поля, а лучше запросить остальную информацию о пользователе уже после регистрации. Например, узнайте фамилию в поле «Получатель» при оформлении заказа, так покупатель будет понимать для чего вам нужна данная информация.

Пример реализации регистрации на сайте Zlato. ua

5. Сделайте акцент на эксклюзивности

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

Пример реализации сообщества в детском интернет-магазине Антошка

6. Откажитесь от капчи

Согласно исследованию, только 66% пользователей смогут ввести капчу без ошибок с первого раза, при этом после двух неудачных попыток подряд, пользователь просто уйдет. Так даже хорошо реализованная капча приводит к потере клиентов. Поэтому от нее стоит либо отказаться, либо использовать скрытую капчу.

Но в случае, если она необходима, то следует взять во внимание следующие советы:

• Используйте хорошо различимые и читаемые буквы и символы;
• Не делайте капчу чувствительной регистру;
• Не очищайте содержимое полей, если пользователь ошибся при вводе капчи;
• Запрашивайте введение капчи только один раз за весь сеанс.

7. Сохраняйте внесенные данные при ошибке

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

8. Откажитесь от необходимости активировать аккаунт

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

9. Пишите понятные заголовки в рассылке

Если пользователь забыл пароль, первое, что он попробует сделать — это найти приветственное письмо со всеми регистрационными данными. Облегчите задачу пользователю, сделав понятную тему письма с указанием названия интернет-магазина и пометкой о чем email. Например: «Регистрационные данные в …». Используйте название вашего интернет-магазина в поле отправителя.

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

• Сделать регистрацию необязательной или фоновой;
• Реализовать регистрацию и авторизацию в одно окно;
• Внедрить регистрацию по номеру телефона с одноразовым кодом-паролем;
• Предложить регистрацию и авторизацию через соцсети.

• авторизация и регистрация на сайте
• увеличения конверсии
• онлайн бизнес
• конверсия интернет магазина
• интерфейс сайта

Підпишіться і будьте в курсі

новин UI / UX і e-commerce

Авторизация пользователей на сайте через Flask-Login

Смотреть материал на видео

Файл проекта: https://github. com/selfedu-rus/flasksite-16

На предыдущем занятии мы с вами добавили регистрацию пользователей. Теперь пришло время сделать их авторизацию. Общий смысл авторизации заключается в том, что на сайте имеются страницы, которые доступны как всем пользователям, так и те, которые доступны только авторизованным пользователям.

Конечно, мы можем самостоятельно реализовать весь этот функционал, используя сессии и куки, о работе которых вы уже знаете. Но это долгий путь. И, так как задача типовая, то для Flask был разработан специальный модуль

Flask-Login

который значительно упрощает эту задачу. Им мы и воспользуемся. Сначала его нужно установить. Это делается с помощью команды:

pip install flask-login

И, далее, импортировать его, а точнее, класс LoginManager, который управляет процессом авторизации:

from flask_login import LoginManager

Ну и, затем, создать экземпляр этого класса, например, так:

login_manager = LoginManager(app)

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

Далее, в обработчике авторизации пользователя создается объект класса UserLogin и передается специальной функции login_user, которая определена в модуле Flask-Login:

Данная функция заносит в сессию информацию о зарегистрированном пользователе, используя определенные в классе методы. После этого сессионная информация будет присутствовать во всех запросах к серверу. Для ее обработки во Flask-Login определен специальный декоратор:

@login_manager.user_loader
def load_user(user_id):
    print("load_user")
    return UserLogin().fromDB(user_id, dbase)

Причем функции load_user этого декоратора будет передан идентификатор пользователя, который присутствует в сессии запроса. Фактически, это будет user_id, который возвращается методом get_id класса UserLogin.

Зная этот идентификатор, мы можем обратиться к БД, прочитать данные этого пользователя и создать экземпляр класса UserLogin на основе прочитанных данных. Благодаря этому, у нас при каждом запросе в системе гарантированно будет объект класса UserLogin, с которым мы сможем в дальнейшем спокойно работать.

Также следует иметь в виду, что функция декоратора user_loader вызывается после функции декоратора

before_query

это гарантирует нам наличие подключения к БД в функции load_user, в которой используется переменная dbase.

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

@app. route("/post/<alias>")
@login_required
def showPost(alias):
…

И теперь страница доступна только авторизованным посетителям сайта.

Давайте теперь в нашей программе реализуем эту концепцию. После создания экземпляра класса LoginManager добавим в наш проект еще один файл UserLogin.py, в котором пропишем вспомогательный класс UserLogin:

class UserLogin:
    def fromDB(self, user_id, db):
        self.__user = db.getUser(user_id)
        return self
 
    def create(self, user):
        self.__user = user
        return self
 
    def is_authenticated(self):
        return True
 
    def is_active(self):
        return True
 
    def is_anonymous(self):
        return False
 
    def get_id(self):
        return str(self.__user['id'])

Здесь первый метод fromDB используется при создании объекта в декораторе user_loader. Он по user_id выполняет загрузку пользовательских данных из БД и сохраняет в частном свойстве __user. Второй метод create используется при создании объекта в момент авторизации пользователя. Вся информация о нем уже известна и мы ее просто передаем по ссылке user и также сохраняем в частной переменной __user. Эта информация потом пригодится в методе get_id, который возвращает id текущего пользователя.

Далее, нам нужно сразу же определить метод getUser в классе FDataBase. Он будет следующий:

    def getUser(self, user_id):
        try:
            self.__cur.execute(f"SELECT * FROM users WHERE id = {user_id} LIMIT 1")
            res = self.__cur.fetchone()
            if not res:
                print("Пользователь не найден")
                return False 
 
            return res
        except sqlite3.Error as e:
            print("Ошибка получения данных из БД "+str(e))
 
        return False

Все предельно просто. Мы извлекаем из таблицы users все поля для указанного id пользователя и, затем, возвращаем прочитанные данные. Если данные прочитать не удалось, то метод возвращает значение False.

После объявления класса UserLogin, мы можем его использовать в нашей основной программе. Сначала сделаем его импорт:

from UserLogin import UserLogin

а, затем, пропишем декоратор

@login_manager.user_loader
def load_user(user_id):
    print("load_user")
    return UserLogin().fromDB(user_id, dbase)

Как мы отмечали, здесь будет создаваться объект UserLogin при каждом запросе, если пользователь авторизован. Если не авторизован, то функция вызываться не будет.

Ну и, наконец, самое главное – прописать обработчик для авторизации пользователя. Я его приведу в таком упрощенном виде:

@app.route("/login", methods=["POST", "GET"])
def login():
    if request.method == "POST":
        user = dbase.getUserByEmail(request.form['email'])
        if user and check_password_hash(user['psw'], request. form['psw']):
            userlogin = UserLogin().create(user)
            login_user(userlogin)
            return redirect(url_for('index'))
 
        flash("Неверная пара логин/пароль", "error")
 
    return render_template("login.html", menu=dbase.getMenu(), title="Авторизация")

Здесь сначала идет проверка: если данные были переданы из формы авторизации, то мы обращаемся к БД и считываем информацию о пользователе, опираясь на указанный в форме email. Если данные из БД были прочитаны успешно и верно введен пароль, то формируется объект класса UserLogin и вызывается функция login_user. С этого момента пользователь считается авторизованным. Далее идет перенаправление на главную страницу сайта. Если какие-либо проверки не прошли, то формируется мгновенное сообщение и снова отображается форма авторизации.

И последнее, что мы сделаем перед пробным запуском, это ограничим доступ к страницам статей неавторизованным посетителям:

@app. route("/post/<alias>")
@login_required
def showPost(alias):
    title, post = dbase.getPost(alias)
    if not title:
        abort(404)
 
    return render_template('post.html', menu=dbase.getMenu(), title=title, post=post)

Все, теперь при запуске мы можем авторизовываться и просматривать статьи только в этом состоянии.

Видео по теме

Flask #1: Что это такое? Простое WSGI-приложение

Flask #2: Использование шаблонов страниц сайта

Flask #3: Контекст приложения и контекст запроса

Flask #4: Функция url_for и переменные URL-адреса

Flask #5: Подключение внешних ресурсов и работа с формами

Flask #6: Мгновенные сообщения — flash, get_flashed_messages

Flask #7: Декоратор errorhandler, функции redirect и abort

Flask #8: Создание БД, установление и разрыв соединения при запросах

Flask #9: Добавление и отображение статей из БД

Flask #10: Способ представления полноценных HTML-страниц на сервере

Flask #11: Формирование ответа сервера, декораторы перехвата запроса

Flask #12: Порядок работы с cookies (куками)

Flask #13: Порядок работы с сессиями (session)

Flask #14: Регистрация пользователей и шифрование паролей

Flask #15: Авторизация пользователей на сайте через Flask-Login

Flask #16: Улучшение процесса авторизации (Flask-Login)

Flask #17: Загрузка файлов на сервер и сохранение в БД

Flask #18: Применение WTForms для работы с формами сайта

Flask #19: Обработка ошибок во Flask-WTF

Flask #20: Blueprint — что это такое, где и как использовать

Flask #21: Blueprint — подключение к БД и работа с ней

Flask #22: Flask-SQLAlchemy — установка, создание таблиц, добавление записей

Flask #23: Операции с таблицами через Flask-SQLAlchemy

Web-авторизация для домашнего интернета билайн Москва

Вы в Москве?

Частным лицам

• Бизнесу
• Партнёрам
• Госсектору
• Операторам
• Поставщикам и партнёрам
• Офисы и покрытие
• Помощь и поддержка
• Корзина
• Мобильная связь
• Интернет и ТВ
• Пополнить счёт
• Телефоны

Вы в Москве?

org/BreadcrumbList» data-=»»>
• Частным лицам
• Помощь и поддержка
• Домашний билайн
• Домашний интернет
• Web-авторизация

 Домашний интернет

Что это?

Технология предоставления доступа в интернет, не требующая специфических настроек соединения. Особенность – для получения доступа в Интернет нужна однократная авторизация на веб-странице.

В чем различия между L2TP VPN (текущая схема получения доступа) и новой технологией «Web-авторизация»?
• Не нужно настраивать соединение, достаточно авторизоваться на веб-странице один раз (повторная авторизация нужна только при смене устройства или квартиры)
• Низкая нагрузка на роутер
• Работает одинаково на всех операционных системах, которые поддерживают протокол DHCP (автоматическое получение IP-адреса) и имеют браузер. Нужные настройки уже установлены по умолчанию.
Начало использования (без роутера)
1. Подключить интернет-кабель Билайн в ПК
2. Запустить браузер, открыть любую страницу, например http://ya.ru. Будет выполнена переадресация на страницу «Вход в домашний интернет Билайн».
3. Заполнить форму, введя логин и пароль в соответствующие поля.
4. После успешной авторизации пользоваться интернетом.
Начало использования (с роутером)
1. Подключить Интернет-кабель Билайн в порт WAN (Internet) на роутере.
2. Соединить ПК и роутер с помощью кабеля или по Wi-Fi. С инструкциями по настройке Wi-Fi сети вы можете ознакомиться в разделе Настройка роутера.
3. Запустить браузер, открыть любую страницу, например http://ya.ru. Будет выполнена переадресация на страницу «Вход в домашний интернет Билайн».
4. Заполнить форму, введя логин и пароль в соответствующие поля.
5. После успешной авторизации пользоваться интернетом.
Что делать, если ничего не работает?
• Удостоверьтесь, что настройки ПК выполнены верно. Для этого на странице Как настроить подключение воспользуйтесь инструкцией «Настройка компьютера для подключения к локальной сети».
• Выключите и включите ПК.
• Если вы используете роутер, его нужно выключить и включить. Если не помогло, попробуйте сбросить его на настройки по умолчанию и настроить заново. Для этого зажмите на 30 секунд зубочисткой, спичкой или скрепкой кнопку reset на задней панели устройства. После чего настройте на нем Wi-Fi соединение. Инструкции можно найти в разделе Настройка роутера.

Домашний интернет

Другие статьи этого раздела:

Инструкции по самообслуживанию

Мастер настроек

Договор об оказании услуг

Управление услугами

Настройка роутера

Интернет по технологии GPON

Как настроить подключение

Проблемы и ошибки при попытке подключения к удаленному рабочему месту

Самодиагностика интернета

Инструкции по подключению устройств к Wi-Fi-сети роутера

О моем тарифе

Актуализация тарифных планов и опций

Переезд

Тарифы на Домашний интернет в Москве

для дома 100 ›

100

Мбит/сек

Wi-Fi-роутер

не входит в тариф

?

В тариф не входит Wi-Fi-роутер. Вы можете взять Wi-Fi-роутер в аренду за 150,00 ₽/мес!

500 ₽/месяц

для дома 300 Акция ›

300

Мбит/сек

Wi-Fi-роутер

не входит в тариф

?

В тариф не входит Wi-Fi-роутер. Вы можете взять Wi-Fi-роутер в аренду за 150,00 ₽/мес!

600 ₽

-17% на 3 месяца

500 ₽/месяц

для дома 500 ›

500

Мбит/сек

Wi-Fi-роутер

не входит в тариф

?

В тариф не входит Wi-Fi-роутер. Вы можете взять Wi-Fi-роутер в аренду за 150,00 ₽/мес!

800 ₽/месяц

Домашний интернет с ТВ и мобильной связью еще выгоднее

++Домашний интернет
с ТВ и мобильной связью

Инструкция по авторизации на сайте

Статья

инструкция пользователяпомощь

Борисов Дмитрий Александрович, кандидат экономических наук, эксперт Федеральной антимонопольной службы России по развитию конкуренции в здравоохранении и образовании

Процедура установки пароля и авторизации на сайте

01 Июля 2018Выделить главное вкл выкл 2670

Доступ к разделу «Только для участников» предоставляется только авторизованным пользователям

См. условия доступа к разделу «Только для участников»

Для доступа к данному разделу необходимо использовать логин (адрес электронной почты), указанный в базе сайта, и пароль, который Вы можете установить самостоятельно (или который Вам предоставлен).

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

Если Ваша электронная почта, адрес которой указан в базе сайта, создана на Яндексе или Mail.Ru, то Вы можете авторизоваться без прохождения процедуры регистрации и установки пароля, используя технологию OAuth 2.0, поддерживаемую Яндексом и Mail.Ru. Для этого после выполнения 1-го шага инструкции перейдите к 9 пункту. Если это Ваша личная эл. почта, то чтобы Ваши коллеги могли заходить на сайт лучше установить пароль для сайта (см. пункты 1 — 8 инструкции), а адрес эл. почты использовать в качестве логина.

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

Если пользователь в предыдущем сеансе авторизовался на данном сайте и не нажимал на ссылку ‘Выйти’, а также не входил с другого устройства, то для доступа достаточно нажать на ссылку ‘Войти’

Инструкция пользователя

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

1. Нажмите пункт меню «Войти»

2. Введите адрес электронной почты, пароль и нажмите кнопку «Войти»

3. После успешной авторизации вы увидите в меню адрес электронной почты

Если вы не видите в меню адрес электронной почты, то вы авторизовались с адресом электронной почты, которого нет в базе сайта, доступ по нему к закрытому разделу невозможен.

Необходимо нажать кнопку «Выйти», затем на следующей странице также нажать кнопку «Выйти»

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

4. Для установки пароля выполните пункт 1 настоящей инструкции, введите адрес электронной почты и нажмите кнопку «Регистрация»

5. Введите код на картинке и нажмите кнопку «Регистрация»

6. На почту придет ссылка для установки пароля

7. Введите новый пароль, подтверждение и нажмите кнопку «Установить пароль»

8. Если вам необходима техническая поддержка напишите на почту csi-pz@mail. ru, укажите в теме письма фразу «Доступ к сайту» и название организации, приложите скриншоты.

9. Вы можете авторизоваться без прохождения процедуры регистрации, используя технологию OAuth 2.0, поддерживаемую Яндексом и Mail.Ru. Для этого выполните пункт 1 инструкции, нажмите нассылку Yandex или Mail.Ru

См. окно Yandex’а

См. окно Mail.Ru

После авторизации выполните для контроля пункт 3 инструкции

10. Подробнее о поддержке данной технологии Яндексом и Mail.Ru

Технология OAuth 2.0 разработана, чтобы избавить пользователей от процедуры регистрации на многочисленных интернет-ресурсах и необходимости помнить имена и пароли к каждому ресурсу.

В общих чертах процесс авторизации пользователя выглядит следующим образом:

наш ресурс посылает запрос на Яндекс или Mail.Ru, действительно ли пользователь с данным именем имеет учетную запись;

Яндекс или Mail. Ru проверяет это, запросив у пользователя его логин и пароль, т.е. попросив авторизоваться;

логин и пароль передаются только между Вами и Яндексом или Mail.Ru, наш ресурс про них ничего не знает;

единственная информация, которую запрашивает наш ресурс у Яндекса или Mail.Ru, — это адрес электронной почты, по которому идентифицируется пользователь;

если авторизация прошла успешно, то Яндекс или Mail.Ru подтверждает запрос, и наш ресурс авторизует пользователя у себя, вместо формы регистрации появится Ваш адрес электронной почты и кнопка «Выйти»;

Важно: после авторизации Яндекс и Mail.Ru автоматически направляют Вас на наш сайт, при этом сохраняя постоянную авторизацию, поэтому Вы возможно захотите зайти на Яндекс или Mail.Ru, чтобы сбросить авторизацию — выйти оттуда, при этом авторизация на нашем ресурсе сохранится, пока Вы не нажмете кнопку «Выйти».

Как настроить регистрацию на сайте через соцсети

Рабочие способы подключить на сайт возможность авторизации через социальные сети.

В статье:

• Чем так хороши соцсети для регистрации
• Требования к сайту по защите личных данных
• Как добавить регистрацию через профиль в соцсети на сайт:
  • вручную настроить формы для каждой сети;
  • использовать сервисы;
  • установить плагины для CMS.

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


Но для пользователя регистрация на сайте — дополнительная нагрузка, так что веб-мастер должен предложить ему удобные и быстрые варианты. Обычно дают на выбор авторизоваться в системе через email, номер телефона или профиль в социальной сети.

Регистрация на asos.com

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

От этого способа авторизации выигрывают и клиенты, и владелец сайта.

Удобно клиентам: меньше заполнять, быстрее регистрация, учетка не теряется

Еще в 2013 году исследование показало, что 77% пользователей считают вход через соцсети хорошим решением. А в 2016 году другие исследователи выяснили, что 93% пользователей чаще выбирают способ авторизации через соцсеть. Остальные опрошенные либо не были зарегистрированы в соцсетях, либо не хотят передавать сайту личные данные профиля, для них нужно оставить возможность авторизации через email.

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

После того, как платформа для email-рассылок Mailchimp внедрила авторизацию через соцсети, количество неудачных попыток входа в систему снизилось на 66%. С этим способом меньше вероятность забыть логин и пароль, потому что не нужно запоминать отдельную учетку.

Полезно компании: можно собирать данные, больше вероятность репостов

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

Также авторизация через соцсети упрощает репосты материалов с сайта, а значит увеличивает конверсию и реферальный трафик.

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

Требования к сайту по защите личных данных

В ФЗ N152-ФЗ «О персональных данных» описаны правила для законного сбора и обработки данных пользователей. За нарушения предусмотрены штрафы.

Список требований:

1. Сайт должен работать на HTTPS, то есть ему нужен ssl-сертификат.

2. Хостинг сайта по закону должен находиться на территории РФ.

3. До публикации сайта владелец или разработчик должен подать в Роскомнадзор уведомление об обработке персональных данных в бумажном или электронном виде.

На сайте должны быть:

• согласие на обработку персональных данных в свободной форме;

• либо ссылка на единую публичную оферту, но тогда придется хранить логи на случай требования Роскомнадзора доказать посещение сайта пользователем;

• документ с политикой в отношении обработки персональных данных с перечислением информации, которые собирает сайт, и обоснованием необходимости;

• уведомление о сборе cookies и других данных.

Google намерен прекратить поддержку в Chrome сторонних файлов cookie. Как это повлияет на работу сайтов, разбирали в статье.

Ссылки на документы на сайте ikea.ru

С 1 марта 2021 года вступил в силу ФЗ от 30.12.2020 № 519-ФЗ об изменении правил обработки общедоступных персональных данных, которые есть в профилях соцсетей и на сайтах объявлений. Это имя, город проживания, контакты, личные фото и другая информация.

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

Настройки cookie на booking.com

Если владелец сайта — юридическое лицо, к нему есть дополнительные требования относительно документации, штрафы за несоблюдение закона сильно выше.

Как добавить на сайт регистрацию через профили в соцсетях

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

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

Авторизация через соцсети идет по цепочке:

1. Пользователь выбирает регистрацию через одну из предложенных соцсетей и кликает на ее кнопку.

2. В приложение социальной сети приходит запрос.

3. Пользователя перебрасывает в закрытое защищенное приложение соцсети, которое создал веб-мастер. На экране появляется кнопка «Продолжить как…» или «Разрешить».

4. По клику пользователь разрешает войти в систему через учетную запись соцсети. Кликнул — разрешил передать данные.

5. Соцсеть отправляет сайту ключ доступа к личным данным пользователя.

6. Сайт отправляет соцсети запрос на получение данных и подтверждает его полученным ранее ключом доступа.

7. Соцсеть передает данные сайту. Количество данных может быть разным из-за того, что пользователь разрешит передать.

Для добавления регистрации через соцсети есть несколько способов — ручной и автоматизированные.

Способ 1. Ручная настройка форм для каждой социальной сети

Каждая соцсеть требует отдельных настроек:

ВКонтакте

Настроить авторизацию на сайте через ВКонтакте можно с помощью API. На странице создания приложения заполните поля, в качестве платформы выберите «Сайт».

Создание приложения

Нажмите «Подключить сайт», действие нужно подтвердить через телефон или устройство с приложением. В настройках вы увидите id приложения и ключ — эти данные понадобятся для работы с API.

Список дальнейших действий подробно разобран на странице Документации для разработчиков.

Если вам нужен только ВКонтакте, можно использовать официальный виджет авторизации. На странице создания виджета нужно заполнить поля и скопировать код для вставки на сайт. Подробная документация расскажет, как правильно его вставить.

Виджет для входа через сайт ВКонтакте

Фейсбук*

Зарегистрируйтесь в системе Фейсбука* для разработчиков, кликните на «Создать приложение» и выберите «Создание кросс-сервисных функций:

Дальше после заполнения полей и клика на «Создать приложение» откроются настройки. Выберите «Настроить» у плашки «Вход через Facebook*». Дальше выберите платформу — Веб, введите адрес сайта, сохраните и нажмите продолжить.

Теперь надо все настроить. Откройте настройки приложения на боковой панели, добавьте добавьте домен сайта, URL политики конфиденциальности и пользовательского соглашения.

Фейсбук* придерживается общего регламента по защите данных (GDPR), согласно ему у пользователей должна быть возможность сделать запрос на удаление данных. В пункте «Удаление данных пользователей» выберите «URL инструкций для удаления данных» и вставьте ссылку на описание таких инструкций. Это обязательный пункт.

Все сохраните, Скопируйте ID приложения и секрет.

В меню настроек вашего сайта нужно найти настройку авторизации через соцсети, выбрать Фейсбук* и ввести ID приложения и код секрета.

Дальше откройте настройки главы «Вход через Фейсбук*»:

В настройках должны быть отметки «Да» у опций «Клиентская авторизация Oauth», «Веб-авторизация Oauth», «Требовать HTTPS» и «Использовать строгий режим для URI перенаправления». В поле «Действительные URI перенаправления для OAuth» нужна ссылка в формате http://site.ru/auth/facebook/callback. OAuth — это единый стандарт авторизации.

Сохраните изменения. Вверху вы увидите «Статус: в разработке», его нужно активировать, чтобы он сменился на «Опубликовано».

Другие соцсети настраиваются по похожему механизму с помощью API. К примеру, в Одноклассниках тоже надо начать с создания приложения, у Твиттера также есть платформа для разработчиков. Быстрее это можно сделать через инструменты или плагины.

Способ 2. Сервисы для настройки авторизации через соцсети

Это не все существующие сервисы, но более-менее популярные из тех, что нам встретились, по большей части платные. Если вы используете что-то из перечисленного, дайте свой отзыв в комментариях!

ULogin

Простой генератор универсального кода для вставки виджета авторизации через соцсети. Нужно выбрать внешний вид, найти из списка CMS вашего сайта или выбрать универсальный вариант для всех и код виджета готов. Русскоязsчный.

Akamai

Более серьезный сервис. Поможет настроить авторизацию через Фейсбук*, LinkedIn, PayPal, Твиттер и Yahoo!, есть функциональность для сбора и анализа информации из пользовательских профилей. Интерфейс на английском.

Gigya

Подходит для установки регистрации через ВКонтакте, Facebook, Twitter и LinkedIn,интеграции с другими сервисами и платформами, а также для обработки статистики по зарегистрированным пользователям. Интерфейс на английском.

Способ 3. CMS-плагины для регистрации на сайте через соцсети

Если пользуетесь CMS, можно поискать решение через модули и расширения в каталогах.

WordPress

Для этого движка есть много расширений, к примеру:

• miniOrange Social Login для регистрации через ВКонтакте, Твиттер, Инстаграм*, Фейсбук* и другие соцсети. Есть дополнительные премиальные возможности, например, отправка приветственных писем зарегистрировавшимся;

• Social Login & Register тоже предлагает много соцсетей, среди которых ВКонтакте, Фейсбук*, Инстаграм*, Твиттер и другие. Есть возможность аналитики данных пользователей;

• Social Login by BestWebSoft для добавления формы авторизации через соцсети и комментирования. Работает с Фейсбуком*, Твиттером, аккаунтом Google и LinkedIn;

• Super Socializer включает в себя не только авторизацию, но и возможность делать репосты и комментировать контент на сайте через профили в соцсетях.

Joomla

Модулей авторизации довольно много, а работа с ними одинаковая: установить модуль, зарегистрировать специальное приложение в соцсети и получить ключи, как мы писали в примерах с ВКонтакте и Фейсбуком*, добавить эти данные в настройки модуля и опубликовать.

Модули можно найти в разделе Расширения — Менеджер расширений. Например:

• Slogin для регистрации через ВКонтакте, Твиттер, Фейсбук*, Одноклассники, Инстаграм*, Twitch, Telegram, Github и другие платформы;

• Social Login — ВКонтакте, Фейсбук*, Твиттер, Pinterest, LinkedIn, Инстаграм*, GitHub, WordPress, Reddit, Vimeo, Steam, Mail.ru, Яндекс, Одноклассники и другие соцсети;

• Instant Facebook* Login для Фейсбука*, Твиттера и LinkedIn, дополнительно с его помощью можно работать с комментариями, чатом и другими функциями;

• BT Social Login для Фейсбука* и Твиттера;

• Akeeba SocialLogin для регистрации с помощью Фейсбука* и Твиттера или через профили в GitHub, Google и Microsoft.

OpenCart

Для OpenCart тоже есть модули, к примеру:

• бесплатный модуль авторизации через социальные сети Фейсбук* и Инстаграм* для версий OpenCart 2.1, 2.2, 2.3;

• платный модуль для регистрации через ВКонтакте, Фейсбук*, Одноклассники, Твиттер, Gmail.com, Mail.ru.

Битрикс

У CMS Битрикс авторизация на сайте через социальные сети входит в функциональность основного модуля входа на сайт.

Нужно только настроить:

1. В выбранных вами соцсетях нужно зарегистрировать приложение и получить ключи.

2. В настройках Битрикса открыть Настройки модулей — Социальные сервисы — Внешние сервисы, выбрать нужные соцсети и внести данные в настройки панели администрирования.

Посоветуйте плагины и сервисы, которые вам нравится использовать для настройки авторизации через соцсети! Ждем в комментариях.

---

*Компания Meta, которой принадлежит Instagram и Facebook, признана в России экстремистской организацией.

Авторизация — HTTP | MDN

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

Заголовок Authorization обычно, но не всегда, отправляется после первой попытки пользовательского агента запросить защищенный ресурс без учетных данных. Сервер отвечает сообщением 401 Unauthorized , которое включает как минимум один Заголовок WWW-Authenticate . Этот заголовок указывает, какие схемы аутентификации можно использовать для доступа к ресурсу (и любую дополнительную информацию, необходимую клиенту для их использования). Пользовательский агент должен выбрать наиболее безопасную схему аутентификации, которую он поддерживает, из предложенных, запросить у пользователя его учетные данные, а затем повторно запросить ресурс (включая закодированные учетные данные в заголовке Authorization ).

Примечание: Этот заголовок является частью общей структуры проверки подлинности HTTP. Его можно использовать с рядом схем аутентификации.

Тип заголовка	Заголовок запроса
Запрещенное имя заголовка	нет

 Авторизация: <схема-авторизации> <параметры-авторизации>
 

Базовая аутентификация

 Авторизация: базовая <учетные данные>
 

Дайджест-аутентификация

 Авторизация: Дайджест-имя пользователя=<имя пользователя>,
    область = "<область>",
    ури="<адрес>",
    алгоритм=<алгоритм>,
    одноразовый номер="<одноразовый номер>",
    нк=<нк>,
    cnonce="",
    qop=,
    ответ="<ответ>",
    непрозрачный="<непрозрачный>"
 

<схема авторизации>

Схема аутентификации, которая определяет способ кодирования учетных данных. Некоторые из наиболее распространенных типов (без учета регистра): Basic , Digest , Negotiate и AWS4-HMAC-SHA256 .

Примечание: Для получения дополнительной информации/параметров см. HTTP-аутентификация > Схемы аутентификации

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

Базовый

<учетные данные>

Учетные данные, закодированные по указанной схеме.

Примечание: Информацию об алгоритме кодирования см. в примерах: ниже, в WWW-Authenticate , в HTTP-аутентификации и в соответствующих спецификациях.

Дайджест

<ответ>

Строка шестнадцатеричных цифр, подтверждающая, что пользователь знает пароль. Алгоритм кодирует имя пользователя и пароль, область, cnonce, qop, nc и так далее. Подробно это описано в спецификации.

имя пользователя

Строка в кавычках, содержащая имя пользователя для указанной области либо в виде простого текста, либо в виде хэш-кода в шестнадцатеричном представлении. Если имя содержит символы, которые не разрешены в этом поле, то 9Вместо этого можно использовать 0004 имя пользователя* (не «также»).

имя пользователя*

Имя пользователя, отформатированное с использованием расширенной нотации, определенной в RFC5987. Это следует использовать только в том случае, если имя не может быть закодировано в username и если userhash установлен "false" .

ури

Действующий URI запроса . См. спецификацию для получения дополнительной информации.

царство

Область запрошенного имени пользователя/пароля (опять же, должно совпадать со значением в соответствующем ответе WWW-Authenticate для запрашиваемого ресурса).

непрозрачный

Значение в соответствующем ответе WWW-Authenticate для запрашиваемого ресурса.

алгоритм

Алгоритм, используемый для расчета дайджеста. Должен быть поддерживаемый алгоритм из Ответ WWW-Authenticate для запрашиваемого ресурса.

ежеквартально

Токен, указывающий качество защиты , примененное к сообщению. Должен соответствовать одному значению в наборе, указанном в ответе WWW-Authenticate для запрашиваемого ресурса.

• "Авторизация" : Аутентификация
• "auth-int" : Аутентификация с защитой целостности

cнонс

Строковое значение ASCII в кавычках, предоставленное клиентом. Это используется как клиентом, так и сервером для обеспечения взаимной аутентификации, обеспечения некоторой защиты целостности сообщений и предотвращения «выбранного открытого текста». атаки». Дополнительную информацию см. в спецификации.

НЗ

Однократный счет. Шестнадцатеричное количество запросов, в которых клиент отправил текущие значение cnonce (включая текущий запрос). Сервер может использовать повторяющиеся значения nc для распознавания запросов воспроизведения.

хэш пользователя Дополнительно

"true" , если имя пользователя было хешировано. "ложь" по умолчанию.

Базовая аутентификация

Для "Базовая" аутентификация учетные данные формируются путем объединения имени пользователя и пароля с двоеточием ( aladdin:opensesame ), а затем путем кодирования полученной строки в base64 ( YWxhZGRpbjpvcGVuc2VzYW1l ).

 Авторизация: базовая YWxhZGRpbjpvcGVuc2VzYW1l
 

Предупреждение: Кодировку Base64 можно легко отменить, чтобы получить исходное имя и пароль, поэтому обычная проверка подлинности совершенно небезопасна. HTTPS всегда рекомендуется при использовании аутентификации, но тем более при использовании аутентификации Basic .

См. также HTTP-аутентификация для примеров того, как настроить серверы Apache или Nginx для защиты паролем вашего сайта с помощью базовой HTTP-аутентификации.

Спецификация
Семантика HTTP # field.authorization

таблицы загружаются только в браузере с включенным BCD. Включите JavaScript для просмотра данных.

• HTTP-аутентификация
• WWW-аутентификация
• Прокси-авторизация
• Прокси-аутентификация
• 401 , 403 , 407

Последнее изменение: 000Z»> 12 сентября 2022 г. , участниками MDN

HTTP-аутентификация — HTTP | МДН

HTTP обеспечивает общую основу для контроля доступа и аутентификации. Эта страница представляет собой введение в структуру HTTP для аутентификации и показывает, как ограничить доступ к вашему серверу с помощью схемы HTTP «Basic».

RFC 7235 определяет структуру проверки подлинности HTTP, которая может использоваться сервером для оспаривания клиентского запроса и клиентом для предоставления информации для проверки подлинности.

Поток запросов и ответов работает следующим образом:

1. Сервер отвечает клиенту со статусом ответа 401 (Неавторизованный) и предоставляет информацию о том, как авторизоваться с помощью заголовка ответа WWW-Authenticate , содержащего как минимум один вызов.
2. Клиент, который хочет аутентифицировать себя на сервере, может сделать это, включив Авторизация Заголовок запроса с учетными данными.
3. Обычно клиент представляет пользователю запрос пароля, а затем выдает запрос, включающий правильный заголовок Authorization .

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

Предупреждение: «Базовая» схема проверки подлинности, используемая на приведенной выше диаграмме, отправляет учетные данные в закодированном, но не зашифрованном виде. Это было бы совершенно небезопасно, если бы обмен не осуществлялся через защищенное соединение (HTTPS/TLS).

Аутентификация прокси-сервера

Тот же механизм запроса и ответа можно использовать для аутентификации прокси-сервера . Поскольку и аутентификация ресурсов, и аутентификация прокси-сервера могут сосуществовать, необходим другой набор заголовков и кодов состояния. В случае прокси-серверов код состояния вызова — 407 (требуется аутентификация прокси-сервера), заголовок ответа Proxy-Authenticate содержит по крайней мере один запрос, применимый к прокси-серверу, и Proxy-Authorization 9. Заголовок запроса 0005 используется для предоставления учетных данных прокси-серверу.

Доступ запрещен

Если (прокси) сервер получает недействительные учетные данные , он должен ответить 401 Неавторизованный или 407 Требуется проверка подлинности прокси-сервера, или пользователь может отправить новый запрос замените поле заголовка Authorization .

Если (прокси) сервер получает действительные учетные данные, которые не соответствуют для доступа к данному ресурсу сервер должен ответить кодом состояния 403 Forbidden . В отличие от 401 Unauthorized или 407 Proxy Authentication Required , аутентификация для этого пользователя невозможна, и браузеры не будут предлагать новую попытку.

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

Аутентификация образов разных источников

Потенциальной дырой в безопасности (которую с тех пор устранили в браузерах) была аутентификация межсайтовых изображений. Начиная с Firefox 59, ресурсы изображения, загружаемые из разных источников в текущий документ, больше не могут вызывать диалоговые окна HTTP-аутентификации (ошибка 1423146), предотвращая кражу учетных данных пользователя, если злоумышленники смогли встроить произвольное изображение на стороннюю страницу.

Кодировка символов HTTP-аутентификации

Браузеры используют кодировку utf-8 для имен пользователей и паролей.

Firefox когда-то использовал ISO-8859-1 , но был изменен на utf-8 для соответствия другим браузерам и во избежание потенциальных проблем, описанных в ошибке 1419658. Заголовки ответа определяют метод проверки подлинности, который следует использовать для получения доступа к ресурсу. Они должны указать, какая схема аутентификации используется, чтобы клиент, желающий авторизоваться, знал, как предоставить учетные данные.

Синтаксис этих заголовков следующий:

 WWW-Authenticate:  realm=
Прокси-аутентификация:  realm=
 

Здесь <тип> — схема аутентификации («Базовая» — наиболее распространенная схема, представленная ниже). Область используется для описания защищенной области или для указания объема защиты. Это может быть сообщение вроде «Доступ к промежуточному сайту» или подобное, чтобы пользователь знал, к какому пространству он пытается получить доступ.

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

 Авторизация: <тип> <учетные данные>
Прокси-авторизация:  
 

Общая структура аутентификации HTTP является основой для ряда схем аутентификации.

IANA ведет список схем аутентификации, но есть и другие схемы, предлагаемые хост-сервисами, например Amazon AWS.

Некоторые распространенные схемы аутентификации включают:

Basic

См. RFC 7617, учетные данные в кодировке base64. Дополнительная информация ниже.

Носитель

См. RFC 6750, токены носителя для доступа к ресурсам, защищенным OAuth 2.0

Дайджест

См. RFC 7616. Firefox 93 и более поздние версии поддерживают алгоритм SHA-256. Предыдущие версии поддерживают только хеширование MD5 (не рекомендуется).

ХОБА

См. RFC 7486, раздел 3, H TTP O rigin- B ound A аутентификация на основе цифровой подписи

Взаимный

См. RFC 8120

Переговоры / НТЛМ

См. RFC4599

VAPID

См. RFC 8292

СКРАМ

См. RFC 7804

AWS4-HMAC-SHA256

См. документы AWS. Эта схема используется для аутентификации сервера AWS3.

Схемы могут различаться степенью защиты и доступностью в клиентском или серверном программном обеспечении.

«Базовая» схема аутентификации обеспечивает очень низкую безопасность, но широко поддерживается и проста в настройке. Более подробно он представлен ниже.

«Базовая» схема аутентификации HTTP определена в RFC 7617, которая передает учетные данные в виде пар идентификатора пользователя и пароля, закодированных с использованием base64.

Безопасность базовой аутентификации

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

Ограничение доступа с помощью Apache и базовая аутентификация

Для защиты паролем каталога на сервере Apache вам потребуются файлы .htaccess и .htpasswd .

Файл .htaccess обычно выглядит так:

 Основной тип аутентификации
AuthName "Доступ к промежуточному сайту"
AuthUserFile /путь/к/.htpasswd
Требовать действительного пользователя
 

Файл .htaccess ссылается на файл .htpasswd , в котором каждая строка состоит из имени пользователя и пароля, разделенных двоеточием ( : ). Вы не можете видеть фактические пароли, поскольку они хэшируются (в данном случае с использованием хеширования на основе MD5). Обратите внимание, что вы можете назвать свой файл . htpasswd по-разному, если хотите, но имейте в виду, что этот файл не должен быть доступен никому. (Apache обычно настроен на запрет доступа к .ht* файлов).

 аладдин:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
пользователь2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
 

Ограничение доступа с помощью Nginx и базовой аутентификации

Для Nginx вам нужно будет указать местоположение, которое вы собираетесь защищать, и директиву auth_basic , которая задает имя защищенной паролем области. Затем директива auth_basic_user_file указывает на файл .htpasswd , содержащий зашифрованные учетные данные пользователя, как в приведенном выше примере Apache.

 местоположение/статус {
    auth_basic "Доступ к промежуточному сайту";
    auth_basic_user_file /etc/apache2/.htpasswd;
}
 

Доступ с использованием учетных данных в URL-адресе

Многие клиенты также позволяют избежать запроса на вход в систему, используя закодированный URL-адрес, содержащий имя пользователя и пароль, например:

 https://имя пользователя:пароль@www. example.com/
 

Использование этих URL устарело . В Chrome часть имя пользователя: пароль @ в URL-адресах даже удалена из соображений безопасности. В Firefox проверяется, действительно ли сайт требует аутентификации, и если нет, Firefox предупредит пользователя с подсказкой «Вы собираетесь войти на сайт «www.example.com» с именем пользователя «имя пользователя», но веб-сайт не требует аутентификации. Это может быть попыткой обмануть вас».

• WWW-аутентификация
• Авторизация
• Прокси-авторизация
• Прокси-аутентификация
• 401 , 403 , 407

Последнее изменение: 9 сентября 2022 г. , участниками MDN0611 RFC 2616 Филдинг и др.

В этом разделе определяются синтаксис и семантика всех стандартных Поля заголовка HTTP/1. 1. Для полей заголовка сущности как отправитель, так и получатель относится либо к клиенту, либо к серверу, в зависимости от того, кто отправляет и кто получает сущность.

14.1 Принять

Поле заголовка запроса «Принять» можно использовать для указания определенных носителей. типы, которые приемлемы для ответа. Заголовки Accept могут быть используется для указания того, что запрос специально ограничен небольшим набор желаемых типов, как в случае запроса на встроенный изображение.

 Принять = "Принять" ":"
                        #( медиа-диапазон [ accept-params ] )
 

 медиа-диапазон = ("*/*"
                        | ( тип "/" "*" )
                        | (тип "/" подтип)
                        ) *( Параметр ";" )
       принять параметры = ";" "q" "=" qvalue *(принять-расширение)
       принять-расширение = ";" токен [ "=" ( токен | строка в кавычках ) ]
 

Символ звездочки «*» используется для группировки типов носителей в диапазоны, где «*/*» указывает все типы носителей, а «тип/*» указывает все подтипы этого типа. Медиа-диапазон МОЖЕТ включать тип носителя параметры, применимые к этому диапазону.

За каждым медиа-диапазоном МОЖЕТ следовать один или несколько accept-params, начиная с параметра «q» для указания относительного качества фактор. Первый параметр «q» (если есть) разделяет медиа-диапазон параметр(ы) из accept-params. Факторы качества позволяют пользователю или пользовательский агент, чтобы указать относительную степень предпочтения для этого media-range, используя шкалу qvalue от 0 до 1 (раздел 3.9). значение по умолчанию q=1.

 Примечание. Использование имени параметра «q» для разделения типа носителя
      параметры из параметров расширения Accept связаны с историческими
      упражняться. Хотя это предотвращает любой параметр типа носителя с именем
      "q" от использования с диапазоном носителей, считается, что такое событие
      маловероятно, учитывая отсутствие каких-либо параметров «q» в IANA
      реестр типов носителей и редкое использование любого типа носителей
      параметры в Принять.  Не рекомендуется использовать будущие типы носителей.
      регистрация любого параметра с именем "q".
 

Пример

 Принять: аудио/*; q=0,2, аудио/базовый
 

СЛЕДУЕТ интерпретировать как «Я предпочитаю аудио/базовый, но пришлите мне любой аудиофайл». тип, если он является лучшим из доступных после снижения качества на 80%».

Если поле заголовка Accept отсутствует, предполагается, что клиент принимает все типы носителей. Если поле заголовка Accept присутствует, и если сервер не может отправить ответ, который является приемлемым в соответствии с комбинированным значением поля Accept, сервер ДОЛЖЕН отправить ответ 406 (неприемлемо).

Более сложный пример

 Принять: текст/обычный; д=0,5, текст/html,
               текст/x-dvi; q=0,8, текст/х-с
 

На словах это будет интерпретироваться как «text/html и text/x-c предпочтительные типы носителей, но если они не существуют, отправьте text/x-dvi, и если он не существует, отправьте text/plain организация. »

Диапазоны носителей могут быть переопределены более конкретными диапазонами носителей или конкретные типы носителей. Если к данному тип, более конкретная ссылка имеет приоритет. Например,

 Принять: текст/*, текст/html, текст/html; уровень=1, */*
 

имеют следующий приоритет:

 1) текст/html;уровень=1
       2) текст/html
       3) текст/*
       4) */*
 

Коэффициент качества типа носителя, связанный с данным типом, равен определяется путем нахождения диапазона мультимедиа с наивысшим приоритетом который соответствует этому типу. Например,

 Принять: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
               текст/html; уровень = 2; д = 0,4, */*; д = 0,5
 

приведет к тому, что следующие значения будут связаны:

 текст/html; уровень=1 = 1
       текст/html = 0,7
       текст/обычный = 0,3
 

 изображений/jpeg = 0,5
       текст/html; уровень = 2 = 0,4
       текст/html; уровень = 3 = 0,7
 

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

14.2 Принять кодировку

Поле заголовка запроса Accept-Charset может использоваться для указания того, что наборы символов приемлемы для ответа. Это поле позволяет клиенты, способные понимать более всеобъемлющие или специальные целевые наборы символов, чтобы сообщить об этой возможности серверу, который способный представлять документы в этих наборах символов.

 Принять кодировку = "Принять кодировку" ":"
              1#(( кодировка | "*" )[ ";" "q" "=" qvalue ] )
 

Значения набора символов описаны в разделе 3.4. Каждая кодировка МОЖЕТ получить соответствующее значение качества, которое представляет предпочтение этой кодировки. Значение по умолчанию: q=1. Примером является

 Accept-Charset: iso-8859-5, unicode-1-1;q=0,8
 

Специальное значение «*», если оно присутствует в поле Accept-Charset, соответствует каждому набору символов (включая ISO-8859-1), который не упоминается в другом месте в поле Accept-Charset. Если нет «*» в поле Accept-Charset, то все наборы символов не явно упомянутые получают значение качества 0, кроме ISO-8859-1, что получает значение качества 1, если это не указано явно.

Если заголовок Accept-Charset отсутствует, по умолчанию любой набор символов приемлем. Если присутствует заголовок Accept-Charset, и если сервер не может отправить ответ, который является приемлемым согласно заголовку Accept-Charset, то сервер ДОЛЖЕН отправить ответ об ошибке с кодом состояния 406 (неприемлемо), хотя также допускается отправка неприемлемого ответа.

14.3 Принять кодирование

Поле заголовка запроса Accept-Encoding похоже на Accept, но ограничивает кодирование контента (раздел 3. 5), которое приемлемо в ответ.

 Accept-Encoding = "Accept-Encoding" ":"
 

 1#( кодировки [ ";" "q" "=" qvalue ] )
       кодировки = ( кодирование контента | "*" )
 

Примеры его использования:

 Accept-Encoding: сжатие, gzip
       Принять кодировку:
       Принять кодировку: *
       Accept-Encoding: сжатие; q = 0,5, gzip; q = 1,0
       Accept-Encoding: gzip;q=1.0, идентификатор; д=0,5, *;д=0
 

Сервер проверяет приемлемость кодирования контента в соответствии с поле Accept-Encoding, используя следующие правила:

 1. Если кодировка контента является одной из кодировок контента, перечисленных в
         поле Accept-Encoding, то оно приемлемо, если только оно не
         сопровождается значением q, равным 0. (Как определено в разделе 3.9, а
         qvalue 0 означает «неприемлемо».)
 

 2. Специальный символ «*» в поле Accept-Encoding соответствует любому
         доступное кодирование содержимого, явно не указанное в заголовке
         поле. 
 

 3. Если допустимо несколько кодировок контента, то допустимый
         предпочтительнее кодирование содержимого с наивысшим ненулевым значением q.
 

 4. Кодирование содержимого «личность» всегда приемлемо, за исключением случаев, когда
         специально отказано, потому что поле Accept-Encoding включает
         "identity;q=0", или потому что поле включает "*;q=0" и не
         явно не включать кодирование контента «личность». Если
         Значение поля Accept-Encoding пусто, тогда только "идентификация"
         кодировка приемлемая.
 

Если поле Accept-Encoding присутствует в запросе и если сервер не может отправить ответ, который является приемлемым в соответствии с Accept-Encoding, то сервер ДОЛЖЕН отправить ответ об ошибке с кодом состояния 406 (неприемлемо).

Если в запросе нет поля Accept-Encoding, сервер МОЖЕТ предположим, что клиент примет любое кодирование контента. В таком случае, если «идентичность» является одной из доступных кодировок контента, то сервер ДОЛЖЕН использовать «идентификационное» кодирование контента, если только он не дополнительная информация о том, что другое кодирование контента имеет смысл клиенту.

 Примечание. Если запрос не включает поле Accept-Encoding,
      и если "личное" кодирование контента недоступно, то
      кодировки содержимого, обычно понятные клиентам HTTP/1.0 (т. е.
 

 "gzip" и "compress") предпочтительнее; некоторые старые клиенты
      некорректно отображать сообщения, отправленные с другими кодировками содержимого.
      сервер также может принять это решение на основе информации о
      конкретный пользовательский агент или клиент.
 

 Примечание. Большинство приложений HTTP/1.0 не распознают значения qvalue или не подчиняются им.
      связанные с кодированием контента. Это означает, что qvalues ​​не будет
      работают и не разрешены с x-gzip или x-compress.
 

14.4 Принять язык

Поле заголовка запроса Accept-Language похоже на Accept, но ограничивает набор естественных языков, предпочитаемых в качестве ответ на запрос. Языковые теги определены в разделе 3.10.

 Accept-Language = "Accept-Language" ":"
                         1#(язык-диапазон [ ";" "q" "=" qvalue ] )
       язык-диапазон = (( 1*8ALPHA *("-" 1*8ALPHA)) | "*" )
 

Каждому диапазону языков МОЖЕТ быть присвоено соответствующее значение качества, которое представляет собой оценку предпочтений пользователя в отношении языков определяется этим диапазоном. Значение качества по умолчанию равно «q=1». За пример,

 Accept-Language: da, en-gb;q=0.8, en;q=0.7
 

будет означать: «Я предпочитаю датский, но приму британский английский и другие типы английского языка.» Диапазон языка соответствует языковому тегу, если он точно равен тегу или, если он точно равен префиксу тег так, чтобы первый символ тега, следующий за префиксом, был «-«. Специальный диапазон «*», если он присутствует в поле Accept-Language, соответствует каждому тегу, не соответствующему ни одному другому диапазону, присутствующему в Поле Accept-Language.

 Примечание. Такое использование правила сопоставления префиксов не означает, что
      языковые теги назначаются языкам таким образом, чтобы
      всегда верно, что если пользователь понимает язык с определенным
      тег, то этот пользователь также будет понимать все языки с тегами
      для которых этот тег является префиксом. Префиксное правило просто позволяет
      использование тегов префикса, если это так. 
 

Фактор качества языка, присвоенный языковому тегу Поле Accept-Language — это значение качества самого длинного языка. диапазон в поле, которое соответствует тегу языка. Если нет языка- диапазон в поле соответствует тегу, фактор качества языка присвоено значение 0. Если заголовок Accept-Language отсутствует в запрос, сервер

СЛЕДУЕТ предполагать, что все языки одинаково приемлемы. Если Заголовок Accept-Language присутствует, тогда все языки, которые которым присвоен коэффициент качества больше 0, являются приемлемыми.

Это может противоречить ожиданиям пользователя в отношении конфиденциальности. заголовок Accept-Language с полными лингвистическими настройками пользователя в каждом запросе. Обсуждение этого вопроса см. раздел 15.1.4.

Поскольку разборчивость в значительной степени зависит от отдельного пользователя, рекомендуется, чтобы клиентские приложения делали выбор языкового предпочтения, доступные пользователю. Если выбор не сделан доступно, то поле заголовка Accept-Language НЕ ДОЛЖНО указываться в запрос.

 Примечание. Если сделать выбор языковых предпочтений доступным для
      пользователя, мы напоминаем разработчикам о том, что пользователи не
      знакомы с деталями языкового сопоставления, как описано выше,
      и должны давать соответствующие указания. Например, пользователи
      можно предположить, что при выборе "en-gb" им будут обслуживаться любые
      тип документа на английском языке, если британский английский недоступен. А
      пользовательский агент может предложить в таком случае добавить «en», чтобы получить
      наилучшее соответствие поведения.
 

14,5 Допустимые диапазоны

 Поле заголовка ответа Accept-Ranges позволяет серверу
      указать, что он принимает запросы диапазона для ресурса:
 

 Accept-Ranges = "Accept-Ranges" ":" допустимые диапазоны
          допустимые-диапазоны = 1#диапазон-единица | "никто"
 

 Исходные серверы, которые принимают запросы диапазона байтов, МОГУТ отправлять
 

 Допустимые диапазоны: байты
 

, но не обязаны этого делать.  Клиенты МОГУТ генерировать диапазон байтов
      запросы, не получив этот заголовок для ресурса
      вовлеченный. Единицы диапазона определены в разделе 3.12.
 

 Серверы, которые не принимают какой-либо запрос диапазона для
      ресурс МОЖЕТ отправить
 

 Допустимые диапазоны: нет
 

, чтобы посоветовать клиенту не пытаться запросить диапазон.
 

14.6 9 лет0082

 Поле заголовка ответа Age содержит оценку отправителем
      количество времени, прошедшее с момента ответа (или его повторной проверки)
      генерируется на исходном сервере. Кэшированный ответ является «свежим», если
      его возраст не превышает срока его свежести. Возрастные значения
      рассчитывается, как указано в разделе 13.2.3.
 

 Возраст = "Возраст" ":" значение возраста
           значение возраста = дельта-секунды
 

 Значения возраста представляют собой неотрицательные десятичные целые числа, представляющие время в
      секунды. 
 931). Сервер HTTP/1.1 с кэшем ДОЛЖЕН
      включать поле заголовка Age в каждый ответ, сгенерированный из его
      собственный кеш. Кэши ДОЛЖНЫ использовать арифметический тип не менее 31
      бит диапазона.
 

14.7 Разрешить

 В поле заголовка сущности Allow указан набор поддерживаемых методов.
      ресурсом, идентифицированным Request-URI. Цель этого
      поле предназначено строго для информирования получателя о действительных методах
      связанные с ресурсом. Поле заголовка Allow ДОЛЖНО быть
      присутствует в ответе 405 (метод не разрешен).
 

 Разрешить = "Разрешить" ":" #Метод
 

 Пример использования:
 

 Разрешить: ПОЛУЧИТЬ, ГОЛОВУ, ПОЛОЖИТЬ
 

 Это поле не может помешать клиенту попробовать другие методы.
      Тем не менее, показания, заданные значением поля заголовка Разрешить
      СЛЕДУЕТ соблюдать. Фактический набор разрешенных методов определен
      исходным сервером во время каждого запроса. 
 

 Поле заголовка Allow МОЖЕТ быть предоставлено с запросом PUT на
      рекомендовать методы, которые должны поддерживаться новыми или измененными
      ресурс. Сервер не обязан поддерживать эти методы и
      СЛЕДУЕТ включать заголовок Allow в ответ, содержащий фактический
      поддерживаемые методы.
 

 Прокси-сервер НЕ ДОЛЖЕН изменять поле заголовка Allow, даже если он не
      понимать все указанные методы, поскольку пользовательский агент может
      иметь другие средства связи с исходным сервером.
 

14.8 Авторизация

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

 Авторизация = "Авторизация" ":" учетные данные
 

 Аутентификация HTTP-доступа описана в разделе «Аутентификация HTTP:
      Basic and Digest Access Authentication" [43].  Если запрос
      аутентифицированы и указана область, одни и те же учетные данные ДОЛЖНЫ
      быть действительным для всех других запросов в этой области (при условии, что
      сама схема аутентификации иного не требует, такие
      как учетные данные, которые варьируются в зависимости от значения вызова или использования
      синхронизированные часы).
 

 Когда общий кэш (см. раздел 13.7) получает запрос
      содержащее поле авторизации, он НЕ ДОЛЖЕН возвращать
      соответствующий ответ в качестве ответа на любой другой запрос, если только
      из следующих конкретных исключений:
 

 1. Если ответ включает элемент управления кешем "s-maxage"
         директивы, кэш МОЖЕТ использовать этот ответ в ответ на
         последующий запрос. Но (если указанный максимальный возраст имеет
         пройден) прокси-кеш ДОЛЖЕН сначала перепроверить его с источником
         сервер, используя заголовки запроса из нового запроса, чтобы разрешить
         исходный сервер для аутентификации нового запроса.  (Это
         определенное поведение для s-maxage.) Если ответ включает «s-
         maxage=0", прокси-сервер ДОЛЖЕН всегда перепроверять его перед повторным использованием.
         Это.
 

 2. Если ответ включает элемент управления кэшем «обязательная повторная проверка».
         директивы, кэш МОЖЕТ использовать этот ответ в ответ на
         последующий запрос. Но если ответ устарел, все кэши
         ДОЛЖЕН сначала повторно проверить его на исходном сервере, используя
         заголовки запроса из нового запроса, чтобы разрешить исходный сервер
         для аутентификации нового запроса.
 

 3. Если ответ включает директиву управления кешем "public",
         он МОЖЕТ быть возвращен в ответ на любой последующий запрос.
 

14.9 Кэш-контроль

Поле общего заголовка Cache-Control используется для указания директив. которому ДОЛЖНЫ подчиняться все механизмы кэширования на цепочка запросов/ответов. Директивы определяют поведение, предназначенное для предотвратить неблагоприятное вмешательство кешей в запрос или отклик. Эти директивы обычно переопределяют кэширование по умолчанию. алгоритмы. Директивы кэша являются однонаправленными в том смысле, что наличие директивы в запросе не означает, что эта же директива необходимо указать в ответе.

 Обратите внимание, что кэши HTTP/1.0 могут не реализовывать Cache-Control и
      может реализовать только Pragma: no-cache (см. раздел 14.32).
 

Директивы кеша ДОЛЖНЫ передаваться через прокси или шлюз приложение, независимо от их значимости для этого приложения, поскольку директивы могут быть применимы ко всем получателям на цепочка запросов/ответов. Невозможно указать кеш- директива для конкретного кеша.

 Cache-Control = "Cache-Control" ":" 1#cache-directive
 

 кеш-директива = кеш-запрос-директива
         | кеш-ответ-директива
 

 кеш-запрос-директива =
           "без кеша"; Раздел 14.9.1
         | "без магазина"; Раздел 14.9.2
         | "max-age" "=" delta-seconds ; Раздел 14. 9.3, 14.9.4
         | "max-stale" [ "=" delta-seconds ] ; Раздел 14.9.3
         | "min-fresh" "=" дельта-секунд ; Раздел 14.9.3
         | "без преобразования"; Раздел 14.9.5
         | "только если кэшировано"; Раздел 14.9.4
         | кеш-расширение ; Раздел 14.9.6
 

 кеш-ответ-директива =
           "общественный"; Раздел 14.9.1
         | "private" [ "=" <"> 1#имя-поля <"> ] ; Раздел 14.9.1
         | "без кеша" [ "=" <"> 1#имя-поля <"> ]; Раздел 14.9.1
         | "без магазина"; Раздел 14.9.2
         | "без преобразования"; Раздел 14.9.5
         | «необходимо перепроверить»; Раздел 14.9.4
         | "прокси-повторная проверка" ; Раздел 14.9.4
         | "max-age" "=" delta-seconds ; Раздел 14.9.3
         | "s-maxage" "=" дельта-секунд ; Раздел 14.9.3
         | кеш-расширение ; Раздел 14.9.6
 

 cache-extension = токен [ "=" ( токен | строка в кавычках ) ]
 

Когда директива появляется без какого-либо параметра 1#field-name, директива применяется ко всему запросу или ответу. Когда такой появляется с параметром 1#field-name, он применяется только к названному полю или полям, а не остальной части запроса или отклик. Этот механизм поддерживает расширяемость; реализации будущие версии протокола HTTP могут применять эти директивы к поля заголовка, не определенные в HTTP/1.1.

Директивы управления кешем можно разбить на эти общие категории:

 - Ограничения на кэширование; они могут быть наложены только
        исходный сервер.
 

 - Ограничения на то, что может хранить кэш; это может быть
        налагается либо исходным сервером, либо пользовательским агентом.
 

 - Модификации основного механизма выдоха; это может быть
        налагается либо исходным сервером, либо пользовательским агентом.
 

 - Элементы управления повторной проверкой и перезагрузкой кеша; это могут быть только
        навязывается агентом пользователя.
 

 - Контроль трансформации сущностей. 
 

 - Расширения системы кэширования.
 

14.9.1 Что можно кэшировать

По умолчанию ответ кэшируется, если требования метод запроса, поля заголовка запроса и статус ответа указать, что он кэшируется. Раздел 13.4 обобщает эти значения по умолчанию. для кеширования. Следующие директивы ответа Cache-Control разрешить исходному серверу переопределять кешируемость по умолчанию для отклик:

общественный

Указывает, что ответ МОЖЕТ быть закэширован любым кешем, даже если он обычно не кэшируются или кэшируются только внутри не- общий кеш. (См. также Авторизация, раздел 14.8, для дополнительные детали.)

частный

Указывает, что все ответное сообщение или его часть предназначены для один пользователь и НЕ ДОЛЖЕН кэшироваться общим кешем. Этот позволяет исходному серверу заявить, что указанные части

ответы предназначены только для одного пользователя и не являются действительными ответ на запросы других пользователей. Частный (не общий) кеш МОЖЕТ кэшировать ответ.

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

без кэша

Если в директиве no-cache не указано имя поля, то кеш НЕ ДОЛЖЕН использовать ответ для удовлетворения последующего запроса без успешной повторной проверки на исходном сервере. Этот позволяет исходному серверу предотвращать кэширование даже теми кэшами, которые были настроены для возврата устаревших ответов на запросы клиентов.

Если директива no-cache указывает одно или несколько имен полей, тогда кеш МОЖЕТ использовать ответ для удовлетворения последующего запроса, с учетом любых других ограничений на кэширование. Тем не менее указанные имена полей НЕ ДОЛЖНЫ быть отправлены в ответ на последующий запрос без успешной повторной проверки с источником сервер. Это позволяет исходному серверу предотвратить повторное использование определенные поля заголовка в ответе, но при этом разрешено кэширование остальной части ответа.

Примечание: Большинство кэшей HTTP/1.0 не распознают или не подчиняются этому директива.

14.9.2 Что может храниться в кэшах

нет в магазине

Целью запрета на хранение является предотвращение непреднамеренное раскрытие или сохранение конфиденциальной информации (для например, на резервных лентах). Директива о запрете магазинов распространяется на всего сообщения и МОЖЕТ быть отправлено либо в ответе, либо в запрос. При отправке в запросе кэш НЕ ДОЛЖЕН хранить какую-либо часть либо этот запрос, либо любой ответ на него. Если отправлено в ответ, кэш НЕ ДОЛЖЕН хранить какую-либо часть ни этого ответа, ни запрос, вызвавший его. Эта директива применяется как к не- общий и общий кэши. «НЕ ДОЛЖЕН хранить» в данном контексте означает что кэш НЕ ДОЛЖЕН преднамеренно хранить информацию в энергонезависимой памяти, и ДОЛЖЕН сделать все возможное, чтобы удалить информацию из энергозависимого хранилища как можно скорее возможно после отправки.

Даже если эта директива связана с ответом, пользователи может явно хранить такой ответ вне кэширования системы (например, с диалоговым окном «Сохранить как»). Буферы истории МОГУТ хранить такие ответы являются частью их нормальной работы.

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

14.9.3 Модификации основного механизма выдоха

Время истечения срока действия объекта МОЖЕТ быть указано источником сервер с использованием заголовка Expires (см. раздел 14.21). Альтернативно, это МОЖЕТ быть указано с помощью директивы max-age в ответе. Когда директива max-age cache-control присутствует в кэшированном ответе, ответ устарел, если его текущий возраст больше, чем возраст значение, заданное (в секундах) во время нового запроса для этого ресурс. Директива max-age для ответа подразумевает, что ответ кэшируется (т. е. «общедоступен»), если только какой-либо другой, более также присутствует директива ограничительного кеша.

Если ответ включает заголовок Expires и max-age директива max-age переопределяет заголовок Expires, даже если заголовок Expires является более строгим. Это правило допускает происхождение сервер, чтобы обеспечить для данного ответа более длительное время истечения срока действия кеш HTTP/1.1 (или более поздней версии), чем к кешу HTTP/1.0. Это может быть полезно, если некоторые кэши HTTP/1.0 неправильно вычисляют возраст или время истечения, возможно, из-за десинхронизации часов.

Многие реализации кэша HTTP/1.0 будут обрабатывать значение Expires, которое меньше или равно значению даты ответа как эквивалентному на директиву ответа Cache-Control «no-cache». Если HTTP/1.1 кэш получает такой ответ, и ответ не включает в себя Поле заголовка Cache-Control, в нем СЛЕДУЕТ рассматривать ответ как без кэширования, чтобы сохранить совместимость с серверами HTTP/1.0.

Примечание: Исходный сервер может использовать относительно новый протокол HTTP. функция управления кешем, такая как директива «private», на сети, включая старые кеши, которые не понимают, что особенность. Исходный сервер должен будет объединить новую функцию с полем Expires, значение которого меньше или равно Значение даты. Это предотвратит неправильное использование старых кешей. кэширование ответа.

с-максаж

Если ответ содержит директиву s-maxage, то для общего кэш (но не для частного кеша), максимальный возраст, указанный эта директива отменяет максимальный возраст, указанный либо max-age или заголовок Expires. Директива s-maxage также подразумевает семантику директивы proxy-revalidate (см. раздел 14.9.4), т. е. общий кэш не должен использовать запись после того, как она устарела, чтобы ответить на последующий запрос без предварительной проверки на исходном сервере. С- maxage всегда игнорируется приватным кешем.

Обратите внимание, что большинство старых кэшей, не соответствующих этой спецификации, не реализуйте никаких директив управления кешем. Исходный сервер желающие использовать директиву управления кешем, которая ограничивает, но не запрещает предотвращения, кэширование с помощью кеша, совместимого с HTTP/1.1, МОЖЕТ использовать требование, чтобы директива max-age переопределяла заголовок Expires, и тот факт, что кэши, совместимые с протоколом pre-HTTP/1.1, не соблюдают директива максимального возраста.

Другие директивы позволяют пользовательскому агенту изменять базовый срок действия. механизм. Эти директивы МОГУТ быть указаны в запросе:

максимальный возраст

Указывает, что клиент готов принять ответ, age не превышает указанного времени в секундах. Если только макс- также включена устаревшая директива, клиент не желает принять устаревший ответ.

мин-фреш

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

максимальное устаревание

Указывает, что клиент готов принять ответ, превысил срок его действия. Если max-stale присвоено значение, то клиент готов принять ответ, превышающий срок его действия не более чем на указанное количество секунды. Если значение max-stale не присвоено, клиент готов принять устаревший ответ любого возраста.

Если кеш возвращает устаревший ответ либо из-за директива по запросу, или потому что кеш настроен на переопределить время истечения срока ответа, кэш ДОЛЖЕН прикрепить Заголовок предупреждения к устаревшему ответу с использованием предупреждения 110 (ответ несвежий).

Кэш МОЖЕТ быть настроен на возврат устаревших ответов без валидация, но только если это не противоречит какому-либо уровню «ОБЯЗАТЕЛЬНО» требования, касающиеся проверки кэша (например, «обязательная повторная проверка» директиву управления кешем).

Если и новый запрос, и кешированная запись содержат «max-age», директивы, то меньшее из двух значений используется для определения свежесть кэшированной записи для этого запроса.

14.9.4 Повторная проверка кэша и элементы управления перезагрузкой

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

Сквозная повторная проверка может быть запрошена либо тогда, когда клиент не иметь собственной локальной кэшированной копии, и в этом случае мы называем ее «неуказанная сквозная повторная проверка», или когда у клиента есть локальная кэшированная копия, и в этом случае мы называем ее «конкретной сквозной переаттестация».

Клиент может указать эти три вида действий с помощью Cache- Директивы запроса управления:

Сквозная перезагрузка

Запрос включает директиву управления кешем «no-cache» или, для совместимость с клиентами HTTP/1. 0, «Прагма: без кеша». Поле имена НЕ ДОЛЖНЫ включаться в директиву no-cache в запрос. Сервер НЕ ДОЛЖЕН использовать кэшированную копию при ответе на такой запрос.

Конкретная сквозная повторная проверка

Запрос включает директиву управления кэшем «max-age=0», которая заставляет каждый кеш на пути к исходному серверу перепроверить свою собственную запись, если таковая имеется, со следующим кешем или сервером. Первоначальный запрос включает в себя условие проверки кеша с текущий валидатор клиента.

Неуказанная сквозная повторная проверка

Запрос включает директиву управления кэшем «max-age=0», которая заставляет каждый кеш на пути к исходному серверу перепроверить свою собственную запись, если таковая имеется, со следующим кешем или сервером. Первоначальный запрос не включает проверку кэша

условный; первый кэш на пути (если есть), который содержит запись кэша для этого ресурса включает проверку кэша условно с его текущим валидатором.

максимальный возраст

При принудительном использовании промежуточного кэша с помощью параметра max-age=0 директива, чтобы перепроверить свою собственную запись в кэше, и клиент предоставил свой собственный валидатор в запросе, предоставленный валидатор может отличаться от валидатора, хранящегося в данный момент в кеше вход. В этом случае кэш МОЖЕТ использовать любой валидатор для создания свой собственный запрос, не влияя на семантическую прозрачность.

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

Если запрос включает директиву no-cache, он НЕ ДОЛЖЕН включать min-fresh, max-stale или max-age.

только при кэшировании

В некоторых случаях, например при очень плохой сети подключения, клиент может захотеть, чтобы кеш возвращал только те ответы, которые он в настоящее время сохранил, а не перезагружать или повторите проверку на исходном сервере. Для этого клиент может включить в запрос директиву only-if-cached. Если он получает этой директиве, кэш ДОЛЖЕН либо отвечать, используя кэшированную запись что согласуется с другими ограничениями запроса, или ответить статусом 504 (время ожидания шлюза). Однако, если группа тайников работает как единая система с хорошей внутренней соединения, такой запрос МОЖЕТ быть перенаправлен внутри этой группы тайники.

необходимо перепроверить

Поскольку кэш МОЖЕТ быть настроен на игнорирование указанного сервером время истечения срока действия, а также потому, что запрос клиента МОЖЕТ включать максимальное stale директива (имеющая аналогичный эффект), протокол также включает механизм, позволяющий исходному серверу требовать повторной проверки записи кэша при любом последующем использовании. Когда необходимо перепроверить присутствует в ответе, полученном кешем, этот кеш НЕ ДОЛЖЕН использовать запись после того, как она устарела, для ответа на

последующий запрос без предварительной проверки его подлинности с источником сервер. (То есть, кэш ДОЛЖЕН выполнять сквозную повторную проверку каждые время, если только на основе исходного сервера Expires или max-age значение, кэшированный ответ устарел.)

Директива must-revalidate необходима для поддержки надежных операции для определенных функций протокола. Во всех обстоятельствах Кэш HTTP/1.1 ДОЛЖЕН подчиняться директиве must-revalidate; в особенно, если кэш не может достичь исходного сервера для любого по этой причине он ДОЛЖЕН генерировать ответ 504 (время ожидания шлюза).

Серверы ДОЛЖНЫ отправлять директиву must-revalidate тогда и только тогда, когда отказ от повторной проверки запроса на сущность может привести к некорректная операция, такая как молча невыполненное финансовое сделка. Получатели НЕ ДОЛЖНЫ предпринимать какие-либо автоматические действия, нарушает эту директиву и НЕ ДОЛЖЕН автоматически предоставлять непроверенная копия объекта, если повторная проверка не удалась.

Хотя это не рекомендуется, пользовательские агенты, работающие под серьезные ограничения подключения МОГУТ нарушать эту директиву, но, если поэтому ДОЛЖЕН явно предупредить пользователя, что непроверенный ответ был предоставлен. Предупреждение ДОЛЖНО быть предоставлено на каждом непроверенном доступ и ДОЛЖЕН требовать явного подтверждения пользователя.

прокси-повторная проверка

Директива proxy-revalidate имеет то же значение, что и must- директива revalidate, за исключением того, что она не применяется к неразделяемым кэш агента пользователя. Его можно использовать в ответ на аутентифицированный запрос, позволяющий кэшу пользователя хранить и позже вернуть ответ без необходимости его повторной проверки (поскольку он уже был аутентифицирован этим пользователем один раз), но все еще требование прокси-серверов, которые обслуживают многих пользователей, каждый раз проходить повторную проверку (чтобы убедиться, что каждый пользователь прошел аутентификацию). Обратите внимание, что такие аутентифицированные ответы также нуждаются в общедоступном кеше. control, чтобы разрешить их кеширование вообще.

14.9.5 Директива о запрете трансформации

без преобразования

Разработчики промежуточных кэшей (прокси) сочли это полезным для преобразования типа носителя определенных тел сущностей. Не- прозрачный прокси может, например, конвертировать изображение форматы, чтобы сэкономить место в кэше или уменьшить количество трафик на медленном канале.

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

визуализация, анализ научных данных и сквозное использование аутентификации, все зависит от получения битового тела сущности. для бита, идентичного исходному телу объекта.

Таким образом, если сообщение содержит директиву no-transform, промежуточный кеш или прокси-сервер НЕ ДОЛЖНЫ изменять те заголовки, которые перечисленные в разделе 13.5.2 как не подлежащие преобразованию директива. Это означает, что кеш или прокси НЕ ДОЛЖНЫ меняться. любой аспект тела объекта, указанный этими заголовками, включая значение самого тела сущности.

14.9.6 Расширения управления кэшем

Поле заголовка Cache-Control можно расширить за счет использования одного или несколько маркеров расширения кеша, каждый из которых имеет необязательное назначенное значение. Информационные расширения (те, которые не требуют изменения в поведение кэша) МОЖЕТ быть добавлено без изменения семантики других директивы. Поведенческие расширения предназначены для работы, действуя как модификаторы к существующей базе директив кеша. Оба новых поставляются директива и стандартная директива, так что приложения, которые не понимают новую директиву, по умолчанию к поведению, определенному стандартной директивой, и те, которые понимать, что новая директива распознает ее как изменяющую требования, связанные со стандартной директивой. Этим способом, расширения директив управления кешем могут быть сделаны без требующие внесения изменений в базовый протокол.

Этот механизм расширения зависит от кэша HTTP, подчиняющегося всем директивы управления кешем, определенные для его собственной HTTP-версии, подчиняясь определенные расширения и игнорирование всех директив, которые он не понять.

Например, рассмотрим гипотетическую новую директиву ответа, называемую community, который действует как модификатор частной директивы. Мы определите эту новую директиву так, чтобы она означала, что в дополнение к любому кеш, любой кеш, которым пользуются только члены сообщества названный в своем значении, может кэшировать ответ. Исходный сервер желая разрешить сообществу UCI использовать частный ответ в их общем кэше (ах) может сделать это, включив

 Cache-Control: private, community="UCI"
 

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

Нераспознанные директивы кеша ДОЛЖНЫ игнорироваться; предполагается, что любой cache-directive, которая, вероятно, не будет распознана кешем HTTP/1.1, будет сочетаться со стандартными директивами (или ответом по умолчанию возможность кэширования), чтобы поведение кэша оставалось минимальным. правильно, даже если кеш не понимает расширение(я).

14.10 Соединение

Поле общего заголовка Connection позволяет отправителю указать параметры, которые желательны для этого конкретного соединения и НЕ ДОЛЖНЫ быть переданы прокси через дальнейшие соединения.

Заголовок Connection имеет следующую грамматику:

 Соединение = "Соединение" ":" 1#(токен соединения)
       токен подключения = токен
 

Прокси-серверы HTTP/1.1 ДОЛЖНЫ анализировать поле заголовка Connection перед сообщение пересылается и для каждого маркера соединения в этом поле удалить все поля заголовка из сообщения с тем же именем, что и токен соединения. Варианты подключения сигнализируются наличием токен подключения в поле заголовка Connection, а не какой-либо соответствующие дополнительные поля заголовка, поскольку дополнительный заголовок поле не может быть отправлено, если нет параметров, связанных с этим вариант подключения.

Заголовки сообщений, перечисленные в заголовке Connection, НЕ ДОЛЖНЫ включать сквозные заголовки, такие как Cache-Control.

HTTP/1.1 определяет опцию «закрыть» соединение для отправителя. сигнализировать о том, что соединение будет закрыто после завершения отклик. Например,

 Соединение: близко
 

в полях заголовка запроса или ответа указывает, что соединение НЕ ДОЛЖНО считаться «постоянным» (раздел 8.1) после завершения текущего запроса/ответа.

Приложения HTTP/1.1, которые не поддерживают постоянные соединения, ДОЛЖНЫ включать опцию «закрыть» соединение в каждое сообщение.

Система, получающая сообщение HTTP/1.0 (или более ранней версии), которое ДОЛЖЕН включать заголовок Connection для каждого маркера подключения в этом поле, удалить и игнорировать любые поля заголовка из сообщения с то же имя, что и у токена подключения. Это защищает от ошибочного пересылка таких полей заголовка прокси-серверами до HTTP/1. 1. См. раздел 19.6.2.

14.11 Кодирование содержимого

Поле заголовка сущности Content-Encoding используется в качестве модификатора для медиа-тип. Если он присутствует, его значение указывает, какой дополнительный контент кодировки были применены к телу объекта, и, таким образом, какое декодирование механизмы должны быть применены для того, чтобы получить медиа-тип на который ссылается поле заголовка Content-Type. Content-Encoding в основном используется для сжатия документа без потери идентичность его основного типа носителя.

 Content-Encoding = "Content-Encoding" ":" 1#content-coding
 

Коды контента определены в разделе 3.5. Примером его использования является

 Кодировка содержимого: gzip
 

Кодирование контента является характеристикой объекта, идентифицируемого URI запроса. Обычно тело объекта хранится с этим кодирование и декодируется только перед рендерингом или аналогичным использованием. Однако непрозрачный прокси-сервер МОЖЕТ изменить кодировку содержимого, если известно, что новое кодирование приемлемо для получателя, если только В сообщении присутствует директива управления кешем «no-transform».

Если кодирование содержимого объекта не является «идентичностью», то ответ ДОЛЖЕН включать заголовок объекта Content-Encoding (раздел 14.11), в котором перечислены используемые кодировки неидентификационного контента.

Если кодирование содержимого объекта в сообщении запроса не приемлемым для исходного сервера, сервер ДОЛЖЕН ответить код состояния 415 (неподдерживаемый тип носителя).

Если к объекту было применено несколько кодировок, содержимое Кодировки ДОЛЖНЫ быть перечислены в том порядке, в котором они были применены. МОЖЕТ быть предоставлена ​​дополнительная информация о параметрах кодирования. другими полями заголовка объекта, не определенными в этой спецификации.

14.

12 Язык содержания

Поле заголовка объекта Content-Language описывает естественный язык(и) целевой аудитории для вложенного объекта. Примечание что это может быть не эквивалентно всем языкам, используемым в сущность-тело.

 Content-Language = "Content-Language" ":" 1#language-tag
 

Языковые теги определены в разделе 3.10. Основная цель Content-Language позволяет пользователю идентифицировать и различать объекты в соответствии с предпочитаемым пользователем языком. Таким образом, если основной контент предназначен только для датской грамотной аудитории, соответствующее поле

 Язык содержания: да
 

Если Content-Language не указан, по умолчанию содержимое предназначен для всех языковых аудиторий. Это может означать, что отправитель не считает его специфичным для какого-либо естественного языка, или что отправитель не знает, для какого языка оно предназначено.

Несколько языков МОГУТ быть указаны для содержимого, предназначенного для несколько аудиторий. Например, перевод «Договора о Вайтанги», представленный одновременно на языке оригинала маори и английском языке. версии, потребуют

 Язык содержимого: mi, en
 

Однако только потому, что несколько языков присутствуют в сущности не означает, что он предназначен для многоязычной аудитории. Примером может служить учебник для начинающих, такой как «Первый Урок латыни», который явно предназначен для англоязычная аудитория. В этом случае Content-Language правильно включать только «en».

Content-Language МОЖЕТ применяться к любому типу медиа — это не ограничивается текстовыми документами.

14.13 Длина содержимого

Поле заголовка сущности Content-Length указывает размер сущность-тело в десятичном числе OCTET, отправленное получателю или, в случае метода HEAD размер тела-сущности, был бы отправлен, если бы запрос был GET.

 Content-Length = "Content-Length" ":" 1*ЦИФРА
 

Примером является

 Длина содержимого: 3495
 

Приложения ДОЛЖНЫ использовать это поле для указания длины передачи тело сообщения, если это не запрещено правилами раздела 4. 4.

Любое значение Content-Length, большее или равное нулю, является допустимым значением. Раздел 4.4 описывает, как определить длину тела сообщения. если Content-Length не указан.

Обратите внимание, что значение этого поля существенно отличается от соответствующее определение в MIME, где это необязательное поле используется в типе содержимого «message/external-body». В HTTP это ДОЛЖНО быть отправлено всякий раз, когда длина сообщения может быть определена заранее. быть переданы, если это не запрещено правилами в раздел 4.4.

14.14 Расположение содержимого

Поле заголовка объекта Content-Location МОЖЕТ использоваться для предоставления расположение ресурса для сущности, заключенной в сообщении, когда это объект доступен из местоположения, отдельного от запрошенного URI ресурса. Сервер ДОЛЖЕН предоставить Content-Location для вариант, соответствующий объекту ответа; особенно в случае где ресурс имеет несколько объектов, связанных с ним, и те объекты на самом деле имеют отдельные местоположения, по которым они могут быть при индивидуальном доступе сервер ДОЛЖЕН предоставить Content-Location для конкретного варианта, который возвращается.

 Content-Location = "Content-Location" ":"
                         (абсолютныйURI | относительныйURI)
 

Значение Content-Location также определяет базовый URI для организация.

Значение Content-Location не является заменой исходного запрошенный URI; это только заявление о местонахождении ресурса соответствующий этому конкретному объекту на момент запроса. Будущие запросы МОГУТ указывать URI Content-Location в качестве запроса- URI, если требуется определить источник этого конкретного организация.

Кэш не может предполагать, что сущность с Content-Location отличается от URI, используемого для получения, его можно использовать для ответа на более поздние запросы по этому URI Content-Location. Однако Содержание- Местоположение может быть использовано для различения нескольких сущностей. извлекается из одного запрошенного ресурса, как описано в разделе 13.6.

Если Content-Location является относительным URI, относительный URI интерпретируется относительно Request-URI.

Значение заголовка Content-Location в запросах PUT или POST: неопределенный; серверы могут игнорировать его в таких случаях.

14.15 Содержимое-MD5

Поле заголовка сущности Content-MD5, как определено в RFC 1864 [23], дайджест MD5 тела объекта с целью предоставления сквозная проверка целостности сообщения (MIC) тела объекта. (Примечание: а MIC хорош для обнаружения случайной модификации тела сущности. в пути, но не является защитой от злонамеренных атак.)

 Content-MD5 = "Content-MD5" ":" md5-дайджест
        md5-digest = 
 

Поле заголовка Content-MD5 МОЖЕТ быть сгенерировано исходным сервером или client для проверки целостности сущности-тела. Только исходные серверы или клиенты МОГУТ генерировать поле заголовка Content-MD5; прокси и шлюзы НЕ ДОЛЖНЫ генерировать его, так как это нарушит его значение в качестве сквозной проверки целостности. Любой получатель сущности- body, включая шлюзы и прокси, МОЖЕТ проверять, что значение дайджеста в этом поле заголовка соответствует полученному телу объекта.

Дайджест MD5 вычисляется на основе содержимого тела объекта, включая любое кодирование контента, которое было применено, но не включая любое кодирование передачи, применяемое к телу сообщения. Если сообщение получено с кодировкой передачи, эта кодировка ДОЛЖНА быть удалена перед проверкой значения Content-MD5 по полученному объекту.

Это приводит к тому, что дайджест вычисляется по октетам сущность-тело точно так же и в том порядке, в котором они были бы отправлены, если бы кодирование передачи не применялось.

HTTP расширяет RFC 1864, чтобы разрешить вычисление дайджеста для MIME. составные медиа-типы (например, multipart/* и message/rfc822), но это не меняет того, как вычисляется дайджест, как определено в предыдущий абзац.

Это имеет несколько последствий. Сущность-тело для составного типы МОГУТ содержать много частей тела, каждая со своим собственным MIME и HTTP заголовки (включая Content-MD5, Content-Transfer-Encoding и заголовки Content-Encoding). Если часть тела имеет Content-Transfer- Encoding или Content-Encoding, предполагается, что содержимое части тела была применена кодировка, и часть тела включены в дайджест Content-MD5 как есть, т. е. после заявление. Поле заголовка Transfer-Encoding не разрешено в части тела.

Преобразование всех разрывов строк в CRLF НЕ ДОЛЖНО выполняться до вычисление или проверка дайджеста: соглашение о разрыве строки, используемое в фактически передаваемый текст ДОЛЖЕН оставаться неизменным при вычислении дайджест.

 Примечание: хотя определение Content-MD5 точно такое же для
      HTTP, как и в RFC 1864 для тел объектов MIME, существует несколько способов.
      в котором применение Content-MD5 к телам объектов HTTP
      отличается от его применения к телам сущностей MIME.  Один из них
      HTTP, в отличие от MIME, не использует Content-Transfer-Encoding и
      использует Transfer-Encoding и Content-Encoding. Другое дело, что
      HTTP чаще использует двоичные типы содержимого, чем MIME, поэтому
      стоит отметить, что в таких случаях порядок байтов, используемый для вычисления
      дайджест — это порядок передачи байтов, определенный для типа.
      Наконец, HTTP позволяет передавать текстовые типы с любым из нескольких
      соглашения о разрыве строки, а не только каноническая форма с использованием CRLF.
 

14.16 Диапазон содержимого

Заголовок сущности Content-Range отправляется с частичным телом сущности в укажите, где в полном теле сущности должно быть частичное тело применяемый. Единицы диапазона определены в разделе 3.12.

 Content-Range = "Content-Range" ":" content-range-spec
 

 спецификация диапазона содержимого = спецификация диапазона содержимого байта
       byte-content-range-spec = байтовая единица SP
                                 byte-range-resp-spec "/"
                                 ( длина экземпляра | "*" )
 

 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
                                      | "*"
       длина экземпляра = 1*ЦИФРА
 

В заголовке СЛЕДУЕТ указывать общую длину полного тела объекта, если только эта длина неизвестна или ее трудно определить. звездочка Символ «*» означает, что длина экземпляра на данный момент неизвестна. когда был сгенерирован ответ.

В отличие от значений byte-ranges-specifier (см. раздел 14.35.1), byte-ranges-specifier range-resp-spec ДОЛЖЕН указывать только один диапазон и ДОЛЖЕН содержать абсолютные позиции байтов как для первого, так и для последнего байта диапазон.

byte-content-range-spec с byte-range-resp-spec, последний из которых значение byte-pos меньше, чем его значение first-byte-pos, или чье значение длины экземпляра меньше или равно его последнему байту-позиции значение, недействительно. Получатель недопустимого byte-content-range- spec ДОЛЖЕН игнорировать его и любой контент, передаваемый вместе с ним.

Сервер, отправляющий ответ с кодом состояния 416 (Запрошенный диапазон не удовлетворительным) СЛЕДУЕТ включать поле Content-Range с диапазоном байтов. соответственно спецификация «*». Длина экземпляра определяет текущую длину

выбранный ресурс. Ответ с кодом состояния 206 (частичный Content) НЕ ДОЛЖЕН включать поле Content-Range с диапазоном байтов. соответственно спецификация «*».

Примеры значений byte-content-range-spec при условии, что сущность содержит всего 1234 байта:

 . Первые 500 байт:
       байты 0-499/1234
 

 . Вторые 500 байт:
       байт 500-999/1234
 

 . Все, кроме первых 500 байт:
       байт 500-1233/1234
 

 . Последние 500 байт:
       байты 734-1233/1234
 

Когда сообщение HTTP включает в себя содержимое одного диапазона (для например, ответ на запрос одного диапазона или на запрос для набора диапазонов, которые перекрываются без каких-либо пробелов), это содержимое передается с заголовком Content-Range и заголовком Content-Length показывает количество фактически переданных байтов. Например,

 HTTP/1.1 206 Частичное содержимое
       Дата: среда, 15 ноября 1995 г., 06:25:24 по Гринвичу. 
       Последнее изменение: среда, 15 ноября 1995 г., 04:58:08 по Гринвичу.
       Диапазон содержимого: байты 21010-47021/47022
       Длина содержимого: 26012
       Тип контента: изображение/gif
 

Когда сообщение HTTP включает в себя содержимое нескольких диапазонов (для например, ответ на запрос нескольких непересекающихся диапазоны), они передаются как составное сообщение. составной тип носителя, используемый для этой цели, — «multipart/byteranges», как определено в приложении 19.2. См. приложение 19.6.3 по вопросам совместимости.

Ответ на запрос одного диапазона НЕ ДОЛЖЕН быть отправлен с использованием тип носителя multipart/byteranges. Ответ на запрос о несколько диапазонов, результатом которых является один диапазон, МОГУТ быть отправлены как тип носителя multipart/byteranges с одной частью. Клиент, который не может декодировать сообщение multipart/byteranges НЕ ДОЛЖНО запрашивать несколько диапазоны байтов в одном запросе.

Когда клиент запрашивает несколько диапазонов байтов в одном запросе, сервер ДОЛЖЕН возвращать их в том порядке, в котором они появились в запрос.

Если сервер игнорирует спецификацию диапазона байтов, потому что она синтаксически недействителен, сервер ДОЛЖЕН обрабатывать запрос так, как если бы недопустимый диапазон поле заголовка не существует. (Обычно это означает вернуть 200 ответ, содержащий полную сущность).

Если сервер получает запрос (кроме запроса, включающего If- Поле заголовка запроса диапазона) с неудовлетворительным запросом диапазона поле заголовка (то есть все значения byte-range-spec имеют значение first-byte-pos больше, чем текущая длина выбранного ресурс), он ДОЛЖЕН вернуть код ответа 416 (Запрошенный диапазон невыполнимо) (раздел 10.4.17).

 Примечание: клиенты не могут зависеть от серверов при отправке 416 (запрошено
      диапазон неудовлетворителен) ответ вместо ответа 200 (ОК) для
      неудовлетворительный заголовок запроса Range, поскольку не все серверы
      реализовать этот заголовок запроса. 
 

14.17 Тип содержимого

Поле заголовка сущности Content-Type указывает тип носителя сущность-тело, отправляемое получателю, или, в случае метода HEAD, тип носителя, который был бы отправлен, если бы запрос был GET.

 Content-Type = "Content-Type" ":" media-type
 

Типы носителей определены в разделе 3.7. Пример поля

 Content-Type: text/html; кодировка = ISO-8859-4
 

Дальнейшее обсуждение методов определения типа носителя сущность представлена ​​в разделе 7.2.1.

14.18 Дата

Поле общего заголовка «Дата» представляет дату и время, когда сообщение было создано, имея ту же семантику, что и исходная дата в RFC 822. Значением поля является HTTP-дата, как описано в разделе 3.3.1; он ДОЛЖЕН быть отправлен в формате даты RFC 1123 [8].

 Дата = "Дата" ":" HTTP-дата
 

Примером является

 Дата: вторник, 15 ноября 1994 г. , 08:12:31 по Гринвичу
 

Исходные серверы ДОЛЖНЫ включать поле заголовка Date во все ответы, кроме этих случаев:

 1. Если код состояния ответа 100 (Продолжить) или 101 (Переключение
         протоколы), ответ МОЖЕТ включать поле заголовка Date,
         вариант сервера.
 

 2. Если код состояния ответа сообщает об ошибке сервера, т.е. 500
         (внутренняя ошибка сервера) или 503 (служба недоступна), и это
         неудобно или невозможно создать действительную дату.
 

 3. Если на сервере нет часов, которые могут обеспечить
         разумное приближение текущего времени, его реакции
         НЕ ДОЛЖЕН включать поле заголовка Date. В этом случае правила
         в разделе 14.18.1 ДОЛЖНЫ соблюдаться.
 

Полученное сообщение, не имеющее поля заголовка Date, ДОЛЖНО быть назначается получателем, если сообщение будет кэшировано этим получатель или шлюз через протокол, для которого требуется дата. HTTP реализация без часов НЕ ДОЛЖНА кэшировать ответы без перепроверять их при каждом использовании. Кэш HTTP, особенно общий кэш, СЛЕДУЕТ использовать механизм, такой как NTP [28], для синхронизации его часы с надежным внешним эталоном.

Клиенты ДОЛЖНЫ отправлять поле заголовка Date только в сообщениях, которые включают сущность-тело, как в случае запросов PUT и POST, и даже тогда это необязательно. Клиент без часов НЕ ДОЛЖЕН отправлять дату поле заголовка в запросе.

HTTP-дата, отправленная в заголовке Date, НЕ ДОЛЖНА представлять дату и время после генерации сообщения. ДОЛЖЕН представлять наилучшее доступное приближение даты и времени сообщения генерации, если реализация не имеет средств для генерации достаточно точные дата и время. Теоретически дата должна быть представляют момент непосредственно перед созданием сущности. В на практике дата может быть сгенерирована в любой момент во время сообщения происхождения, не затрагивая его семантической ценности.

14.18.1 Работа исходного сервера без часов

В некоторых реализациях исходного сервера часы могут отсутствовать. Исходный сервер без часов НЕ ДОЛЖЕН назначать Expires или Last- Измененные значения для ответа, если только эти значения не были связаны с ресурсом системой или пользователем с надежными часами. Это может назначить известное значение Expires на сервере или до него время конфигурации должно быть в прошлом (это позволяет ответов без сохранения отдельных значений Expires для каждого ресурс).

14.19 ETag

Поле заголовка ответа ETag предоставляет текущее значение тег объекта для запрошенного варианта. Заголовки, используемые с сущностью теги описаны в разделах 14.24, 14.26 и 14.44. Тег сущности МОЖЕТ использоваться для сравнения с другими объектами из того же ресурса. (см. раздел 13.3.3).

 ETag = "ETag" ":" сущность-тег
 

Примеры:

 ETag: "xyzzy"
      ETag: W/"xyzzy"
      Этег: ""
 

14.20 Ожидать

Поле заголовка запроса Expect используется для указания того, что поведение сервера требуется клиенту.

 Ожидать = "Ожидать" ":" 1#ожидание
 

 ожидание = "100-продолжить" | ожидание-расширение
      ожидание-расширение = токен [ "=" ( токен | строка в кавычках )
                               *параметры ожидания]
      ожидаемые параметры = ";" токен [ "=" ( токен | строка в кавычках ) ]
 

Сервер, который не понимает или не может выполнить какое-либо из ожидаемые значения в поле Expect запроса ДОЛЖНЫ ответить с соответствующим статусом ошибки. Сервер ДОЛЖЕН ответить 417 (Ожидание не выполнено) статус, если какое-либо из ожиданий не может быть выполнено или, если есть другие проблемы с запросом, какой-то другой 4xx статус.

Это поле заголовка определяется с помощью расширяемого синтаксиса, позволяющего будущие расширения. Если сервер получает запрос, содержащий Поле ожидания, которое включает в себя расширение ожидания, которого нет поддержки, он ДОЛЖЕН ответить статусом 417 (ошибка ожидания).

Сравнение значений ожидания не зависит от регистра для некавычек токены (включая токен 100-continue) и чувствителен к регистру для ожидание-расширения строки в кавычках.

Механизм Expect является пошаговым: то есть прокси-сервер HTTP/1.1 ДОЛЖЕН вернуть статус 417 (ошибка ожидания), если он получает запрос с надеждой, что она не может оправдаться. Тем не менее, Ожидайте сам заголовок запроса сквозной; он ДОЛЖЕН быть перенаправлен, если запрос переадресован.

Многие старые приложения HTTP/1.0 и HTTP/1.1 не понимают Ожидайте заголовок.

См. раздел 8.2.3 об использовании статуса 100 (продолжить).

14.21 Истекает

Поле заголовка объекта Expires указывает дату/время, после которого ответ считается устаревшим. Устаревшая запись кэша обычно не может быть возвращаемый кешем (либо кешем прокси, либо кешем пользовательского агента) если только он не был предварительно проверен исходным сервером (или промежуточный кеш, в котором есть свежая копия сущности). См. раздел 13.2 для дальнейшего обсуждения модели истечения срока действия.

Наличие поля Expires не означает, что исходный ресурс изменится или перестанет существовать до, или после этого время.

Формат представляет собой абсолютную дату и время, как определено HTTP-датой в раздел 3.3.1; он ДОЛЖЕН быть в формате даты RFC 1123:

 Expires = "Истекает" ":" HTTP-дата
 

Примером его использования является

 Истекает: Чт, 01 декабря 1994 16:00:00 по Гринвичу
 

 Примечание: если ответ содержит поле Cache-Control с максимальным
      возрастная директива (см. раздел 14.9.3), эта директива имеет приоритет над
      Истекает поле.
 

Клиенты и кэши HTTP/1.1 ДОЛЖНЫ обрабатывать другие недопустимые форматы даты, особенно включая значение «0», как в прошлом (т. е. «уже истекший»).

Чтобы пометить ответ как «уже просроченный», исходный сервер отправляет Дата истечения срока действия, равная значению заголовка Date. (см. правила для расчетов истечения в разделе 13.2.4.)

Чтобы пометить ответ как «бессрочный», исходный сервер отправляет Истекает примерно через год с момента получения ответа. послал. Серверы HTTP/1.1 НЕ ДОЛЖНЫ отправлять даты истечения срока действия более одной год в будущем.

Наличие поля заголовка Expires со значением даты время в будущем для ответа, который в противном случае по умолчанию был бы non-cacheable указывает, что ответ можно кэшировать, если только в противном случае указывается полем заголовка Cache-Control (раздел 14.9).

14.22 Из

Поле From request-header, если оно задано, ДОЛЖНО содержать Интернет адрес электронной почты пользователя-человека, который контролирует запрашивающего пользователя агент. Адрес ДОЛЖЕН использоваться машиной, как определено в «почтовом ящике». в RFC 822 [9], обновленном RFC 1123 [8]:

 От = "От" ":" почтовый ящик
 

Пример:

 От кого: [email protected]
 

Это поле заголовка МОЖЕТ использоваться для целей регистрации и как средство для определение источника недействительных или нежелательных запросов. НЕ ДОЛЖНО использоваться в качестве небезопасной формы защиты доступа. Интерпретация этого поля является то, что запрос выполняется от имени данное лицо, которое берет на себя ответственность за выполненный метод. В В частности, агентам роботов СЛЕДУЕТ включать этот заголовок, чтобы с лицом, ответственным за работу робота, можно связаться, если возникнут проблемы происходят на принимающей стороне.

Адрес электронной почты в Интернете в этом поле МОЖЕТ быть отделен от Интернет-хост, выдавший запрос. Например, при запросе передается через прокси, исходный адрес эмитента ДОЛЖЕН быть использовал.

Клиент НЕ ДОЛЖЕН отправлять поле заголовка From без указания пользователя. одобрение, так как это может противоречить интересам конфиденциальности пользователя или политика безопасности их сайта. Настоятельно рекомендуется, чтобы пользователь может отключать, включать и изменять значение этого поля в любое время до запроса.

14.23 Хост

Поле заголовка запроса Host указывает хост и порт Интернета. номер запрашиваемого ресурса, полученный из оригинала URI, предоставленный пользователем или ссылающимся ресурсом (обычно URL-адрес HTTP,

как описано в разделе 3.2.2). Значение поля Host ДОЛЖНО представлять полномочия по именованию исходного сервера или шлюза, предоставленные исходный URL. Это позволяет исходному серверу или шлюзу различать внутренне неоднозначные URL-адреса, такие как корень «/» URL-адрес сервера для нескольких имен хостов на одном IP-адресе.

 Хост = "Хост" ":" хост [ ":" порт ] ; Раздел 3.2.2
 

«Хост» без какой-либо информации о завершающем порте подразумевает значение по умолчанию. порт для запрошенной службы (например, «80» для URL-адреса HTTP). За например, запрос на исходный сервер для должным образом включает:

 ПОЛУЧИТЬ /pub/WWW/HTTP/1.1
       Хост: www. w3.org
 

Клиент ДОЛЖЕН включать поле заголовка Host во все запросы HTTP/1.1. Сообщения . Если запрошенный URI не включает интернет-хост имя запрашиваемой службы, то поле заголовка Host ДОЛЖНО быть задано с пустым значением. Прокси-сервер HTTP/1.1 ДОЛЖЕН гарантировать, что любой сообщение запроса, которое он пересылает, содержит соответствующий заголовок хоста поле, которое идентифицирует услугу, запрошенную прокси. Все Интернет-серверы HTTP/1.1 ДОЛЖНЫ отвечать кодом 400 (неверный запрос). код состояния для любого сообщения запроса HTTP/1.1, в котором отсутствует заголовок узла поле.

См. разделы 5.2 и 19.6.1.1 для других требований, касающихся Хозяин.

14.24 Если-совпадение

Поле заголовка запроса If-Match используется с методом, чтобы сделать его условный. Клиент, который ранее имел одну или несколько сущностей полученный из ресурса, может проверить, что один из этих объектов текущий, включив список связанных с ними тегов сущностей в Поле заголовка If-Match. Теги объектов определены в разделе 3.11. целью этой функции является обеспечение эффективного обновления кэшированных информацию с минимальным объемом транзакционных накладных расходов. Это также используется при обновлении запросов, чтобы предотвратить непреднамеренное изменение неправильная версия ресурса. Как частный случай, значение «*» соответствует любой текущей сущности ресурса.

 If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
 

Если какой-либо из тегов объекта совпадает с тегом объекта, который был бы возвращен в ответ на аналогичный запрос GET (без заголовка If-Match) на этом ресурсе или если указано «*»

и любой текущий объект существует для этого ресурса, то сервер МОЖЕТ выполнить запрошенный метод, как если бы поле заголовка If-Match не существует.

Сервер ДОЛЖЕН использовать функцию строгого сравнения (см. раздел 13.3.3). для сравнения тегов сущностей в If-Match.

Если ни один из тегов объекта не соответствует или если задано «*» и нет текущего объект существует, сервер НЕ ДОЛЖЕН выполнять запрошенный метод, и ДОЛЖЕН вернуть ответ 412 (ошибка предварительного условия). Это поведение наиболее полезно, когда клиент хочет предотвратить метод обновления, например как PUT, от изменения ресурса, который изменился с тех пор, как клиент последний раз извлекал.

Если запрос без поля заголовка If-Match приведет к ничего, кроме статуса 2xx или 412, то заголовок If-Match ДОЛЖЕН быть проигнорирован.

Смысл «If-Match: *» в том, что метод ДОЛЖЕН быть выполнен если представление, выбранное исходным сервером (или кэшем, возможно, с использованием механизма Vary, см. раздел 14.44), и НЕ ДОЛЖЕН выполняться, если представление не существует.

Запрос, предназначенный для обновления ресурса (например, PUT), МОЖЕТ включать Поле заголовка If-Match, чтобы указать, что метод запроса НЕ ДОЛЖЕН быть применяется, если сущность, соответствующая значению If-Match (одиночное тэг объекта) больше не является представлением этого ресурса. Этот позволяет пользователю указать, что он не желает, чтобы запрос успешно, если ресурс был изменен без их ведома. Примеры:

 Если-совпадение: "xyzzy"
       Если-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
       Если-совпадение: *
 

Результат запроса, имеющего как поле заголовка If-Match, так и либо поле заголовка If-None-Match, либо поле If-Modified-Since. не определено этой спецификацией.

14.25 Если-Изменено-С

Поле заголовка запроса If-Modified-Since используется с методом для сделать его условным: если запрошенный вариант не был изменен с момента, указанного в этом поле, сущность не будет возвращено с сервера; вместо этого ответ 304 (не измененный) будет возвращаться без какого-либо тела сообщения.

 If-Modified-Since = "If-Modified-Since" ":" HTTP-дата
 

Пример поля:

 If-Modified-Since: сб, 29 октября 1994 г., 19:43:31 по Гринвичу
 

Метод GET с заголовком If-Modified-Since и без заголовка Range. запрашивает, чтобы идентифицированный объект был передан только в том случае, если он был изменен с даты, указанной в заголовке If-Modified-Since. Алгоритм определения этого включает следующие случаи:

 а) Если запрос обычно приводит к чему-либо, кроме
         200 (ОК), или если переданная дата If-Modified-Since
         недействителен, ответ точно такой же, как и при обычном GET.
         Дата, более поздняя, ​​чем текущее время сервера,
         инвалид.
 

 b) Если вариант был изменен с момента If-Modified-Since
         date ответ точно такой же, как и при обычном GET.
 

 c) Если вариант не был изменен с момента действительного If-
         Modified-Since date, сервер ДОЛЖЕН возвращать 304 (не
         Измененный) ответ.
 

Цель этой функции — разрешить эффективное обновление кэшированных информацию с минимальным объемом транзакционных накладных расходов.

 Примечание. Поле заголовка запроса Range изменяет значение If-
      Модифицировано-с; подробности см. в разделе 14.35.
 

 Примечание. Время If-Modified-Since интерпретируется сервером, чей
      часы могут быть не синхронизированы с клиентом. 
 

 Примечание. При обработке поля заголовка If-Modified-Since некоторые
      серверы будут использовать функцию сравнения точной даты, а не
      функция «меньше чем» для принятия решения о том, следует ли отправлять 304 (не
      Измененный) ответ. Чтобы получить наилучшие результаты при отправке If-
      Поле заголовка Modified-Since для проверки кэша, клиенты
      рекомендуется использовать точную строку даты, полученную в предыдущем Last-
      По возможности изменено поле заголовка.
 

 Примечание. Если клиент использует произвольную дату в поле If-Modified-Since
      заголовок вместо даты, взятой из заголовка Last-Modified для
      тот же запрос, клиент должен осознавать тот факт, что это
      date интерпретируется в понимании времени сервером.
      клиент должен учитывать несинхронизированные часы и проблемы с округлением
      из-за разных кодировок времени между клиентом и
      сервер. Это включает в себя возможность условий гонки, если
      документ изменился между моментом его первого запроса и
      дата If-Modified-Since последующего запроса и
 

 вероятность проблем, связанных с рассогласованием часов, если If-Modified-
      Поскольку дата выводится из часов клиента без коррекции
      к часам сервера.  Поправки для разных временных баз
      между клиентом и сервером в лучшем случае приблизительны из-за сетевых
      задержка.
 

Результат запроса, имеющего как поле заголовка If-Modified-Since, и поля заголовка If-Match или If-Unmodified-Since не определено этой спецификацией.

14.26 Если не совпадает

Поле заголовка запроса If-None-Match используется с методом для создания это условно. Клиент, который ранее имел одну или несколько сущностей полученный из ресурса, может проверить, что ни один из этих объектов не текущий, включив список связанных с ними тегов сущностей в Поле заголовка If-None-Match. Цель этой функции состоит в том, чтобы позволить эффективное обновление кэшированной информации с минимальным объемом транзакционные накладные расходы. Он также используется для предотвращения метода (например, PUT) от непреднамеренного изменения существующего ресурса, когда клиент считает, что ресурса не существует.

Как особый случай, значение «*» соответствует любому текущему объекту ресурс.

 If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
 

Если какой-либо из тегов объекта совпадает с тегом объекта, который был бы возвращен в ответ на аналогичный запрос GET (без заголовка If-None-Match) на этом ресурсе или если «*» данный и любая текущая сущность существует для этого ресурса, то сервер НЕ ДОЛЖЕН выполнять запрошенный метод, если только это не требуется так как дата модификации ресурса не соответствует этой предоставляется в поле заголовка If-Modified-Since в запросе. Вместо этого, если метод запроса был GET или HEAD, сервер ДОЛЖЕН ответить ответом 304 (не изменено), включая кеш- связанные поля заголовка (в частности, ETag) одного из объектов, которые совпало. Для всех других методов запроса сервер ДОЛЖЕН ответить статус 412 (сбой предварительного условия).

См. раздел 13.3.3 для правил о том, как определить, являются ли теги двух сущностей соответствие. Функция слабого сравнения может использоваться только с GET или HEAD. Запросы.

Если ни один из тегов сущности не совпадает, сервер МОЖЕТ выполнить запрошенный метод, как если бы поле заголовка If-None-Match не существовало, но ДОЛЖНЫ также игнорировать любые поля заголовка If-Modified-Since в запрос. То есть, если никакие теги сущностей не совпадают, сервер НЕ ДОЛЖЕН вернуть ответ 304 (не изменено).

Если запрос будет без поля заголовка If-None-Match, результат в любом другом статусе, кроме 2xx или 304, то If-None-Match заголовок ДОЛЖЕН игнорироваться. (См. раздел 13.3.4 для обсуждения поведение сервера, когда появляются и If-Modified-Since, и If-None-Match в том же запросе)

Значение «If-None-Match: *» в том, что метод НЕ ДОЛЖЕН быть выполняется, если представление, выбранное исходным сервером (или кэш, возможно, с использованием механизма Vary, см. раздел 14.44) существует, и СЛЕДУЕТ выполняться, если представление не существует. Эта функция предназначена для предотвращения гонок между PUT. операции.

Примеры:

 Если-Нет-совпадения: "xyzzy"
       If-None-Match: W/"xyzzy"
       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
       Если-нет-совпадения: *
 

Результат запроса, имеющего как поле заголовка If-None-Match, так и либо поле заголовка If-Match, либо поле заголовка If-Unmodified-Since. не определено этой спецификацией.

14,27 Если-диапазон

Если у клиента есть частичная копия объекта в его кеше, и он желает чтобы иметь актуальную копию всего объекта в своем кеше, он можно использовать заголовок запроса Range с условным GET (используя один или оба из If-Unmodified-Since и If-Match.) Однако, если условие не выполняется, потому что сущность была изменена, клиент затем придется сделать второй запрос, чтобы получить весь текущий сущность-тело.

Заголовок If-Range позволяет клиенту «замкнуть» второй запрос. Неформально это означает: «если объект не изменился, отправить мне часть (части), которые мне не хватает; в противном случае пришлите мне весь новый организация’.

 If-Range = "If-Range" ":" (entity-tag | HTTP-date)
 

Если у клиента нет тега сущности для сущности, но есть Last- Дата изменения, МОЖЕТ использовать эту дату в заголовке If-Range. ( сервер может различать допустимую дату HTTP и любую форму entity-tag, проверив не более двух символов.) If-Range заголовок СЛЕДУЕТ использовать только вместе с заголовком Range и ДОЛЖЕН быть игнорируется, если запрос не включает заголовок Range или если сервер не поддерживает операцию поддиапазона.

Если тег объекта, указанный в заголовке If-Range, соответствует текущему тэг объекта для объекта, то сервер ДОЛЖЕН предоставить указанный поддиапазон объекта с использованием 206 (частичное содержимое) отклик. Если тег объекта не совпадает, то сервер ДОЛЖЕН вернуть весь объект, используя ответ 200 (ОК).

14.28 Если-без изменений-с

Поле заголовка запроса If-Unmodified-Since используется с методом для сделать его условным. Если запрошенный ресурс не был изменен с момента, указанного в этом поле, сервер ДОЛЖЕН выполнить запрошенная операция, как если бы заголовок If-Unmodified-Since не был подарок.

Если запрошенный вариант был изменен с указанного времени, сервер НЕ ДОЛЖЕН выполнять запрошенную операцию и ДОЛЖЕН возвращать 412 (сбой предварительного условия).

 If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-дата
 

Пример поля:

 If-Unmodified-Since: сб, 29 октября 1994 г., 19:43:31 по Гринвичу
 

Если запрос нормальный (т.е. без If-Unmodified-Since заголовок) приведет к чему-то другому, кроме статуса 2xx или 412, Заголовок If-Unmodified-Since ДОЛЖЕН игнорироваться.

Если указанная дата недействительна, заголовок игнорируется.

Результат запроса с заголовком If-Unmodified-Since поле и заголовок If-None-Match или If-Modified-Since fields не определено этой спецификацией.

14.29 Последнее изменение

Поле заголовка объекта Last-Modified указывает дату и время который исходный сервер считает, что вариант был последним изменен.

 Last-Modified = "Last-Modified" ":" HTTP-дата
 

Примером его использования является

 Последнее изменение: Вт, 15 ноября 1994 г., 12:45:26 GMT
 

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

Исходный сервер НЕ ДОЛЖЕН отправлять дату последнего изменения, которая является более поздней. чем время отправки сообщения сервером. В таких случаях, когда последняя модификация ресурса указывала бы на какое-то время в будущем сервер ДОЛЖЕН заменить эту дату сообщением дата возникновения.

Исходный сервер ДОЛЖЕН получить значение Last-Modified объекта как можно ближе ко времени, когда он генерирует значение Date для его ответ. Это позволяет получателю сделать точную оценку времени модификации объекта, особенно если объект изменяется рядом с моментом генерации ответа.

Серверы HTTP/1.1 ДОЛЖНЫ отправлять Last-Modified всякий раз, когда это возможно.

14.30 Адрес

Поле заголовка ответа Location используется для перенаправления получателя в место, отличное от Request-URI для завершения запрос или идентификация нового ресурса. Для 201 (Создано) ответы, это местоположение нового ресурса, который был создан по запросу. Для ответов 3xx местоположение ДОЛЖНО указывать предпочтительный URI сервера для автоматического перенаправления на ресурс. значение поля состоит из одного абсолютного URI.

 Местоположение = "Расположение" ":" absoluteURI
 

Пример:

 Местонахождение: http://www.w3.org/pub/WWW/People.html
 

 Примечание. Поле заголовка Content-Location (раздел 14.14) отличается
      from Location в том, что Content-Location идентифицирует оригинал
      местонахождение объекта, включенного в запрос. Поэтому
      возможно, чтобы ответ содержал поля заголовка как для местоположения,
      и Контент-Местоположение. Также см. раздел 13.10 для кеша.
      Требования некоторых методов.
 

14.31 Макс-Форвард

Поле заголовка запроса Max-Forwards предоставляет механизм с TRACE (раздел 9.8) и OPTIONS (раздел 9.2) для ограничения количество прокси или шлюзов, которые могут перенаправить запрос на следующий входящий сервер. Это может быть полезно, когда клиент пытается чтобы отследить цепочку запросов, которая, кажется, терпит неудачу или зацикливается средняя цепь.

 Макс. вперед = "Макс. вперед" ":" 1*ЦИФРА
 

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

Каждый получатель прокси или шлюза запроса TRACE или OPTIONS содержащее поле заголовка Max-Forwards, ДОЛЖНО проверять и обновлять его значение до пересылки запроса. Если полученное значение равно нулю (0) получатель НЕ ДОЛЖЕН пересылать запрос; вместо этого он ДОЛЖЕН ответить как конечный получатель. Если полученное значение Max-Forwards равно больше нуля, то пересылаемое сообщение ДОЛЖНО содержать обновленный Поле Max-Forwards со значением, уменьшенным на единицу (1).

Поле заголовка Max-Forwards МОЖЕТ игнорироваться для всех остальных методов. определенных этой спецификацией и для любых методов расширения, для которых он явно не упоминается как часть определения этого метода.

14.32 Прагма

Поле общего заголовка Pragma используется для включения конкретные директивы, которые могут применяться к любому получателю на протяжении цепочка запросов/ответов. Все директивы прагмы указывают необязательный поведение с точки зрения протокола; однако некоторые системы МОЖЕТ требовать, чтобы поведение соответствовало директивам.

 Pragma = "Pragma" ":" 1#pragma-directive
       прагма-директива = "без кеша" | расширение-прагма
       extension-pragma = токен [ "=" ( токен | строка в кавычках ) ]
 

Когда директива no-cache присутствует в сообщении запроса, приложение ДОЛЖНО пересылать запрос исходному серверу даже если у него есть кешированная копия того, что запрашивается. Эта прагма директива имеет ту же семантику, что и директива кэша no-cache (см. раздел 14.9) и определен здесь для обратной совместимости с HTTP/1.0. Клиенты ДОЛЖНЫ включать оба поля заголовка, если нет кэша. запрос отправляется на сервер, о котором не известно, что он совместим с HTTP/1.1.

Директивы Pragma ДОЛЖНЫ передаваться через прокси или шлюз приложение, независимо от их значимости для этого приложения, поскольку директивы могут быть применимы ко всем получателям на цепочка запросов/ответов. Невозможно указать прагму для конкретный получатель; однако любая директива прагмы, не относящаяся к получатель ДОЛЖЕН игнорироваться этим получателем.

Кэши HTTP/1.1 ДОЛЖНЫ обрабатывать «Pragma: no-cache», как если бы клиент отправил «Кэш-Контроль: нет кеша». Никаких новых директив Pragma не будет. определено в HTTP.

 Примечание: поскольку значение «Прагма: без кеша в качестве ответа
      поле заголовка на самом деле не указано, оно не обеспечивает
      надежная замена "Cache-Control: no-cache" в ответе
 

14.33 Прокси-аутентификация

Поле заголовка ответа Proxy-Authenticate ДОЛЖНО быть включено как часть ответа 407 (требуется аутентификация прокси-сервера). Значение поля состоит из вызова, указывающего схему аутентификации и параметры, применимые к прокси для этого Request-URI.

 Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
 

Процесс аутентификации доступа HTTP описан в разделе «HTTP Аутентификация: базовая и дайджест-аутентификация доступа» [43]. В отличие от WWW-Authenticate, поле заголовка Proxy-Authenticate применяется только к текущее соединение и НЕ ДОЛЖНО передаваться вниз по течению клиенты. Однако промежуточному прокси-серверу может потребоваться получить собственный учетные данные, запрашивая их у нижестоящего клиента, который в некоторые обстоятельства будут выглядеть так, как будто прокси-сервер пересылает Поле заголовка Proxy-Authenticate.

14.34 Прокси-авторизация

Поле заголовка запроса Proxy-Authorization позволяет клиенту идентифицировать себя (или своего пользователя) для прокси-сервера, который требует аутентификация. Значение поля Proxy-Authorization состоит из учетные данные, содержащие информацию об аутентификации пользователя агент для прокси и/или области запрашиваемого ресурса.

 Прокси-Авторизация = "Прокси-Авторизация" ":" учетные данные
 

Процесс аутентификации доступа HTTP описан в разделе «HTTP Аутентификация: базовая и дайджест-аутентификация доступа» [43]. В отличие от Authorization, поле заголовка Proxy-Authorization относится только к следующий исходящий прокси-сервер, который требовал аутентификации с использованием прокси-сервера. Поле аутентификации. Когда несколько прокси используются в цепочке,

Поле заголовка Proxy-Authorization используется первым исходящим прокси, который ожидал получить учетные данные. Прокси МОЖЕТ ретранслировать учетные данные от клиентского запроса к следующему прокси-серверу, если это механизм, с помощью которого прокси совместно аутентифицируют данный запрос.

14,35 Диапазон

14.

35.1 Диапазоны байтов

Поскольку все объекты HTTP представлены в сообщениях HTTP в виде последовательностей байтов, понятие диапазона байтов имеет смысл для любого HTTP организация. (Однако не все клиенты и серверы должны поддерживать байт-код. диапазонные операции.)

Спецификации диапазона байтов в HTTP применяются к последовательности байтов в тело объекта (не обязательно такое же, как тело сообщения).

Операция диапазона байтов МОЖЕТ указывать один диапазон байтов или набор диапазонов внутри одного объекта.

 спецификатор диапазонов = спецификатор диапазонов байтов
       спецификатор диапазонов байтов = единица байтов "=" набор диапазонов байтов
       байт-диапазон-набор = 1#( байт-диапазон-спецификация | суффикс-байт-диапазон-спецификация)
       byte-range-spec = первая позиция байта "-" [последняя позиция байта]
       первый байт-поз = 1*ЦИФРА
       последний байт-поз = 1*ЦИФРА
 

Значение first-byte-pos в byte-range-spec дает смещение байта. первого байта в диапазоне. Значение last-byte-pos дает byte-offset последнего байта в диапазоне; то есть байт указанные позиции являются включительно. Байтовые смещения начинаются с нуля.

Если присутствует значение last-byte-pos, оно ДОЛЖНО быть больше или равно первому байту-позиции в этой спецификации байт-диапазона или байту- range-spec синтаксически недействителен. Получатель диапазона байтов- набор, включающий одну или несколько синтаксически недопустимых спецификаций диапазона байтов значения ДОЛЖНЫ игнорировать поле заголовка, которое включает этот диапазон байтов. установлен.

Если значение last-byte-pos отсутствует или если значение больше или равна текущей длине тела сущности, last-byte-pos принимается равным на единицу меньше, чем текущая длина сущности- тело в байтах.

Выбрав last-byte-pos, клиент может ограничить количество байтов, полученных без знания размера объекта.

 suffix-byte-range-spec = "-" длина суффикса
       длина суффикса = 1*ЦИФРА
 

Suffix-byte-range-spec используется для указания суффикса сущность-тело, длина которой определяется значением длины суффикса. (То есть, эта форма определяет последние N байтов тела сущности.) Если сущность короче указанной длины суффикса, весь используется сущность-тело.

Если синтаксически допустимый набор диапазонов байтов включает хотя бы один range-spec, первый байт-pos которого меньше текущей длины тело объекта или, по крайней мере, один suffix-byte-range-spec с не- нулевая длина суффикса, то набор диапазонов байтов выполним. В противном случае набор диапазонов байтов неудовлетворителен. Если набор диапазонов байтов является неудовлетворительным, сервер ДОЛЖЕН вернуть ответ со статусом из 416 (запрашиваемый диапазон не удовлетворяется). В противном случае сервер СЛЕДУЕТ вернуть ответ со статусом 206 (Частичное содержимое) содержащий допустимые диапазоны тела сущности.

Примеры значений спецификатора диапазонов байтов (при условии, что тело объекта длина 10000):

 - Первые 500 байт (байтовые смещения 0-499 включительно): bytes=0-
        499
 

 - Вторые 500 байт (байтовые смещения 500-999 включительно):
        байты=500-999
 

 - Последние 500 байт (байтовые смещения 9500-9999 включительно):
        байт=-500
 

 - или байт=9500-
 

 - Только первый и последний байты (байты 0 и 9999): байты=0-0,-1
 

 - Несколько легальных, но не канонических спецификаций вторых 500
        байты (байтовые смещения 500-999 включительно):
         байты=500-600,601-999
         байты=500-700,601-999
 

14.

35.2 Запросы на получение диапазона

HTTP-запросы на поиск с использованием условного или безусловного GET методы МОГУТ запрашивать один или несколько поддиапазонов объекта вместо весь объект, используя заголовок запроса Range, который применяется к сущность, возвращенная в результате запроса:

 Диапазон = "Диапазон" ":" спецификатор диапазонов
 

Сервер МОЖЕТ игнорировать заголовок Range. Однако происхождение HTTP/1.1 серверы и промежуточные кэши должны поддерживать диапазоны байтов, когда возможно, так как Range поддерживает эффективное восстановление после частичного неудачные передачи и поддерживает эффективное частичное извлечение больших сущности.

Если сервер поддерживает заголовок Range и указанный диапазон или диапазоны подходят для объекта:

 — наличие заголовка Range в безусловном GET изменяет
        что возвращается, если GET в противном случае успешен. В других
        словами, ответ содержит код состояния 206 (частичный
        содержание) вместо 200 (ОК). 
 

 - Наличие заголовка Range в условном GET (запрос
        используя один или оба из If-Modified-Since и If-None-Match, или
        один или оба из If-Unmodified-Since и If-Match) изменяют то, что
        возвращается, если GET в остальном успешен и
        условие верно. Это не влияет на 304 (не изменено)
        ответ возвращается, если условие ложно.
 

В некоторых случаях может быть более подходящим использовать If-Range. заголовок (см. раздел 14.27) в дополнение к заголовку Range.

Если прокси, поддерживающий диапазоны, получает запрос диапазона, пересылает запрос на входящий сервер и получает весь объект в ответ, он ДОЛЖЕН возвращать своему клиенту только запрошенный диапазон. Это СЛЕДУЕТ хранить весь полученный ответ в своем кеше, если это в соответствии с его политиками распределения кеша.

14.36 Реферер

Поле заголовка запроса Referer[sic] позволяет клиенту указать, для сервера адрес (URI) ресурса из который был получен Request-URI («реферер», хотя в поле заголовка написана ошибка. ) Заголовок запроса Referer позволяет сервер для генерации списков обратных ссылок на интересующие ресурсы, ведение журнала, оптимизированное кэширование и т. д. Это также позволяет ссылки для обслуживания. Поле Referer НЕ ДОЛЖНО быть отправляется, если Request-URI был получен из источника, не имеющего свой собственный URI, например ввод с пользовательской клавиатуры.

 Referer = "Referer" ":" ( absoluteURI | относительныйURI )
 

Пример:

 Реферер: http://www.w3.org/hypertext/DataSources/Overview.html
 

Если значение поля является относительным URI, его СЛЕДУЕТ интерпретировать относительно Request-URI. URI НЕ ДОЛЖЕН включать фрагмент. Видеть раздел 15.1.3 по соображениям безопасности.

14.37 Повторить-После

Поле заголовка ответа Retry-After можно использовать с кодом 503 (Service Недоступно) ответ, чтобы указать, как долго ожидается, что услуга быть недоступным для запрашивающего клиента. Это поле МОЖЕТ также использоваться с любым ответом 3xx (перенаправление), чтобы указать минимальное время, в течение которого агенту пользователя предлагается подождать, прежде чем выдавать перенаправленный запрос. значение этого поля может быть как HTTP-датой, так и целым числом секунд (в десятичном формате) после времени ответа.

 Retry-After = "Retry-After" ":" (HTTP-дата | дельта-секунды)
 

Два примера его использования:

 Повторить после: пятница, 31 декабря 1999 г., 23:59:59 GMT
       Повторить после: 120
 

В последнем примере задержка составляет 2 минуты.

14.38 Сервер

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

 Сервер = "Сервер" ":" 1*( продукт | комментарий )
 

Пример:

 Сервер: CERN/3.0 libwww/2.17
 

Если ответ пересылается через прокси, прокси приложение НЕ ДОЛЖНО изменять заголовок ответа сервера. Вместо этого это СЛЕДУЕТ включать поле Via (как описано в разделе 14.45).

 Примечание. Раскрытие конкретной версии программного обеспечения сервера может
      сделать серверную машину более уязвимой для атак
      против программного обеспечения, которое, как известно, содержит дыры в безопасности. Сервер
      разработчикам рекомендуется сделать это поле настраиваемым
      вариант.
 

14,39 ТЭ

Поле заголовка запроса TE указывает, какое кодирование передачи расширения он готов принять в ответ и независимо от того, является ли он готов принять поля трейлера в кодировании передачи по частям. Его значение может состоять из ключевого слова «трейлеры» и/или через запятую список имен кодирования передачи расширений с необязательным принятием параметры (как описано в разделе 3. 6).

 TE = "TE" ":" #(t-коды)
       t-кодировки = "прицепы" | (передача-расширение [принять-параметры])
 

Наличие ключевого слова «трейлеры» говорит о том, что клиент готов принять поля трейлера в кодировании передачи по частям, как определено в разделе 3.6.1. Это ключевое слово зарезервировано для использования с значений переносного кодирования, даже если оно само по себе не представляет собой передача-кодирование.

Примеры его использования:

 TE: сдуть
       ТЭ:
       TE: прицепы, сдутые; q=0,5
 

Поле заголовка TE применяется только к непосредственному соединению. Следовательно, ключевое слово ДОЛЖНО быть указано в заголовке Connection. поле (раздел 14.10) всякий раз, когда TE присутствует в сообщении HTTP/1.1.

Сервер проверяет, допустимо ли кодирование передачи в соответствии с поле TE, используя следующие правила:

 1. Всегда допустимо «разделенное» кодирование передачи.  Если
         указано ключевое слово "трейлеры", клиент указывает, что это
         готов принять поля трейлера в ответе на фрагменты на
         от имени себя и любых нижестоящих клиентов. Подразумевается
         что, если дано, клиент заявляет, что либо все
         нижестоящие клиенты готовы принимать поля трейлера в
         перенаправленный ответ, или что он попытается буферизовать
         ответ от имени нижестоящих получателей.
 

 Примечание. HTTP/1.1 не определяет никаких средств для ограничения размера
         фрагментированный ответ, чтобы клиент мог быть уверен в буферизации
         весь ответ.
 

 2. Если тестируемое кодирование передачи является одним из
         кодировки, перечисленные в поле TE, то она приемлема, если только она не
         сопровождается значением q, равным 0. (Как определено в разделе 3.9,
         qvalue 0 означает «неприемлемо».)
 

 3. Если допускается множественное кодирование передачи, то
         допустимое кодирование передачи с наибольшим ненулевым значением q равно
         предпочтительно.  «Разбитое» кодирование передачи всегда имеет qvalue
         из 1.
 

Если значение поля TE пусто или если поле TE отсутствует, единственное кодирование передачи «разделено». Сообщение без кодирования передачи всегда приемлемо.

14.40 Трейлер

Значение поля Trailer general указывает, что данный набор поля заголовка присутствуют в трейлере сообщения, закодированного с помощью фрагментированное кодирование передачи.

 Trailer = "Trailer" ":" 1#имя поля
 

Сообщению HTTP/1.1 СЛЕДУЕТ включать поле заголовка Trailer в сообщение с использованием фрагментированного кодирования передачи с непустым трейлером. Делает таким образом позволяет получателю узнать, какие поля заголовка ожидать в трейлер.

Если поле заголовка Trailer отсутствует, трейлер НЕ ДОЛЖЕН включать любые поля заголовка. См. раздел 3.6.1 для ограничений на использование концевые поля в «фрагментированном» кодировании передачи.

Поля заголовка сообщения, перечисленные в поле заголовка Trailer, НЕ ДОЛЖНЫ включать следующие поля заголовка:

 . Передача-кодирование
 

 . Длина содержимого
 

 . Трейлер
 

14.41 Кодирование передачи

Поле общего заголовка Transfer-Encoding указывает, что (если есть) тип преобразования был применен к телу сообщения, чтобы безопасно передать его между отправителем и получателем. Этот отличается от кодирования контента тем, что кодирование передачи представляет собой свойство сообщения, а не сущности.

 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
 

Кодирование передачи определено в разделе 3.6. Пример:

 Transfer-Encoding: фрагментировано
 

Если к объекту было применено несколько кодировок, Кодировки ДОЛЖНЫ быть перечислены в том порядке, в котором они были применены. МОЖЕТ быть предоставлена ​​дополнительная информация о параметрах кодирования. другими полями заголовка объекта, не определенными в этой спецификации.

Многие старые приложения HTTP/1.0 не понимают механизм передачи. Заголовок кодировки.

14.42 Обновление

Общий заголовок Upgrade позволяет клиенту указать, что дополнительные протоколы связи, которые он поддерживает и хотел бы использовать если сервер сочтет целесообразным переключить протоколы. Сервер НЕОБХОДИМО использовать поле заголовка Upgrade в сообщении 101 (Switching Protocols). ответ, чтобы указать, какой протокол(ы) переключается.

 Обновление = "Обновление" ":" 1#продукт
 

Например,

 Обновление: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
 

Поле заголовка Upgrade предназначено для предоставления простого механизма для перехода с HTTP/1.1 на какой-то другой, несовместимый протокол. Это делает это, позволяя клиенту объявить о своем желании использовать другой протокол, такой как более поздняя версия HTTP с более высокой основной версией номер, даже если текущий запрос был сделан с использованием HTTP/1. 1. Это облегчает трудный переход между несовместимыми протоколами за счет позволяя клиенту инициировать запрос в более обычном поддерживаемый протокол, указывая при этом серверу, что он хотел бы использовать «лучший» протокол, если он доступен (где «лучший» определяется сервером, возможно, в зависимости от характера метода и/или запрашиваемый ресурс).

Поле заголовка Upgrade применяется только к переключению прикладного уровня. протоколы при существующем соединении транспортного уровня. Обновление нельзя использовать, чтобы настаивать на изменении протокола; его принятие и использование сервером не является обязательным. Возможности и характер связь на уровне приложений после того, как изменение протокола полностью зависит от выбранного нового протокола, хотя первое действие после изменения протокола ДОЛЖЕН быть ответ на начальный HTTP запрос, содержащий поле заголовка Upgrade.

Поле заголовка Upgrade применяется только к непосредственному соединению. Следовательно, ключевое слово upgrade ДОЛЖНО быть указано в сообщении Connection. поле заголовка (раздел 14.10) всякий раз, когда Upgrade присутствует в Сообщение HTTP/1.1.

Поле заголовка Upgrade нельзя использовать для указания перехода на протокол по другому соединению. Для этой цели более целесообразно использовать ответ перенаправления 301, 302, 303 или 305.

Эта спецификация определяет только имя протокола «HTTP» для использования семейство протоколов передачи гипертекста, как определено HTTP правила версии раздела 3.1 и будущие обновления этого Технические характеристики. В качестве имени протокола можно использовать любой токен; однако это будет полезен только в том случае, если и клиент, и сервер связывают имя с тем же протоколом.

14.43 Агент пользователя

Поле заголовка запроса User-Agent содержит информацию о пользовательский агент, инициирующий запрос. Это для статистических целей, отслеживание нарушений протокола и автоматическое распознавание пользовательских агенты ради адаптации ответов, чтобы избежать конкретного пользователя агентские ограничения. Пользовательские агенты ДОЛЖНЫ включать это поле с Запросы. Поле может содержать несколько токенов продукта (раздел 3.8). и комментарии, идентифицирующие агента и любые подпродукты, которые формируют значительную часть пользовательского агента. По соглашению, токены продукта перечислены в порядке их значимости для идентификации заявление.

 User-Agent = "User-Agent" ":" 1*( продукт | комментарий )
 

Пример:

 Агент пользователя: CERN-LineMode/2.15 libwww/2.17b3
 

14,44 Варьируется

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

 Vary = "Vary" ":" ("*" | 1#имя поля)
 

Серверу HTTP/1.1 СЛЕДУЕТ включать поле заголовка Vary с любым кэшируемый ответ, который подлежит согласованию с сервером. Это позволяет кешу правильно интерпретировать будущие запросы на этом ресурса и информирует пользовательский агент о наличии согласования

на том ресурсе. Сервер МОЖЕТ включать поле заголовка Vary с некэшируемый ответ, который подлежит согласованию с сервером, поскольку это может предоставить пользовательскому агенту полезную информацию о размеры, по которым отклик изменяется во время отклик.

Значение поля Vary, состоящее из списка имен полей, сигнализирует о том, что представление, выбранное для ответа, основано на выборе алгоритм, который учитывает ТОЛЬКО перечисленные значения полей заголовка запроса в выборе наиболее подходящего представления. Кэш МОЖЕТ предполагать что такой же выбор будет сделан для будущих запросов с те же значения для перечисленных имен полей, в течение времени для что ответ свежий.

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

Значение поля Vary, равное «*», сигнализирует о том, что неуказанные параметры не ограничивается заголовками запроса (например, сетевым адресом client), играют роль в выборе представления ответа. Значение «*» НЕ ДОЛЖНО генерироваться прокси-сервером; это может быть только генерируется исходным сервером.

14.45 Через

Поле общего заголовка Via ДОЛЖНО использоваться шлюзами и прокси для указать промежуточные протоколы и получателей между пользователем агентом и сервером по запросам, а также между исходным сервером и клиент по отзывам. Аналог поля «Получено» RFC 822 [9] и предназначен для отслеживания пересылки сообщений, избегая циклов запросов и определяя возможности протокола все отправители по цепочке запрос/ответ.

 Via = "Via" ":" 1#(полученный-протокол полученный [комментарий])
      полученный-протокол = [имя-протокола "/"] версия-протокола
      имя-протокола = токен
      версия протокола = токен
      получено = (хост [ ":" порт ] ) | псевдоним
      псевдоним = жетон
 

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

Имя протокола является необязательным тогда и только тогда, когда это будет «HTTP». поле «получено по» обычно представляет собой хост и необязательный номер порта сервер-получатель или клиент, который впоследствии переслал сообщение. Однако, если реальный хост считается конфиденциальной информацией, он МОЖЕТ быть заменен псевдонимом. Если порт не указан, он МОЖЕТ предполагается, что он является портом по умолчанию для полученного протокола.

Несколько значений поля Via представляют каждый прокси или шлюз, переслал сообщение. Каждый получатель ДОЛЖЕН добавить свою информацию таким образом, что конечный результат упорядочен в соответствии с последовательностью переадресация заявок.

Комментарии МОГУТ использоваться в поле заголовка Via для идентификации программного обеспечения. прокси-сервера или шлюза получателя, аналогичный User-Agent и Поля заголовка сервера. Однако все комментарии в поле Via необязательный и МОЖЕТ быть удален любым получателем до пересылки сообщение.

Например, сообщение запроса может быть отправлено пользователем HTTP/1.0. агента к внутреннему прокси-серверу под кодовым названием «fred», который использует HTTP/1.1 для перенаправить запрос на общедоступный прокси на nowhere.com, что завершает запрос, перенаправив его на исходный сервер по адресу www.ics.uci.edu. Запрос, полученный www.ics.uci.edu, будет иметь следующий вид: Через поле заголовка:

 Через: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
 

Прокси и шлюзы, используемые в качестве портала через сетевой брандмауэр НЕ ДОЛЖНО по умолчанию перенаправлять имена и порты хостов в область брандмауэра. Эту информацию СЛЕДУЕТ распространять только в том случае, если явно включен. Если не включено, полученный хост любого хоста за брандмауэром СЛЕДУЕТ заменить соответствующим псевдонимом для этого хоста.

Для организаций, предъявляющих строгие требования к конфиденциальности для сокрытия внутренние структуры, прокси МОЖЕТ комбинировать упорядоченную подпоследовательность Через записи полей заголовка с идентичными значениями полученного протокола в единственная такая запись. Например,

 Через: 1.0 Рикки, 1.1 Этель, 1.1 Фред, 1.0 Люси
 

 можно свернуть в
 

 Через: 1.0 Рикки, 1.1 Мерц, 1.0 Люси
 

Приложения НЕ ДОЛЖНЫ объединять несколько записей, если они не все под тем же организационным контролем и хосты уже были заменены псевдонимами. Приложения НЕ ДОЛЖНЫ объединять записи, которые имеют разные значения протокола приема.

14.46 Предупреждение

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

Заголовки предупреждений отправляются с ответами, используя:

 Предупреждение = "Предупреждение" ":" 1#значение-предупреждения
 

 warning-value = предупреждающий код SP предупреждающий агент SP предупредительный текст
                                             [дата предупреждения SP]
 

 код предупреждения = 3-ЗНАЧНЫЙ
       предупреждающий агент = (хост [ ":" порт ] ) | псевдоним
                       ; имя или псевдоним сервера добавления
                       ; заголовок Warning для использования при отладке
       предупреждающий текст = строка в кавычках
       дата-предупреждения = <"> HTTP-дата <">
 

Ответ МОЖЕТ содержать более одного заголовка предупреждения.

Предупреждающий текст ДОЛЖЕН быть на естественном языке и с набором символов, скорее всего, будет понятен пользователю-человеку, получающему отклик. Это решение МОЖЕТ быть основано на любых доступных знаниях, таких как в качестве расположения кеша или пользователя, поле Accept-Language в запрос, поле Content-Language в ответе и т. д. По умолчанию язык — английский, а набор символов по умолчанию — ISO-8859.-1.

Если используется набор символов, отличный от ISO-8859-1, он ДОЛЖЕН быть закодирован в тексте предупреждения с использованием метода, описанного в RFC 2047 [14].

Заголовки предупреждений, как правило, могут быть применены к любому сообщению, однако некоторые специальные коды предупреждений относятся к кэшам и могут быть применяется к ответным сообщениям. ДОЛЖНЫ быть добавлены новые заголовки предупреждений после любых существующих заголовков Warning. Кэш НЕ ДОЛЖЕН удалять какие-либо Заголовок предупреждения, полученный вместе с сообщением. Однако, если кеш успешно проверяет запись в кэше, он ДОЛЖЕН удалить все предупреждения заголовки, ранее прикрепленные к этой записи, за исключением случаев, указанных для

специальные коды предупреждений. Затем он ДОЛЖЕН добавить любые полученные заголовки предупреждений. в подтверждающем ответе. Другими словами, заголовки Warning — это те который будет приложен к самому последнему соответствующему ответу.

Если к ответу прикреплено несколько заголовков Warning, пользователь агент должен информировать пользователя о как можно большем количестве из них, в порядок их появления в ответе. Если нет возможности информировать пользователя обо всех предупреждениях, пользовательский агент ДОЛЖЕН следовать эти эвристики:

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

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

Системы, которые генерируют несколько заголовков Warning, ДОЛЖНЫ упорядочивать их с помощью это поведение пользовательского агента в виду.

Требования к поведению кэшей по отношению к Предупреждениям указано в разделе 13.1.2.

Это список определенных в настоящее время кодов предупреждений, каждый из которых имеет рекомендуемый предупреждающий текст на английском языке и описание его значения.

110 Ответ устарел ДОЛЖЕН быть включен всякий раз, когда возвращаемый ответ устарел.

111 Повторная проверка не удалась ДОЛЖЕН быть включен, если кеш возвращает устаревший ответ из-за попытка перепроверить ответ не удалась из-за невозможности добраться до сервера.

112 Отключенная операция ДОЛЖЕН быть включен, если кеш намеренно отключен от остальной части сети в течение определенного периода времени.

113 Эвристическое истечение ДОЛЖЕН быть включен, если кеш эвристически выбрал свежесть время жизни больше 24 часов и возраст ответа больше чем 24 часа.

199 Разное предупреждение Текст предупреждения МОЖЕТ включать произвольную информацию, которая должна быть представлена пользователю-человеку или зарегистрированному. Система, получившая это предупреждение, ДОЛЖНА НЕ предпринимайте никаких автоматических действий, кроме выдачи предупреждения Пользователь.

214 Преобразование применено ДОЛЖЕН быть добавлен промежуточным кешем или прокси, если он применяется преобразование, изменяющее кодировку содержимого (как указано в заголовок Content-Encoding) или тип носителя (как указано в заголовок Content-Type) ответа или тело объекта ответ, если этот код предупреждения уже не появляется в ответе.

299 Разное постоянное предупреждение Текст предупреждения МОЖЕТ включать произвольную информацию, которая должна быть представлена пользователю-человеку или зарегистрированному. Система, получившая это предупреждение, ДОЛЖНА НЕ предпринимайте никаких автоматических действий.

Если реализация отправляет сообщение с одним или несколькими заголовками Warning чья версия HTTP/1.0 или ниже, то отправитель ДОЛЖЕН включить в каждое значение предупреждения — дата предупреждения, совпадающая с датой в ответе.

Если реализация получает сообщение со значением предупреждения, которое включает дату предупреждения, и эта дата предупреждения отличается от даты значение в ответе, то это значение предупреждения ДОЛЖНО быть удалено из сообщение перед его сохранением, пересылкой или использованием. (Это предотвращает плохие последствия наивного кэширования полей заголовка Warning.) Если все из значений предупреждения удаляются по этой причине, заголовок Предупреждение ДОЛЖНЫ быть также удалены.

14.47 WWW-Аутентификация

Поле заголовка ответа WWW-Authenticate ДОЛЖНО быть включено в 401 (Неавторизованные) ответные сообщения. Значение поля состоит из at по крайней мере один вызов, который указывает схему(ы) аутентификации и параметры, применимые к Request-URI.

 WWW-аутентификация = "WWW-аутентификация" ":" 1#вызов
 

Процесс аутентификации доступа HTTP описан в разделе «HTTP Аутентификация: базовая и дайджест-аутентификация доступа» [43]. Пользователь Агентам рекомендуется проявлять особую осторожность при разборе WWW- Аутентифицируйте значение поля, так как оно может содержать более одного запроса, или если предоставлено более одного поля заголовка WWW-Authenticate, содержание самого вызова может содержать список разделенных запятыми параметры аутентификации.

Авторизация с помощью ACL | Сплошная документация

Apache Kafka® поставляется с подключаемым готовым авторизатором реализация, использующая Apache ZooKeeper™ для хранения всех ACL. Важно настроить ACL потому что в противном случае доступ к ресурсам ограничен суперпользователями, когда Авторизатор настроен. Поведение по умолчанию таково, что если ресурс не имеет связанных ACL, тогда доступ к ресурсу никому не разрешен, кроме суперпользователей.

Вы можете узнать больше об авторизации с помощью ACL в модуле авторизации бесплатного курса Apache Kafka Security.

См. также

Пример, демонстрирующий это в действии, см. в демоверсии Confluent Platform. Обратитесь к демонстрационному файлу docker-compose.yml для справки по конфигурации.

Концепции ACL

Списки управления доступом (ACL) обеспечивают важные элементы управления авторизацией для данные корпоративного кластера Apache Kafka®. Прежде чем пытаться создавать и использовать ACL, ознакомиться с понятиями, описанными в этом разделе; ваш их понимание является ключом к вашему успеху при создании и использовании ACL для управлять доступом к компонентам и данным кластера.

Авторизатор

Авторизатор — это подключаемый модуль сервера, используемый Apache Kafka® для авторизации операций. Более в частности, авторизатор контролирует, разрешать ли операцию или нет на основе принципала и ресурса, к которому осуществляется доступ. Кафка по умолчанию реализация авторизатора — AclAuthorizer ( kafka.security.authorizer.AclAuthorizer ), который был представлен в Apache Kafka® 2.4/Confluent Platform 5.4.0. До этого авторизационный был назван SimpleAclAuthorizer ( kafka. security.auth.SimpleAclAuthorizer ).

Чтобы включить и использовать AclAuthorizer, установите его полное имя класса для вашего брокера конфигурация в server.properties :

 authorizer.class.name=kafka.security.authorizer.AclAuthorizer
 

Примечание

Хотя в этом разделе рассматривается только AclAuthorizer, имейте в виду, что Confluent также предоставляет авторизатор Configuring Confluent Server, позволяющий использовать проприетарные Управление доступом на основе групп и ролей LDAP (RBAC), а также централизованные ACL. По умолчанию, Confluent Server Authorizer поддерживает списки управления доступом на основе ZooKeeper.

AclAuthorizer хранит информацию ACL Kafka в ZooKeeper. Однако это не контролировать доступ к узлам ZooKeeper. Скорее, ZooKeeper имеет собственную безопасность ACL для управления доступ к узлам ZooKeeper. ACL ZooKeeper контролируют, какой принципал (например, брокер принципал) может обновлять узлы ZooKeeper, содержащие метаданные кластера Kafka (например, синхронизированные реплики, конфигурация темы и списки управления доступом Kafka) и узлы, используемые в Interbroker. координация (например, выбор контроллера, присоединение к брокеру и удаление темы).

ACL Kafka определяют, какие участники могут выполнять операции с ресурсами Kafka. Брокеры Kafka могут использовать списки управления доступом ZooKeeper, включив ZooKeeper Security. ( zookeeper.set.acl=true ) для конфигурации брокера.

Принципал

Принципал — это объект, который может быть аутентифицирован авторизирующим лицом. Клиенты брокер Kafka идентифицирует себя как конкретного принципала, используя различные средства безопасности. протоколы. Способ идентификации принципала зависит от того, какой протокол безопасности он используется для подключения к брокеру Kafka (например: mTLS, SASL/GSSAPI или SASL/PLAIN). Аутентификация зависит от используемого протокола безопасности (например, SASL, TLS/SSL). распознавать принципала в брокере Kafka.

В следующих примерах показан формат основного имени на основе используемый протокол:

• Когда клиент подключается к брокеру Kafka с использованием протокола безопасности SSL, основное имя будет в форме имени субъекта SSL-сертификата: CN=quickstart. confluent.io,OU=TEST,O=Sales,L=PaloAlto,ST=Ca,C=US . Обратите внимание, что после запятой между подлежащими нет пробелов.
• Когда клиент подключается к брокеру Kafka, используя протокол безопасности SASL с GSSAPI. (Kerberos), субъект будет иметь формат принципала Kerberos: [email protected] . Для более подробной информации см. Основные имена Kerberos.
• Когда клиент подключается к брокеру Kafka, используя протокол безопасности SASL с механизм PLAIN или SCRAM, принципалом будет простая текстовая строка, например alice , admin или billing_etl_job_03 .

AclAuthorizer поддерживает только отдельных пользователей и всегда интерпретирует основной как имя пользователя. Однако другие авторизаторы поддерживают группы. Следовательно, при указании принципала вы должны указать тип, используя префикс Пользователь: или Группа: (с учетом регистра). Некоторые примеры: Пользователь: admin , Группа: разработчики или Пользователь: CN=quickstart. confluent.io,OU=TEST,O=Sales,L=PaloAlto,ST=Ca,C=US .

В следующем ACL, простые текстовые принципы ( User:alice , User:fred ) идентифицируются как пользователи Kafka, которым разрешено выполнять определенные операции (читать, запись) с любого из указанных хостов (хост-1, хост-2) на указанный ресурс (тема):

 kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
 --add --allow-principal Пользователь: Алиса --allow-principal Пользователь: fred --allow-host host-1 \
 --allow-host host-2 --операция чтения --операция записи --topic финансовая тема
 

Рекомендуется создать одного принципала для каждого приложения и дать каждому принципал только те списки управления доступом, которые ему требуются, и не более того. Например: если Алиса пишет три программы, которые обращаются к разным темам для автоматизации рабочего процесса выставления счетов, она может создать три принципала: billing_etl_job_01 , billing_etl_job_02 , и billing_etl_job_03 . Затем она предоставила бы каждому основному разрешение на только те темы, которые ей нужны, и запускать каждую программу с ее конкретным принципалом.

В качестве альтернативы она могла бы выбрать золотую середину и создать единую billing_etl_jobs принципал с доступом ко всем темам, которые программы требуют, и просто запустите все три с этим принципалом.

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

Подстановочные знаки участников

Вы можете создать списки ACL для всех участников, используя подстановочный знак в основном Пользователь:* . ACL, использующие подстановочный знак в качестве участника-пользователя, применяются ко всем пользователям. За например, следующая команда предоставляет всем доступ к теме testTopic :

 kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs. conf --add \
--allow-principal Пользователь:* --operation Все --topic testTopic
 

Если вы используете авторизатор, поддерживающий групповые принципы, например Confluent Server Authorizer, вы можете также создайте ACL для всех участников группы, используя принципала Группа:* . ACL, использующие подстановочный знак в качестве принципала, применяются ко всем пользователям, принадлежащим хотя бы в одну группу.

Вы не можете создавать ACL, использующие подстановочные знаки для суперпользователей. Например, пока следующая конфигурация делает пользователя основным User:* суперпользователем, это не делает каждого пользователя суперпользователем, потому что не выполняется сопоставление с подстановочными знаками:

 super.users=User:*
 

Примечание

Если вы используете Confluent Server Authorizer, обратите внимание, что привязки ролей не поддерживают сопоставление с подстановочными знаками. Следовательно, назначение роли Пользователь:* не предоставляет роль каждому пользователю. Ссылаться к авторизации с использованием управления доступом на основе ролей для получения дополнительных сведений о принципалах RBAC.

Субъекты SASL/Kerberos

Если вы используете Kerberos, ваш субъект Kafka основан на субъекте Kerberos (для например, kafka/[email protected] ). По умолчанию Kafka использует только основное имя принципала Kerberos, то есть имя, которое появляется перед косая черта ( / ). Следовательно, если принципал Kerberos брокера kafka/broker1.example.com@EXAMPLE , затем принципал, используемый Kafka авторизатор kafka . Имя хоста отличается для каждого брокера. Этот разбор автоматически реализуется с использованием значения по умолчанию sasl.kerberos.principal.to.local.rules .

Подробнее об основных именах и конфигурациях Kerberos см. Принципы Kerberos.

Примечание

Если вы используете сервер Kerberos или Active Directory вашей организации, запросите ваш администратор Kerberos для принципала для каждого брокера Kafka в вашем кластере и для каждого пользователя операционной системы, который будет получать доступ к Kafka с помощью Kerberos. аутентификация (с использованием клиентов и инструментов). Субъекты сервера имеют тип NT_HOSTBASED_SERVICE.

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

Параметры конфигурации для настройки имени пользователя SASL/Kerberos

По умолчанию субъект Kafka будет основной частью субъекта Kerberos. Вы можете изменить это поведение, указав настраиваемое правило для sasl.kerberos.principal.to.local.rules в server.properties . Формат из sasl.kerberos.principal.to.local.rules принимает форму списка, где каждый правило работает так же, как и в auth_to_local в Файл конфигурации Kerberos (krb5.conf). Эти правила поддерживают использование строчных/верхних регистров для принудительного перевода результат должен быть весь в нижнем регистре (/L ) или весь в верхнем регистре (/U ). Это правоприменение достигается добавив /L или /U в конец правила. Каждое правило начинается с ПРАВИЛО: и содержит выражение. В следующих примерах показан формат и синтаксис:

 ПРАВИЛО:[n:строка](regexp)s/шаблон/замена/
ПРАВИЛО:[n:строка](regexp)s/шаблон/замена/g
ПРАВИЛО:[n:string](regexp)s/шаблон/замена//L
ПРАВИЛО:[n:string](regexp)s/шаблон/замена/g/L
ПРАВИЛО:[n:string](regexp)s/шаблон/замена//U
ПРАВИЛО:[n:строка](regexp)s/шаблон/замена/g/U
 

Это правило преобразует [email protected] в user , сохраняя значение по умолчанию. правило на месте:

 sasl.kerberos.principal.to.local.rules=ПРАВИЛО:[1:$1@$0](.*@MYDOMAIN.COM)s/@.*//,ПО УМОЛЧАНИЮ
 

Имена основных пользователей TLS/SSL

Как упоминалось ранее, принципалы распознаются на основе того, как пользователи аутентифицируются в брокер, который, в свою очередь, зависит от используемого протокола безопасности. Использовать принципалов TLS/SSL, вы должны понимать, как точно представлять имена пользователей.

По умолчанию имя принципала, идентифицируемое сертификатом TLS/SSL. является DN (отличительное имя X.500) этого сертификата (также известного как Субъект), в котором используется форма CN=writeuser,OU=неизвестно,O=неизвестно,L=неизвестно,ST=неизвестно,C=неизвестно . Вы можете использовать ssl.principal.mapping.rules , чтобы преобразовать DN в более управляемый основное имя. Дополнительные сведения см. в разделе Параметры конфигурации для настройки имени пользователя TLS/SSL.

В случае, если SSL включен, но проверка подлинности клиента не настроена, клиенты будут подключаться анонимно, используя порт SSL, и будут отображаться в сервер с именем пользователя ANONYMOUS. Такая конфигурация обеспечивает шифрование и аутентификация сервера, но клиенты подключаются анонимно. Другой случай в котором сервер увидит АНОНИМНОГО пользователя, если безопасность PLAINTEXT протокол используется. Предоставляя разрешение на чтение/запись АНОНИМНОМУ пользователю, вы позволяете любому получить доступ к брокерам без аутентификации. Как таковой, вы не должны предоставлять доступ АНОНИМНЫМ пользователям, если намерение это дать всем разрешение.

Параметры конфигурации для настройки имени пользователя TLS/SSL

По умолчанию имя пользователя SSL имеет форму CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown . Эта конфигурация позволяет составить список правил для сопоставления выделенных X.500 имя (DN) на короткое имя. Правила оцениваются по порядку, и первое правило, которое соответствует DN, используется для сопоставления его с коротким именем. Любые последующие правила в списке игнорируются.

Формат ssl.principal.mapping.rules — это список, где начинается каждое правило с «RULE:» и содержит выражение с использованием следующих форматов. Правило по умолчанию возвращает строковое представление DN сертификата X.500. Если DN совпадает с шаблон, то по имени выполняется команда замены. Это также поддерживает параметры нижнего/верхнего регистра, чтобы переводить результат в нижнем/верхнем регистре кейс. Это делается путем добавления /L или /U в конец правила:

 ПРАВИЛО:шаблон/замена/
ПРАВИЛО:шаблон/замена/[LU]
 9.*[Cc][Nn]=([a-zA-Z0-9.]*).*$/$1/л,
ДЕФОЛТ
 

Эти правила преобразуют DN следующим образом: CN=serviceuser,OU=ServiceUsers,O=неизвестно,L=неизвестно,ST=неизвестно,C=неизвестно до serviceuser и CN=adminUser,OU=Admin,O=неизвестно,L=неизвестно,ST=неизвестно,C=неизвестно на adminuser@admin .

Операции

Операция — это действие, выполняемое над ресурсом. В помимо определения ресурсов, к которым пользователи или группы имеют доступ, ACL-списки также определяют операции, которые разрешено выполнять этим пользователям или группам. выполнять. Для каждого ресурса операция сопоставляется с одним или несколькими API Kafka или типы запросов, применимые к этому ресурсу. Например, операция READ для Ресурс темы сопоставляется с Fetch, OffsetCommit и TxnOffsetCommit. Или НАПИСАТЬ операция для ресурса Topic сопоставляется с Produce и AddPartitionsToTxn.

В следующих таблицах указаны допустимые операции, доступные для каждого ресурса. введите Confluent Platform и опишите взаимосвязь между операциями, ресурсами и API:

Операции, доступные для типа ресурса кластера:

Операция	Ресурс	Разрешенные API
Изменить	Кластер	Альтеррепликалогдирс, CreateAcls, УдалитьAcls
АльтерКонфигс	Кластер	АльтерКонфигс
КластерЭкшен	Кластер	Fetch (только для репликации), ЛидерАндИср, смещение для лидера эпохи, стопреплика, Обновить метаданные, Контролируемое выключение, WriteTxnMarkers
Создать	Кластер	CreateTopics, Метаданные
Описать	Кластер	ОписатьAcls, ОписатьLogDirs, Группы списков
Описать конфигурации	Кластер	Описания конфигурации

Операции, доступные для типа ресурса «Тема»:

Операция	Ресурс	Разрешенные API
Изменить	Тема	Создатьразделы
АльтерКонфигс	Тема	АльтерКонфигс
Создать	Тема	CreateTopics, Метаданные
Удалить	Тема	Удалить записи, Удалить Темы
Описать	Тема	Листоффсетс, Метаданные, смещение, OffsetForLeaderEpoch
Описать конфигурации	Тема	Описания конфигурации
Чтение	Тема	Принести, коммит смещения, TxnOffsetCommit
Запись	Тема	Продукция, Аддпартитионстотексн

Операции, доступные для типа ресурса Группа:

Операция	Ресурс	Разрешенные API
Удалить	Группа	УдалитьГруппы
Описать	Группа	Группа описания, Найтикоординатор, Группы списков
Чтение	Группа	Аддоффсетстотексн, Стук сердца, Вступить в группу, Покинуть группу, коммит смещения, смещение, группа синхронизации, Тксноффсеткоммит

Операции, доступные для типа ресурса токена делегирования:

Операция	Ресурс	API разрешено
Описать	Токен делегирования	Жетоны описания

Операции, доступные для типа ресурса Transactional ID:

Операция	Ресурс	Разрешенные API
Описать	идентификатор транзакции	Найтикоординатор
Запись	идентификатор транзакции	Продукция, аддпартитионстотексн, аддоффсетстотексн, EndTxn, InitProducerId, Тксноффсеткоммит

Операции в приведенных выше таблицах предназначены для клиентов (производителей, потребителей, admin) и межброкерские операции кластера. В защищенном кластере оба клиента запросы и межброкерские операции требуют авторизации. Интерброкер операции делятся на два класса: кластер и тема. Кластерные операции относятся к операциям, необходимым для управления кластером, таким как обновление метаданные брокера и раздела, изменение лидера и набора синхронизированных реплик раздела и запуск управляемого отключения.

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

Производители и потребители должны быть авторизованы для выполнения операций по темам, но они должны быть настроены с другими принципами по сравнению с брокерами. Основными операциями, для выполнения которых производителям требуется авторизация, являются ЗАПИСЬ. и читать. Пользователи с правами администратора могут запускать инструменты командной строки и требовать авторизации. Операции, для которых администратору может потребоваться авторизация: DELETE, CREATE, и ИЗМЕНИТЬ. Вы можете использовать подстановочные знаки ( *) для производителей и потребителей, чтобы вы только нужно установить его один раз.

Неявно производные операции

Некоторые операции предоставляют пользователям дополнительный доступ к неявным операциям.

При разрешении READ, WRITE или DELETE пользователи неявно получают операцию DESCRIBE.

При предоставлении ALTER_CONFIGS пользователи неявно получают операцию DESCRIBE_CONFIGS.

Приоритет ACL

В контекстах, где у вас есть как разрешающие, так и запрещающие списки ACL, запретные ACL имеют приоритет сверх разрешенных списков контроля доступа.

Ресурсы

Пользователи получают доступ и выполняют операции с определенными ресурсами Kafka и Confluent Platform. А ресурс может быть кластером, группой, темой Apache Kafka®, идентификатором транзакции или делегированием. токен. ACL определяют, какие пользователи могут получить доступ к указанному ресурсу, а операции, которые им разрешено выполнять с этим ресурсом. В ресурсах Кафки являются:

Кластер

Кластер Kafka. Пользователи, которые хотят выполнять операции, влияющие на все кластер, например контролируемое отключение или создание новой темы, должен быть назначен привилегии на ресурсе кластера.

Токен делегирования

Токены делегирования — это общие секреты между брокерами Apache Kafka® и клиентами. Аутентификация на основе токенов делегирования — это упрощенная аутентификация. механизм, который можно использовать для дополнения существующих методов SASL/SSL. Ссылаться на Аутентификация с использованием токенов делегирования для получения более подробной информации.

Группа

Группы у брокеров. Все протокольные вызовы, которые работают с группами, такие как присоединяясь к группе, должны иметь соответствующие привилегии с группой в предмет. Группа ( group.id ) может означать группу потребителей, группу потоков ( application.id ), Connect Worker Group или любая другая группа, использующая Протокол Consumer Group, такой как кластер Schema Registry.

Тема

Все сообщения Kafka организованы в темы (и разделы). Чтобы получить доступ к теме, у вас должна быть соответствующая операция (такая как READ или WRITE), определенная в ACL.

Идентификатор транзакции

Идентификатор транзакции ( transactional.id ) идентифицирует одного производителя экземпляр при перезапуске приложения и обеспечивает способ обеспечения единой писатель; это необходимо для семантики ровно один раз (EOS). Может быть только один производитель активен в любое время для каждых идентификатор транзакции . Когда продюсер запускается, он сначала проверяет, есть ли ожидающая транзакция производитель со своим собственным transactional.id . Если есть, то надо подождать пока транзакция не завершится (прервите или зафиксируйте). Это гарантирует, что производитель всегда начинает с непротиворечивого состояния.

При использовании производитель должен иметь возможность манипулировать идентификаторами транзакций и иметь все набор разрешений. Например, следующий ACL разрешает всем пользователям в системе доступ к продюсеру EOS:

 kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
   --add --transactional-id * --allow-principal Пользователь:* --operation write
 

В тех случаях, когда вам нужно создать ACL для кластера Kafka, чтобы разрешить Обработка потоков ровно один раз (EOS):

 # Разрешить потоки EOS:
 bin/kafka-acls ... --add --allow-principal Пользователь: team1 --operation WRITE \
   --operation DESCRIBE --transactional-id team1-streams-app1 \
   --resource-pattern-type с префиксом
 

Дополнительные сведения о роли идентификаторов транзакций см. Транзакции в Apache Kafka.

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

Вы можете просмотреть списки ACL для определенного ресурса, используя --список опций . За Например, чтобы просмотреть все ACL для темы test-topic , выполните следующую команду: команда:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
   --list --topic тестовая тема
 

ACL с префиксом

Вы можете указать ресурсы ACL, используя значение LITERAL (по умолчанию), PREFIXED тип шаблона или подстановочный знак ( * ), который разрешает все.

Если вы идентифицируете ресурс, используя LITERAL, Kafka попытается сопоставить полный имя ресурса (например, тема или группа потребителей) с ресурсом, указанным в ACL. В некоторых случаях вы можете использовать звездочку ( * ) указать все Ресурсы.

Если вы идентифицируете ресурс с помощью PREFIXED, Kafka попытается сопоставить префикс имени ресурса с ресурсом, указанным в ACL.

Например, вы можете добавить ACL для пользователя User:kafka/kafka1. [email protected] для создания любой темы с именем, использующим префикс Test-. Ты можешь сделать для этого выполните следующую команду:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
   --add --allow-principal Пользователь: kafka/[email protected] \
   --producer --topic Test- --resource-pattern-type с префиксом
 

В следующем примере программа BillingPublisher, созданная при использовании Kafka Java SDK требуется ACL, позволяющий записывать только темы, использующие префикс billing- :

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
--allow-principal Пользователь:BillingPublisher \
--allow-host 198.51.100.0 --producer --topic billing- --resource-pattern-type с префиксом
 

Имейте в виду, что вы не можете использовать тип шаблона ресурса PREFIXED для раздела при предоставлении доступ ко всем группам * (шаблон) в одной команде. Вместо этого разделите разрешения для разных команд. Например, предоставить доступ READ и DESCRIBE. пользователю для тем с префиксом:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
--allow-principal Пользователь:имя пользователя --operation Read --operation Describe --topic префикс темы --resource-pattern-type с префиксом
 

Затем предоставьте пользователю доступ READ ко всем группам:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --добавить \
--allow-principal Пользователь: имя пользователя --operation Read --group '*'
 

Привилегированные пользователи

По умолчанию, если ресурс не имеет связанных ACL, никто не может получить доступ к этому ресурсу, кроме суперпользователей. Если вы хотите изменить это поведение, вы можете включить следующее в server.properties: allow.everyone.if.no.acl.found=true .

Примечание

Использование параметра конфигурации allow. everyone.if.no.acl.found в рабочей среде среды категорически не рекомендуется.

• Если вы укажете этот параметр, исходя из предположения, что у вас есть ACL, но затем ваш последний ACL удаляется, вы, по сути, открываете свои кластеры Kafka для всех пользователей.
• Если вы используете этот параметр для отключения ACL, соблюдайте осторожность: если кто-то добавит ACL, все пользователи, которые ранее имели доступ, потеряют этот доступ.

Вы можете добавить суперпользователей в server.properties (примечание что разделителем является точка с запятой, потому что имена пользователей SSL могут содержать запятую) как показано здесь:

 super.users=Пользователь:Боб;Пользователь:Алиса
 

ACL и перехватчики мониторинга

Перехватчики Confluent Monitoring производить в тему _confluent-monitoring по умолчанию. Вы можете настроить Тема _confluent-monitoring с использованием темы confluent. monitoring.interceptor.topic атрибут. Приложение или программный доступ к _confluent-monitoring Тема должна иметь права на запись и описание. Если _confluent-monitoring тема не существует, то вы должны иметь доступ CREATE и DESCRIBE на уровне кластера к создать это. Вы также должны иметь права доступа CREATE, DESCRIBE, READ и WRITE на уровне тем. _confluent-monitoring .

Вы можете предоставить доступ либо индивидуально для каждого принципала клиента, который будет использовать перехватчики или использование записи с подстановочными знаками для всех клиентов. Следующий пример показывает список управления доступом, который предоставляет основному доступ к теме _confluent-monitoring :

 kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
--add --topic _confluent-monitoring --allow-principal Пользователь:имя пользователя --операция запись --операция Описать
 

Субъекту Confluent Control Center требуется доступ READ, DESCRIBE и CREATE к _confluent-monitoring тема. Используйте сценарий control-center-set-acls , чтобы установить соответствующий разрешения для участника Confluent Control Center на доступ к этому разделу. См. Настройка базовой HTTP-аутентификации с помощью Центра управления. для деталей.

Использование ACL

В примерах в следующих разделах используется bin/kafka-acls (CLI управления авторизацией Kafka) для добавления, удаления или перечисления ACL. Для получения подробной информации о поддерживаемых параметрах запустите bin/kafka-acls --help . Обратите внимание, что списки управления доступом хранятся в ZooKeeper и распространяется на брокеры асинхронно, поэтому может быть задержка перед изменение вступает в силу даже после возврата команды.

Вы также можете использовать Kafka AdminClient API для управления ACL.

Некоторые из наиболее распространенных вариантов использования ACL:

• создать тему, принципалу клиента потребуются операции CREATE и DESCRIBE для ресурса Topic или Cluster .
• производят в теме, принципалу производителя потребуется операция WRITE для ресурса темы .
• потребляют из темы, принципалу потребителя потребуется операция ЧТЕНИЕ на Тема и Ресурсы группы .

Обратите внимание: чтобы иметь возможность создавать, производить и потреблять, серверы должны быть настроены с помощью соответствующих ACL. Серверам требуется авторизация для обновления метаданные (CLUSTER_ACTION) и чтение из темы (READ) для целей репликации.

ACL на основе ZooKeeper не поддерживают использование слитные команды iam acl, которые используются только с централизованными ACL.

Формат ACL

ACL Kafka определяются в общем формате «Principal P is [Allowed/Denied] Операция O с хоста H на ресурсах, соответствующих ResourcePattern RP».

• Подстановочные знаки применяются к любому ресурсу.

• Вы можете предоставить доступ к темам и группам с подстановочными знаками пользователям, у которых есть разрешение на доступ ко всем темам и группам (например, пользователи-администраторы). Если вы используете этот метод, вам не нужно создавать отдельное правило для каждой темы и группы для пользователя. Например, вы можете использовать эту команду, чтобы предоставить Алисе доступ с подстановочными знаками:

  .

   kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add --allow-principal \
  Пользователь:Алиса --operation All --topic '*' --group '*'
   

Использование файла свойств конфигурации

Если вы использовали API производителя, API потребителя или Streams API с Kafka раньше, то вы можете знать, что сведения о подключении к кластеру указывается с помощью свойств конфигурации. Хотя некоторые пользователи могут распознать это для приложений, разработанных для взаимодействия с Kafka, другие могут не знать, что инструменты администрирования, поставляемые с Kafka, работают одинаково, а это значит, что после того, как вы определили свойства конфигурации (часто в форме файл config.properties ), либо приложения, либо инструменты смогут подключаться к кластерам.

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

Аргумент --command-config предоставляет инструментам Confluent CLI свойства конфигурации, необходимые для подключения к кластеру Kafka, в .properties формат файла. Обычно это включает security.protocol которую кластер использует для подключения, и любую информацию, необходимую для аутентификации. к кластеру. Например:

 security.protocol=SASL_PLAINTEXT
sasl.mechanism=ОБЫЧНЫЙ
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule требуется \
  имя пользователя = "Алиса" \
  пароль = "s3cr3t";
 

Добавление ACL

Предположим, вы хотите добавить ACL, где: принципалы Пользователь: CN=Jane Smith,OU=Sales,O=Неизвестно,L=Неизвестно,ST=Неизвестно,C=Неизвестно и User:CN=Bob Thomas,OU=Sales,O=Unknown,L=Unknown,ST=NY,C=Unknown разрешены выполнять операции чтения и записи по теме test-topic с IP 198. 51.100.0 и IP 198.51.100.1. Вы можете сделать это, выполнив следующее:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
 --allow-principal "Пользователь:CN=Боб Томас,OU=Продажи,O=Неизвестно,L=Неизвестно,ST=Нью-Йорк,C=Неизвестно" \
 --allow-principal "Пользователь:CN=Джейн Смит,OU=Продажи,O=Неизвестно,L=Неизвестно,ST=Неизвестно,C=Неизвестно" \
 --allow-хост 198.51.100.0 --allow-хост 198.51.100.1 \
 --operation Чтение --operation Запись --topic тестовая тема
 

По умолчанию все участники, у которых нет явного ACL, разрешающего операцию доступ к ресурсу запрещен. В редких случаях, когда ACL, разрешающий доступ для всех, кроме некоторых принципалов, вы можете использовать --deny-principal и --deny-host опций. Например, используйте следующую команду, чтобы разрешить все пользователей читать из тестовой темы , но запрещать только Пользователь: kafka/kafka6.host-1.com@bigdata. com от IP 198.51.100.3:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
 --allow-principal Пользователь: '*' --allow-host '*' --deny-principal Пользователь: kafka/[email protected] --deny-host 198.51.100.3 \
 --operation Чтение --topic тестовая тема
 

Kafka не поддерживает списки отзыва сертификатов (CRL), поэтому отзывать нельзя сертификат клиента. Следовательно, единственной альтернативой является отключение пользовательского доступ с помощью ACL:

 kafka-acls --bootstrap-server localhost:9092 --add --deny-principal "User:CN=Bob,O=Sales" --cluster --topic '*'
 

Обратите внимание, что --allow-host и deny-host поддерживают только IP-адреса (имена хостов). не поддерживаются). Также обратите внимание, что адреса IPv6 поддерживаются и что вы может использовать их в ACL.

В приведенных выше примерах списки управления доступом добавляются в тему путем указания --topic [имя-темы] как вариант шаблона ресурсов. Точно так же можно добавить ACL в кластер, указание --cluster и в группу, указав --group [имя-группы] . Если вы хотите предоставить разрешение всем группам, вы можете сделать это, указав --group='*' , как показано в следующей команде:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add \
--allow-principal User: '*' --operation read --topic test --group '*'
 

Вы можете добавить ACL к шаблонам ресурсов с префиксом. Например, вы можете добавить ACL что позволяет пользователям в организационном подразделении (OU) ServiceUsers (эта организация использует TLS/SSL аутентификация) для создания любой темы, имя которой начинается с Test-. Ты это можно сделать, выполнив CLI со следующими параметрами:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --add --allow-principal \
  Пользователь: CN = serviceuser, OU = ServiceUsers, O = Unknown, L = Unknown, ST = Unknown, C = Unknown --producer --topic Test- --resource-pattern-type с префиксом
 

Обратите внимание, что --resource-pattern-type по умолчанию литерал , который только влияет на ресурсы с точно таким же именем или, в случае подстановочного знака имя ресурса '*' , ресурс с любым именем.

Caution

Параметр --link-id для kafka-acls , доступный, начиная с Confluent Platform 7.1.0, является экспериментальным и не должен использоваться в производственных развертываниях. В частности, не используйте link-ID для создания ACL. Если в исходном кластере создается ACL с --link-id , он помечается для управления по идентификатору ссылки, и не будет синхронизироваться с пунктом назначения, независимо от acl.sync.filters . В настоящее время Confluent Platform не обеспечивает проверку существования в кластере. идентификаторов ссылок, созданных с помощью kafka-acls . Дополнительные сведения см. в разделе «Миграция списков ACL из исходного в целевой кластер».

Удаление ACL

Удаление ACL аналогично их добавлению, за исключением того, что параметр --remove должен быть указано вместо --добавить . Чтобы удалить списки ACL, добавленные в первом примере выше вы можете выполнить следующее:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs. conf --remove \
 --allow-principal "Пользователь:CN=Боб Томас,OU=Продажи,O=Неизвестно,L=Неизвестно,ST=Нью-Йорк,C=Неизвестно" \
 --allow-principal "Пользователь:CN=Джейн Смит,OU=Продажи,O=Неизвестно,L=Неизвестно,ST=Неизвестно,C=Неизвестно" \
 --allow-host 198.51.100.0 --allow-host 198.51.100.1 \
 --operation Чтение --operation Запись --topic тестовая тема
 

Если вы хотите удалить ACL, добавленный к шаблону ресурса с префиксом в Например, запустите CLI со следующими параметрами:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --remove \
  --allow-principal Пользователь:CN=Джейн Смит,OU=Продажи,O=Неизвестно,L=Неизвестно,ST=Неизвестно,C=Неизвестно \
  --producer --topic Test- --resource-pattern-type С префиксом
 

Список ACL

Вы можете просмотреть список ACL для данного ресурса, указав параметр --list и ресурс. Например, чтобы получить список всех ACL для тестовой темы , выполните команду следующий:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs. conf \
 --list --topic тестовая тема
 

Однако будут возвращены только те списки ACL, которые были добавлены именно к этому шаблон ресурса. Могут существовать и другие ACL, влияющие на доступ к теме, например, любой ACL для шаблона темы '*' или любые ACL для шаблонов ресурсов с префиксом. Вы можете явно запросить ACL по шаблону ресурсов с подстановочными знаками:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --list --topic '*'
 

Не всегда возможно явно запрашивать списки ACL для ресурса с префиксом шаблоны, соответствующие тестовой теме , потому что имя таких шаблонов может быть неизвестно. Вы можете перечислить все ACL, влияющие на Test-topic , используя --соответствие типа-шаблона ресурса . Например:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --list --topic Test-topic --resource-pattern-type match
 

Эта команда выведет список ACL для всех соответствующих литералов, ресурсов с подстановочными знаками и ресурсов с префиксом. узоры.

Чтобы просмотреть ACL для внутренней темы:

 kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf --list --topic __consumer_offsets
 

Добавление или удаление участника в качестве производителя или потребителя

Наиболее распространенными вариантами использования для управления ACL являются добавление/удаление производитель или потребитель. Чтобы добавить пользователя «Jane Doe» (платформа Kerberos Пользователь:[email protected] ) как производителя тестовой темы , вы можете выполнить следующее:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
 --add --allow-principal Пользователь:[email protected] \
 --producer --topic тестовая тема
 

Чтобы добавить пользователя : [email protected] в качестве потребителя тестовой темы с группой Group-1 , вы можете укажите --consumer и --group варианты:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs. conf \
 --add --allow-principal Пользователь:[email protected] \
 --consumer --topic test-topic --group Группа-1
 

Чтобы удалить принципала из роли производителя или потребителя, вы можете указать --удалить опцию .

Включение авторизации для идемпотентных и транзакционных API

Производители могут быть настроены с помощью enable.idempotence=true , чтобы гарантировать, что ровно одна копия каждого сообщения записывается в поток. Принципал, используемый идемпотентные производители должны быть уполномочены выполнять Напишите на кластер.

Чтобы позволить Бобу создавать сообщения с использованием идемпотентного производителя, вы можете выполнить команда:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
 --add --allow-principal Пользователь: Боб \
 --producer --topic тестовая тема --write --idempotent
 

Производители также могут быть настроены с непустым transactional. id , чтобы включить транзакционная доставка с семантикой надежности, которая охватывает несколько производителей сессии. Принципал, используемый производителями транзакций, должен быть авторизован для Описать и Записать операций с настроенным transactional.id .

Чтобы Алиса могла создавать сообщения с помощью транзакционного производителя с transactional.id=test-txn , выполните команду:

 bin/kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
 --add --allow-principal Пользователь: Алиса \
 --producer --topic тестовая тема --transactional-id test-txn
 

Создание администраторов ACL без прав суперпользователя

Если вы хотите, чтобы пользователь без прав суперпользователя мог создавать или удалять ACL, но не предоставлять им роль суперпользователя, текущий суперпользователь может предоставить другому пользователь (называемый здесь администратором ACL) доступ ALTER --cluster контрольная запись (ACE), которая привязывает операцию, в данном случае «изменение», к ресурс, «кластер». После предоставления администратору ACL ALTER --cluster ACE, этот пользователь может создавать и удалять ACL для данного ресурса в кластере.

 kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
--add --allow-principal Пользователь: notSuper \
--operation ALTER --cluster
 

Примечание

• Если вы хотите назначить ALTER --cluster группе, то Group:groupName также допустимо; однако используемый вами авторизатор должен иметь возможность обрабатывать/разрешать группы.
• Соблюдайте осторожность при назначении ALTER --cluster пользователям или группам, поскольку такие пользователи смогут создавать и удалять списки ACL для управления собственным доступом к ресурсам.

Авторизация в реестре REST Proxy и Schema

Вы можете использовать ACL Kafka для обеспечения авторизации в REST Proxy и реестре схем. Эти требуется подключаемый модуль REST Proxy Security и Плагин безопасности реестра схемы.

Отладка

Можно работать с логами авторизатора в режиме DEBUG , сделав некоторые изменения в файле log4j.properties . Если вы используете значение по умолчанию файл log4j.properties , измените следующую строку на вместо режима DEBUG из ПРЕДУПРЕЖДЕНИЕ :

 log4j.logger.kafka.authorizer.logger=ПРЕДУПРЕЖДЕНИЕ, authorizerAppender
 

Файл log4j.properties находится в каталоге конфигурации Kafka по адресу /etc/kafka/log4j.properties . Если вы используете более раннюю версию Confluent Platform или если вы используете собственный файл log4j.properties , вы необходимо добавить в конфигурацию следующие строки:

 log4j.appender.authorizerAppender=org.apache.log4j.DailyRollingFileAppender
log4j.appender.authorizerAppender.DatePattern='.'гггг-ММ-дд-ЧЧ
log4j.appender.authorizerAppender.File=${kafka.logs.dir}/kafka-authorizer.log
log4j.appender. authorizerAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.authorizerAppender.layout.ConversionPattern=[%d] %p %m (%c)%n
log4j.logger.kafka.authorizer.logger=DEBUG, authorizerAppender
log4j.additivity.kafka.authorizer.logger=false
 

Вам необходимо перезапустить брокера, прежде чем он вступит в силу. Это будет регистрировать каждый авторизованный запрос и связанное с ним имя пользователя. Журнал находится в $kafka_logs_dir/kafka-authorizer.log . Расположение журналов зависит от формат упаковки — kafka_logs_dir будет в /var/log/kafka в rpm/debian и $base_dir/logs в формате архива.

Настройка HTML-файлов веб-аутентификации (необязательно)

Процесс веб-аутентификации отображает серию веб-страниц и сообщений о состоянии для пользователя во время входа в систему. Отображаемые веб-страницы могут быть следующими:

Создавая настраиваемые веб-страницы входа, вы можете улучшить «внешний вид» процесса веб-аутентификации, чтобы он больше соответствовал потребностям вашей сети и бизнеса. Например, вы можете:

• Определите сеть, в которую пытается войти клиент.

• Укажите контактную информацию, если у клиента возникают проблемы с подключением к сети.

• Включите стили CSS, соответствующие внешнему виду вашей сети.

Внедрение настраиваемых веб-страниц аутентификации

Чтобы внедрить расширенные веб-страницы аутентификации, вам необходимо:

• Настройте и запустите веб-сервер в вашей локальной сети.

• Настройте файлы шаблонов HTML и сделайте их доступными для веб-сервера.

• Настройте коммутатор для отображения настроенных файлов с помощью aaa port-access веб-команда ewa-server для указания IP-адреса сервера или имени хоста и пути к настроенным HTML-файлам на сервере.

Примечания и рекомендации по эксплуатации

• Настраиваемые страницы веб-аутентификации настраиваются для каждого коммутатора таким образом, чтобы каждый порт с поддержкой веб-аутентификации отображал одни и те же настраиваемые страницы при входе клиента.

• Создаваемые вами настраиваемые веб-страницы могут размещаться на трех веб-серверах в вашей сети. Внедрение нескольких веб-серверов обеспечивает избыточность в случае сбоя доступа к любому из других серверов.

• Чтобы настроить веб-сервер в вашей сети, следуйте инструкциям в документации, прилагаемой к серверу.

• Перед включением пользовательских страниц веб-аутентификации необходимо:

  • Определите IP-адрес или имя хоста веб-серверов, на которых будут размещаться ваши настраиваемые страницы.

  • Определите путь на сервере (серверах), где хранятся файлы HTML (включая всю графику), используемые для страниц входа.

  • Настройте и запустите веб-сервер(ы).

  • Создайте настроенные веб-страницы, как описано в разделе Настройка шаблонов HTML, и сохраните их в пути к документу на назначенных серверах.

  • Проверьте, доступны ли они по указанным URL-адресам.

Настройка шаблонов HTML

Следуйте этим рекомендациям при настройке шаблона HTML:

• Не изменяйте имя ни одного из HTML-файлов ( index.html , accept.html и т. д.).

• Некоторые страницы шаблонов используют встроенные переключатели (ESI) или страницы активного сервера. Их не следует изменять при настройке файлов HTML. ESI ведут себя следующим образом:

  1. Веб-браузер клиента отправляет запрос на файл HTML. Коммутатор передает запрос настроенному веб-серверу.

  2. В ответ веб-сервер отправляет коммутатору настроенную HTML-страницу. Каждый вызов ESI на HTML-странице заменяется значением (в виде простого текста), полученным в результате вызова.

  3. Коммутатор отправляет окончательную версию HTML-страницы в веб-браузер клиента.

• Сохраните все настраиваемые веб-страницы входа (включая любую графику), которые вы создаете для входа клиента на каждом веб-сервере, по пути, который вы настроите с помощью команды aaa port-access веб-сервера ewa-server .

Дополнительные сведения о доступных шаблонах страниц см. в разделе Настраиваемые HTML-шаблоны.

Настраиваемые шаблоны HTML

Чтобы помочь вам создать собственный набор файлов HTML, используйте шаблоны, которые можно найти на странице загрузки программного обеспечения RA.

Страница входа пользователя (index.html)

Страница входа пользователя

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

HTML-код для шаблона страницы входа пользователя

Страница разрешенного доступа (accept.html)

Страница разрешенного доступа

Файл accept.html — это веб-страница, используемая для подтверждения действительного входа клиента. Эта веб-страница отображается после ввода и принятия действительного имени пользователя и пароля.

Затем клиентскому устройству предоставляется доступ к сети. Чтобы настроить VLAN, используемую авторизованными клиентами, укажите идентификатор VLAN со значением 9.0004 aaa параметр команды auth-vid для доступа к порту при включении веб-аутентификации.

Файл accept.html содержит следующие ESI, которые не следует изменять:

• ESI GETWAUTHREDIRECTTIME вставляет значение времени ожидания, используемого коммутатором для перенаправления аутентифицированного клиента, пока клиент обновляет свой IP-адрес и получает доступ к сети.

• ESI GETWAUTHREDIRECTURL вставляет URL-адрес, настроенный с помощью redirect-url Параметр для перенаправления входа клиента или первой веб-страницы, запрошенной клиентом.

HTML-код для шаблона страницы «Доступ предоставлен»

Страница аутентификации (authen.

html)

Страница аутентификации

Файл authen.html — это веб-страница, используемая для обработки входа клиента, которая обновляется во время проверки учетных данных пользователя.

HTML-код для шаблона страницы аутентификации

Страница недействительных учетных данных (reject_unauthvlan.html)

Страница недействительных учетных данных

Файл reject_unauthvlan.html — это веб-страница, используемая для отображения ошибок входа, на которых неаутентифицированный клиент назначается неавторизованным клиентским сеансам в VLAN, настроенной для . Вы можете настроить VLAN, используемую неавторизованными клиентами, с помощью веб-команды aaa port-access unauth-vid при включении веб-аутентификации.

ESI GETWAUTHREDIRECTTIME вставляет значение времени ожидания, используемого коммутатором для перенаправления неаутентифицированного клиента, пока клиент обновляет свой IP-адрес и получает доступ к VLAN для неавторизованных клиентов. Этот ESI не следует изменять.

Код HTML для шаблона страницы с недействительными учетными данными

Код HTML для шаблона страницы с недействительными учетными данными

Страница таймаута (timeout.html)

Таймаут страницы

Файл timeout.html — это веб-страница, используемая для возврата сообщения об ошибке, если сервер RADIUS недоступен. Вы можете настроить период времени (в секундах), в течение которого коммутатор ожидает ответа от сервера RADIUS, используемого для проверки учетных данных клиента, с помощью команды aaa port-access web-server-timeout при включении веб-аутентификации.

HTML-код для шаблона страницы тайм-аута

Повторить попытку входа на страницу (retry_login.html)

Страница повторного входа

Файл retry_login.html — это веб-страница, отображаемая клиенту, который ввел недопустимое имя пользователя и/или пароль и получил еще одну возможность войти в систему.

GETWAUTHRETRIESLEFT ESI отображает количество попыток входа в систему, оставшихся для клиента, который ввел неверные учетные данные для входа. Вы можете настроить количество раз, которое клиент может ввести свое имя пользователя и пароль, прежде чем аутентификация завершится ошибкой, с помощью aaa порт-доступ через Интернет максимальное число повторных попыток команд при включении веб-аутентификации. Этот ESI не следует изменять.

HTML-код для шаблона страницы повторного входа

Страница перенаправления SSL (sslredirect.html)

Страница перенаправления SSL

Файл sslredirect — это веб-страница, отображаемая, когда клиент перенаправляется на сервер SSL для ввода учетных данных для веб-аутентификации. Если вы включили SSL на коммутаторе, вы можете включить безопасную веб-аутентификацию на основе SSL, введя aaa port-access веб-команда ssl-login при включении веб-аутентификации.

ESI GETWAUTHSSLSRV вставляет URL-адрес, который перенаправляет клиента на порт с поддержкой SSL на сервере для проверки имени пользователя и пароля клиента. Этот ESI не следует изменять.

HTML-код для шаблона страницы переадресации SSL

Доступ запрещен к странице (reject_novlan.html)

Доступ запрещен к странице

reject_novlan — это веб-страница, отображаемая после сбоя входа клиента в систему, когда VLAN не настроен для неавторизованных клиентов.

ESI GETWAUTHQUIETTIME вставляет период времени, используемый для блокировки неавторизованного клиента от повторной попытки входа в систему. Чтобы указать период времени, по истечении которого коммутатор сможет получить новый запрос на проверку подлинности, настройте значение для команды aaa port-access веб-команды тихого периода при включении веб-аутентификации. Этот ESI не следует изменять.

HTML-код для шаблона страницы «Отказано в доступе»

RFC 7235 — Протокол передачи гипертекста (HTTP/1.

1): аутентификация

 Инженерная рабочая группа Интернета (IETF) R. Fielding, Ed.
Запрос комментариев: 7235 Adobe
Устарело: 2616 J. Reschke, Ed.
Обновления: 2617 гринбайт
Категория: Трек стандартов, июнь 2014 г.
ISSN: 2070-1721
         Протокол передачи гипертекста (HTTP/1.1): аутентификация
Абстрактный
   Протокол передачи гипертекста (HTTP) — это приложение без сохранения состояния.
   протокол уровня для распределенной, совместной, гипермедиа информации
   системы. Этот документ определяет структуру HTTP-аутентификации.
Статус этого меморандума
   Это документ для отслеживания стандартов Интернета.
   Этот документ является продуктом Инженерной группы Интернета.
   (IETF). Он представляет собой консенсус сообщества IETF. Оно имеет
   получил общественное мнение и был одобрен для публикации
   Руководящая группа по разработке Интернет-технологий (IESG). Дополнительная информация о
   Интернет-стандарты доступны в разделе 2 RFC 5741.
   Информация о текущем статусе этого документа, любых опечатках,
   и как предоставить отзыв о нем можно получить на
   http://www. rfc-editor.org/info/rfc7235.
Уведомление об авторских правах
   Copyright (c) 2014 IETF Trust и лица, указанные в качестве
   авторы документа. Все права защищены.
   Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
   Положения, касающиеся документов IETF
   (http://trustee.ietf.org/license-info) действует на дату
   публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
   внимательно, так как они описывают ваши права и ограничения в отношении
   к этому документу. Компоненты кода, извлеченные из этого документа, должны
   включить текст упрощенной лицензии BSD, как описано в Разделе 4.e
   Доверительные юридические положения и предоставляются без гарантии, поскольку
   описан в Упрощенной лицензии BSD.
   Этот документ может содержать материалы из документов IETF или IETF.
   Материалы, опубликованные или ставшие общедоступными до ноября
   10, 2008. Лицо (лица), контролирующие авторские права на некоторые из этих
Трек стандартов Fielding & Reschke [Страница 1] 

---

RFC 7235 HTTP/1. 1 Аутентификация, июнь 2014 г.
   материал, возможно, не предоставил IETF Trust право разрешать
   модификации такого материала вне процесса стандартизации IETF.
   Без получения соответствующей лицензии от лица (лиц), контролирующего
   авторские права на такие материалы, этот документ не может быть изменен
   вне процесса стандартизации IETF, и его производные продукты могут
   не создаваться вне процесса стандартизации IETF, за исключением форматирования
   для публикации в виде RFC или для перевода на другие языки.
   чем английский.
Оглавление
   1. Введение ............................................... .....3
      1.1. Соответствие и обработка ошибок ......................3
      1.2. Синтаксическая нотация ......................................3
   2. Платформа аутентификации доступа ................................3
      2.1. Вызов и ответ ......................................................3
      2.2. Пространство Защиты (Царство) ......................................5
   3.  Определения кодов состояния ......................................6
      3.1. 401 Неавторизованный ......................................6
      3.2. 407 Требуется аутентификация прокси-сервера ......................6
   4. Определения полей заголовка ......................................7
      4.1. WWW-аутентификация ......................................7
      4.2. Авторизация ......................................................8
      4.3. Прокси-аутентификация ......................................8
      4.4. Прокси-авторизация ......................................95. Соображения IANA ......................................................9
      5.1. Реестр схем аутентификации ......................9
           5.1.1. Процедура ......................................................9
           5.1.2. Соображения по поводу новых схем аутентификации ..... 10
      5.2. Регистрация кода состояния ................................11
      5.3. Регистрация поля заголовка ........ ........................11
   6. Вопросы безопасности ......................................12
      6.1. Конфиденциальность учетных данных ................................12
      6.2. Учетные данные для аутентификации и незанятые клиенты ......................12
      6.3. Защитные пространства ................................................13
   7. Благодарности ....................................................... .14
   8. Ссылки ....................................................... ......14
      8.1. Нормативные ссылки ......................................14
      8.2. Информативные ссылки ......................................14
   Приложение A. Отличия от RFC 2616 и 2617 ......................16
   Приложение B. Импортированный ABNF ......................................16
   Приложение C. Собранные ABNF ................................17
   Индекс ................................................. ............18
Трек стандартов Fielding & Reschke [Страница 2] 

---

RFC 7235 HTTP/1. 1 Аутентификация, июнь 2014 г.
1. Введение
   HTTP обеспечивает общую основу для контроля доступа и
   аутентификация через расширяемый набор запросов-ответов
   схемы аутентификации, которые могут использоваться сервером для вызова
   клиентский запрос, а также клиент для предоставления аутентификационной информации.
   Этот документ определяет аутентификацию HTTP/1.1 с точки зрения
   архитектура, определенная в «Протоколе передачи гипертекста (HTTP/1.1):
   Синтаксис и маршрутизация сообщений» [RFC7230], включая общие
   каркас, ранее описанный в статье «Аутентификация HTTP: базовая и
   Digest Access Authentication" [RFC2617] и соответствующие поля и
   коды состояния, ранее определенные в «Протоколе передачи гипертекста —
   HTTP/1.1" [RFC2616].
   Реестр схемы аутентификации IANA (раздел 5.1) перечисляет
   зарегистрированные схемы аутентификации и соответствующие им
   спецификации, включая «базовую» и «дайджест» аутентификацию
   схемы, ранее определенные в RFC 2617.
1.1. Соответствие и обработка ошибок
   Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
   "СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ДОПОЛНИТЕЛЬНО" в этом
   документ должны интерпретироваться, как описано в [RFC2119]. 
   Критерии соответствия и соображения, касающиеся обработки ошибок, приведены ниже.
   определено в разделе 2.5 [RFC7230].
1.2. Синтаксическая нотация
   В этой спецификации используется расширенная форма Бэкуса-Наура (ABNF).
   нотация [RFC5234] с расширением списка, определенным в Разделе 7
   [RFC7230], который позволяет компактно определять разделенные запятыми
   списки с использованием оператора '#' (аналогично тому, как оператор '*' указывает
   репетиция). Приложение B описывает правила, импортированные из других
   документы. Приложение C показывает собранную грамматику со всем списком
   операторы расширены до стандартной нотации ABNF.
2. Доступ к платформе аутентификации
2.1. Вызов и ответ
   HTTP обеспечивает простую структуру аутентификации типа «запрос-ответ».
   который может использоваться сервером для вызова клиентского запроса и
   клиент для предоставления аутентификационных данных. Он использует случай-
   нечувствительный токен как средство идентификации схемы аутентификации,
   с последующей дополнительной информацией, необходимой для достижения
Трек стандартов Fielding & Reschke [Страница 3] 

---

RFC 7235 HTTP/1. 1 Аутентификация, июнь 2014 г.
   авторизация по этой схеме. Последняя может быть либо запятой-
   разделенный список параметров или единая последовательность символов
   способный хранить информацию в кодировке base64.
   Параметры аутентификации представляют собой пары имя=значение, где токен имени
   сопоставляется без учета регистра, и имя каждого параметра ДОЛЖНО
   происходят один раз за вызов.
     схема авторизации = токен
     auth-param = токен BWS "=" BWS ( токен / строка в кавычках )
     token68 = 1*( АЛЬФА/ЦИФРА/
                          "-"/"." / "_" / "~" / "+" / "/" ) *"="
   Синтаксис token68 позволяет использовать 66 незарезервированных символов URI.
   ([RFC3986]), плюс несколько других, чтобы он мог содержать base64,
   base64url (URL и безопасный алфавит имени файла), base32 или base16 (шестнадцатеричный)
   кодировка, с отступом или без, но исключая пробелы
   ([RFC4648]).
   Ответное сообщение 401 (Unauthorized) используется исходным сервером для
   оспаривать авторизацию пользовательского агента, включая
   Поле заголовка WWW-Authenticate, содержащее хотя бы один запрос
   применимо к запрошенному ресурсу. 
   Ответное сообщение 407 (требуется проверка подлинности прокси-сервера) используется
   прокси для оспаривания авторизации клиента, включая
   Поле заголовка Proxy-Authenticate, содержащее хотя бы один запрос
   применимо к прокси для запрошенного ресурса.
     вызов = схема авторизации [ 1 * SP ( token68 / # auth-param ) ]
      Примечание. Многие клиенты не могут проанализировать вызов, содержащий
      неизвестная схема. Обходной путь для этой проблемы состоит в том, чтобы перечислить
      сначала поддерживаемые схемы (например, «базовые»).
   Пользовательский агент, который хочет аутентифицировать себя на исходном сервере
   -- обычно, но не обязательно, после получения 401 (несанкционированный доступ)
   -- можно сделать это, включив поле заголовка Authorization с
   запрос.
   Клиент, который хочет аутентифицировать себя с помощью прокси-сервера — обычно
   но не обязательно, после получения ошибки 407 (прокси-аутентификация
   Required) -- можно сделать это, включив заголовок Proxy-Authorization
   поле с запросом. 
Трек стандартов Fielding & Reschke [Страница 4] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
   Значение поля Authorization и поле Proxy-Authorization
   значение содержит учетные данные клиента для области ресурса
   запрашивается на основе вызова, полученного в ответ
   (возможно, в какой-то момент в прошлом). При создании своих значений
   пользовательский агент должен сделать это, выбрав вызов с тем, что он
   считается самой безопасной схемой аутентификации, которую он понимает,
   получение учетных данных от пользователя по мере необходимости. Передача
   учетные данные в значениях поля заголовка подразумевает значительную безопасность
   соображения относительно конфиденциальности основного
   подключение, как описано в разделе 6.1.
     учетные данные = схема аутентификации [ 1 * SP ( token68 / # auth-param ) ]
   При получении запроса на защищенный ресурс, в котором отсутствует
   учетные данные, содержит недействительные учетные данные (например, неверный пароль) или
   частичные учетные данные (например, когда схема аутентификации требует
   более одного кругового пути), исходный сервер ДОЛЖЕН отправить 401
   (Неавторизованный) ответ, содержащий поле заголовка WWW-Authenticate
   по крайней мере с одним (возможно, новым) вызовом, применимым к
   запрашиваемый ресурс. 
   Аналогичным образом, при получении запроса, в котором отсутствуют учетные данные прокси-сервера или
   содержит неверные или неполные учетные данные прокси, прокси, который требует
   аутентификация ДОЛЖНА генерировать 407 (требуется аутентификация прокси)
   ответ, который содержит поле заголовка Proxy-Authenticate с at
   хотя бы один (возможно, новый) вызов, применимый к прокси.
   Сервер, который получает действительные учетные данные, которые не подходят для
   получить доступ должен ответить кодом состояния 403 (Запрещено)
   (раздел 6.5.3 [RFC7231]).
   HTTP не ограничивает приложения этим простым вызовом-ответом.
   фреймворк для аутентификации доступа. Дополнительные механизмы могут быть
   используется, например, аутентификация на транспортном уровне или через сообщение
   инкапсуляция и с дополнительными полями заголовка, указывающими
   аутентификационная информация. Однако такие дополнительные механизмы
   не определены настоящей спецификацией.
2.2. Защитное пространство (царство)
   Параметр аутентификации «область» зарезервирован для использования
   схемы аутентификации, которые хотят указать объем защиты. 
   Пространство защиты определяется каноническим корневым URI (схема
   и компоненты полномочий действующего URI запроса; см. раздел
   5.5 [RFC7230]) сервера, к которому осуществляется доступ, в сочетании с
   значение области, если оно присутствует. Эти сферы позволяют защищенным
   ресурсы на сервере должны быть разделены на набор защиты
Трек стандартов Fielding & Reschke [Страница 5] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
   пространства, каждое со своей собственной схемой аутентификации и/или авторизации
   база данных. Значение области представляет собой строку, обычно назначаемую
   исходный сервер, который может иметь дополнительную семантику, специфичную для
   схема аутентификации. Обратите внимание, что ответ может иметь несколько
   задачи с той же схемой авторизации, но с разными сферами.
   Пространство защиты определяет домен, в котором могут быть разрешены учетные данные.
   применяться автоматически. Если предварительный запрос был санкционирован,
   пользовательский агент МОЖЕТ повторно использовать одни и те же учетные данные для всех других запросов. 
   в пределах этого защитного пространства в течение периода времени, определяемого
   схема аутентификации, параметры и/или пользовательские настройки (например,
   настраиваемый тайм-аут бездействия). Если это специально не разрешено
   схема аутентификации, одно пространство защиты не может расширяться
   за пределами своего сервера.
   По историческим причинам отправитель ДОЛЖЕН генерировать только строку в кавычках
   синтаксис. Получателям, возможно, придется поддерживать как токен, так и
   Синтаксис строки в кавычках для максимальной совместимости с существующими
   клиенты, которые уже давно принимают обе нотации.
3. Определения кодов состояния
3.1. 401 Неавторизованный
   Код состояния 401 (Unauthorized) указывает на то, что запрос не
   был применен, потому что ему не хватает действительных учетных данных для аутентификации
   целевой ресурс. Сервер, генерирующий ответ 401, ДОЛЖЕН отправить
   поле заголовка WWW-Authenticate (раздел 4.1), содержащее по крайней мере один
   задача, применимая к целевому ресурсу. 
   Если запрос включал учетные данные для аутентификации, то ошибка 401
   ответ указывает, что авторизация была отклонена для тех
   реквизиты для входа. Пользовательский агент МОЖЕТ повторить запрос с новым или
   заменено поле заголовка Authorization (раздел 4.2). Если 401
   ответ содержит тот же вызов, что и предыдущий ответ, и
   пользовательский агент уже пытался аутентифицироваться хотя бы один раз, тогда
   пользовательский агент ДОЛЖЕН представить прилагаемое представление
   пользователю, так как он обычно содержит соответствующую диагностическую информацию.
3.2. 407 Требуется аутентификация прокси
   Код состояния 407 (требуется аутентификация прокси-сервера) аналогичен 401.
   (Неавторизованный), но это указывает на то, что клиенту необходимо
   аутентифицировать себя, чтобы использовать прокси. Прокси ДОЛЖЕН отправить
   Поле заголовка Proxy-Authenticate (раздел 4.3), содержащее запрос
   применимо к этому прокси для целевого ресурса. Клиент МОЖЕТ
   повторите запрос с новым или замененным заголовком Proxy-Authorization
   поле (раздел 4. 4).
Трек стандартов Fielding & Reschke [Страница 6] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
4. Определения полей заголовка
   Этот раздел определяет синтаксис и семантику полей заголовка.
   связанные с инфраструктурой HTTP-аутентификации.
4.1. WWW-аутентификация
   Поле заголовка «WWW-Authenticate» указывает
   схемы и параметры, применимые к целевому ресурсу.
     WWW-аутентификация = 1#вызов
   Сервер, генерирующий ответ 401 (неавторизованный), ДОЛЖЕН отправить
   Поле заголовка WWW-Authenticate, содержащее хотя бы один вызов. А
   сервер МОЖЕТ генерировать поле заголовка WWW-Authenticate в другом ответе
   сообщения, указывающие на то, что предоставление учетных данных (или других
   учетные данные) может повлиять на ответ.
   Прокси-сервер, пересылающий ответ, НЕ ДОЛЖЕН изменять какие-либо WWW-Authenticate
   поля в этом ответе.
   Пользовательским агентам рекомендуется проявлять особую осторожность при анализе поля
   значение, так как оно может содержать более одной задачи, и каждая
   вызов может содержать список аутентификационных данных, разделенных запятыми. 
   параметры. Более того, само поле заголовка может встречаться несколько раз.
   раз.
   Например:
     WWW-аутентификация: Newauth realm="apps", type=1,
                       title="Войти в \"приложения\"", Basic realm="simple"
   Это поле заголовка содержит две задачи; один для "Ньюаут"
   схема со значением области «приложения» и двумя дополнительными параметрами
   "тип" и "название", и еще один для схемы "Базовая" с
   значение области «простой».
      Примечание. При производстве грамматики вызова используется синтаксис списка, как
      Что ж. Таким образом, последовательность запятой, пробела и запятой может
      рассматриваться либо как относящиеся к предыдущему вызову, либо к
      быть пустой записью в списке вызовов. На практике это
      неоднозначность не влияет на семантику значения поля заголовка
      и поэтому безвреден.
Трек стандартов Fielding & Reschke [Страница 7] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
4.2. Авторизация
   Поле заголовка «Авторизация» позволяет пользовательскому агенту аутентифицировать
   себя с исходным сервером - обычно, но не обязательно, после
   получение ответа 401 (неавторизованный).  Его значение состоит из
   учетные данные, содержащие информацию об аутентификации пользователя
   агент для области запрашиваемого ресурса.
     Авторизация = учетные данные
   Если запрос аутентифицирован и указана область, то же самое
   учетные данные считаются действительными для всех других запросов в пределах
   этой сфере (при условии, что сама схема аутентификации не
   требуют иного, например учетные данные, которые варьируются в зависимости от
   значение вызова или с использованием синхронизированных часов).
   Прокси, пересылающий запрос, НЕ ДОЛЖЕН изменять какие-либо поля авторизации.
   в этом запросе. См. Раздел 3.2 [RFC7234] для получения подробной информации и
   требования, относящиеся к обработке поля авторизации
   Кэши HTTP.
4.3. Прокси-аутентификация
   Поле заголовка «Proxy-Authenticate» состоит как минимум из одного
   вызов, который указывает схему(ы) аутентификации и параметры
   применимо к прокси-серверу для этого эффективного URI запроса (раздел 5.5
   [RFC7230]).  Прокси-сервер ДОЛЖЕН отправить хотя бы одно сообщение Proxy-Authenticate.
   поле заголовка в каждом ответе 407 (требуется прокси-аутентификация)
   что он генерирует.
     Прокси-аутентификация = 1#вызов
   В отличие от WWW-Authenticate, поле заголовка Proxy-Authenticate применяется
   только следующему исходящему клиенту в цепочке ответов. Это
   потому что только клиент, выбравший данный прокси, скорее всего, будет иметь
   учетные данные, необходимые для аутентификации. Однако, когда несколько
   прокси используются в пределах одного административного домена, например
   офисные и региональные кеширующие прокси в крупной корпоративной сети,
   обычно учетные данные генерируются пользовательским агентом и
   проходят через иерархию до тех пор, пока не будут потреблены. Следовательно, в такой
   конфигурации, это будет выглядеть так, как будто Proxy-Authenticate
   перенаправляется, потому что каждый прокси будет отправлять один и тот же набор вызовов.
   Обратите внимание, что соображения анализа для WWW-Authenticate относятся к
   это поле заголовка, а также; подробности см.  в разделе 4.1.
Трек стандартов Fielding & Reschke [Страница 8] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
4.4. Прокси-авторизация
   Поле заголовка «Proxy-Authorization» позволяет клиенту идентифицировать
   себя (или своего пользователя) на прокси-сервер, требующий аутентификации. Его
   значение состоит из учетных данных, содержащих аутентификацию
   информация клиента для прокси и/или области ресурса
   запрашивается.
     Прокси-авторизация = учетные данные
   В отличие от Authorization, поле заголовка Proxy-Authorization применяется
   только к следующему входящему прокси-серверу, который потребовал аутентификацию с использованием
   Поле прокси-аутентификации. Когда несколько прокси используются в цепочке,
   поле заголовка Proxy-Authorization используется первым входящим
   прокси, который ожидал получить учетные данные. Прокси МОЖЕТ ретранслировать
   учетные данные от клиентского запроса к следующему прокси-серверу, если это
   механизм, с помощью которого прокси совместно аутентифицируют данный
   запрос. 
5. Соображения IANA
5.1. Реестр схемы аутентификации
   Схема аутентификации протокола передачи гипертекста (HTTP)
   Registry» определяет пространство имен для схем аутентификации в
   вызовы и полномочия. Он был создан и сейчас
   хранится по адресу .
5.1.1. Процедура
   Регистрация ДОЛЖНА включать следующие поля:
   o Имя схемы аутентификации
   o Указатель на текст спецификации
   o Примечания (необязательно)
   Значения, добавляемые в это пространство имен, требуют проверки IETF (см.
   [RFC5226], раздел 4.1).
Трек стандартов Филдинга и Решке [Страница 9] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
5.1.2. Рекомендации по новым схемам аутентификации
   Существуют определенные аспекты HTTP Authentication Framework, которые
   установить ограничения на то, как могут работать новые схемы аутентификации:
   o HTTP-аутентификация предполагается без сохранения состояния: все
      информация, необходимая для аутентификации запроса, ДОЛЖНА быть предоставлена
      в запросе, а не зависеть от того, запоминает ли сервер
      предварительные запросы.  Аутентификация, основанная или связанная с
      базовое соединение выходит за рамки этой спецификации
      и изначально ошибочны, если не будут предприняты шаги для обеспечения того, чтобы
      соединение не может быть использовано какой-либо стороной, кроме
      аутентифицированный пользователь (см. раздел 2.3 [RFC7230]).
   o Параметр аутентификации "область" зарезервирован для определения
      защитные пространства, как описано в разделе 2.2. Новые схемы ДОЛЖНЫ
      НЕ используйте его способом, несовместимым с этим определением.
   o Нотация "token68" была введена для совместимости с
      существующих схем аутентификации и может использоваться только один раз за
      вызов или удостоверение. Таким образом, новые схемы должны использовать
      вместо этого синтаксис auth-param, потому что в противном случае будущие расширения
      будет невозможно.
   o Разбор вызовов и учетных данных определяется этим
      спецификация и не может быть изменена новой аутентификацией
      схемы.  При использовании синтаксиса auth-param все параметры должны
      для поддержки синтаксиса токенов и строк в кавычках, а также синтаксического
      ограничения должны быть определены для значения поля после синтаксического анализа
      (т. е. обработка строки в кавычках). Это необходимо, чтобы
      получатели могут использовать общий синтаксический анализатор, который применяется ко всем
      схемы аутентификации.
      Примечание. Тот факт, что синтаксис значения параметра «область»
      ограниченный строкой в ​​кавычках был плохим выбором дизайна, чтобы не быть
      повторяется для новых параметров.
   o Определения новых схем должны определять обращение с
      неизвестные параметры расширения. В общем, правило «необходимо игнорировать».
      предпочтительнее правила «должен понять», потому что в противном случае
      сложно ввести новые параметры при наличии устаревших
      получатели. Кроме того, хорошо описать политику для
      определение новых параметров (например, «обновить спецификацию» или
      «использовать этот реестр»). 
   o Схемы аутентификации должны документально подтверждать возможность их использования в
      аутентификация исходного сервера (т. е. с использованием WWW-Authenticate),
      и/или аутентификация прокси (т. е. с использованием Proxy-Authenticate).
Трек стандартов Fielding & Reschke [Страница 10] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
   o Учетные данные, содержащиеся в поле заголовка Authorization,
      специфичны для пользовательского агента и, следовательно, имеют такое же влияние на
      Кэши HTTP как «частная» директива ответа Cache-Control
      (раздел 5.2.2.6 [RFC7234]), в рамках запроса в
      которые они появляются.
      Таким образом, новые схемы аутентификации, которые предпочитают не выполнять
      учетные данные в поле заголовка Authorization (например, используя недавно
      определенное поле заголовка) потребуется явно запретить кэширование,
      предписывающее использование любой директивы запроса Cache-Control
      (например, «без хранения», раздел 5. 2.1.5 [RFC7234]) или ответ
      директивы (например, «частные»).
5.2. Регистрация кода состояния
   «Реестр кодов состояния протокола передачи гипертекста (HTTP)», расположенный
   на  был
   обновлено с регистрацией ниже:
   +-------+--------------------------------+--------- ----+
   | Значение | Описание | Ссылка |
   +-------+--------------------------------+--------- ----+
   | 401 | Неавторизованный | Раздел 3.1 |
   | 407 | Требуется аутентификация прокси | Раздел 3.2 |
   +-------+--------------------------------+--------- ----+
5.3. Регистрация поля заголовка
   Поля заголовков HTTP регистрируются в «Заголовках сообщений».
   реестр ведется по адресу
   .
   Этот документ определяет следующие поля заголовка HTTP, поэтому
   Обновлен реестр «Постоянные имена полей заголовка сообщения».
   соответственно (см. [BCP90]).
   +---------------------+----------+-----------+----- --------+
   | Имя поля заголовка | Протокол | Статус | Ссылка |
   +---------------------+----------+-----------+----- --------+
   | Авторизация | http | стандартный | Раздел 4. 2 |
   | Прокси-аутентификация | http | стандартный | Раздел 4.3 |
   | Прокси-авторизация | http | стандартный | Раздел 4.4 |
   | WWW-Аутентификация | http | стандартный | Раздел 4.1 |
   +---------------------+----------+-----------+----- --------+
   Контроллер изменений: "IETF ([email protected]) - Интернет
   Инженерная оперативная группа».
Трек стандартов Fielding & Reschke [Страница 11] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
6. Вопросы безопасности
   Этот раздел предназначен для информирования разработчиков, поставщиков информации,
   и пользователи с известными проблемами безопасности, характерными для HTTP-аутентификации.
   Более общие соображения безопасности рассматриваются в обмене сообщениями HTTP.
   [RFC7230] и семантика [RFC7231].
   Все, что касается темы HTTP-аутентификации, — это безопасность.
   соображений, поэтому приведенный ниже список соображений не является исчерпывающим.
   Кроме того, он ограничивается соображениями безопасности в отношении
   рамки аутентификации в целом, а не обсуждать все
   потенциальные соображения для конкретных схем аутентификации
   (что должно быть задокументировано в спецификациях, определяющих эти
   схемы).  Различные организации хранят актуальную информацию и
   ссылки на текущие исследования по безопасности веб-приложений (например,
   [OWASP]), включая распространенные ошибки при внедрении и использовании
   схемы аутентификации, встречающиеся на практике.
6.1. Конфиденциальность учетных данных
   Платформа аутентификации HTTP не определяет единый механизм
   для сохранения конфиденциальности учетных данных; вместо этого каждый
   Схема аутентификации определяет, как учетные данные кодируются до
   к передаче. Хотя это обеспечивает гибкость для разработки
   будущих схем аутентификации, этого недостаточно для защиты
   существующих схем, которые сами по себе не обеспечивают конфиденциальности, или
   которые недостаточно защищают от повторных атак.
   Кроме того, если сервер ожидает учетные данные, относящиеся к
   каждого отдельного пользователя, обмен этими учетными данными будет иметь
   эффект идентификации этого пользователя, даже если содержимое внутри
   учетные данные остаются конфиденциальными. 
   HTTP зависит от свойств безопасности базового транспорта.
   или соединение на уровне сеанса для обеспечения конфиденциальной передачи
   поля заголовка. Другими словами, если сервер ограничивает доступ к
   аутентифицированных пользователей, использующих эту структуру, сервер должен обеспечить
   что соединение надежно защищено в соответствии с характером
   используемой схемы аутентификации. Например, услуги, которые зависят
   при индивидуальной аутентификации пользователя часто требуется, чтобы соединение было
   защищен с помощью TLS ("Transport Layer Security", [RFC5246]) до
   обмен какими-либо учетными данными.
6.2. Учетные данные аутентификации и бездействующие клиенты
   Существующие HTTP-клиенты и пользовательские агенты обычно сохраняют аутентификацию.
   информация бессрочно. HTTP не предоставляет механизма для
   исходный сервер, чтобы указать клиентам отказаться от этих кэшированных учетных данных,
   поскольку протокол не знает, как получаются учетные данные
Трек стандартов Fielding & Reschke [Страница 12] 

---

RFC 7235 HTTP/1. 1 Аутентификация, июнь 2014 г.
   или управляется пользовательским агентом. Механизмы истечения или
   отзыв учетных данных может быть указан как часть аутентификации
   определение схемы.
   Обстоятельства, при которых кэширование учетных данных может помешать
   Модель безопасности приложения включает, но не ограничивается:
   o Клиенты, бездействовавшие в течение длительного времени после
      который сервер может пожелать заставить клиента повторно запросить
      пользователя для учетных данных.
   o Приложения, которые включают индикацию завершения сеанса (например,
      как кнопку «выйти» или «зафиксировать» на странице), после чего сервер
      сторона приложения «знает», что больше нет причин
      чтобы клиент сохранил учетные данные.
   Пользовательским агентам, которые кэшируют учетные данные, рекомендуется предоставлять
   легкодоступный механизм для сброса кэшированных учетных данных под
   пользовательский контроль.
6.3. Защитные пространства
   Схемы аутентификации, которые полагаются исключительно на механизм «области» для
   установка защитного пространства откроет учетные данные для всех
   ресурсы на исходном сервере.  Клиенты, которые успешно сделали
   аутентифицированные запросы с ресурсом могут использовать один и тот же
   учетные данные аутентификации для других ресурсов в том же источнике
   сервер. Это позволяет собирать другой ресурс
   учетные данные аутентификации для других ресурсов.
   Это вызывает особую озабоченность, когда исходный сервер размещает ресурсы
   для нескольких сторон под одним и тем же каноническим корневым URI (раздел 2.2).
   Возможные стратегии смягчения включают ограничение прямого доступа к
   учетные данные аутентификации (т. е. не делать содержимое
   доступно поле заголовка запроса на авторизацию), и разделяющий
   пространства защиты, используя другое имя хоста (или номер порта) для
   каждой партии.
Трек стандартов Fielding & Reschke [Страница 13] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
7. Благодарности
   Эта спецификация берет на себя определение протокола HTTP.
   Authentication Framework, ранее определенный в RFC 2617. Мы благодарим
   Джон Фрэнкс, Филлип М.  Халлам-Бейкер, Джеффри Л. Хостетлер, Скотт Д.
   Лоуренс, Пол Дж. Лич, Ари Луотонен и Лоуренс С. Стюарт за
   свою работу над этой спецификацией. См. Раздел 6 [RFC2617] для
   дальнейшие подтверждения.
   См. Раздел 10 [RFC7230] для благодарностей, связанных с этим
   редакция документа.
8. Ссылки
8.1. Нормативные ссылки
   [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания
              Уровни требований», BCP 14, RFC 2119, март 1997 г.
   [RFC5234] Крокер, Д., изд. и П. Оверелл, "Расширенный BNF для синтаксиса".
              Спецификации: ABNF", STD 68, RFC 5234, январь 2008 г.
   [RFC7230] Филдинг, Р., изд. и Дж. Решке, изд., "Передача гипертекста
              Протокол (HTTP/1.1): синтаксис и маршрутизация сообщений»,
              RFC 7230, июнь 2014 г.
   [RFC7231] Филдинг, Р., изд. и Дж. Решке, изд., "Передача гипертекста
              Протокол (HTTP/1.1): семантика и содержимое", RFC 7231,
              июнь 2014 г.
   [RFC7234] Филдинг, Р., изд., Ноттингем, М. , изд., и Дж. Решке,
              Ред., «Протокол передачи гипертекста (HTTP/1.1): кэширование»,
              RFC 7234, июнь 2014 г.
8.2. Информативные ссылки
   [BCP90] Клайн, Г., Ноттингем, М., и Дж. Могул, «Регистрация
              Процедуры для полей заголовка сообщения", BCP 90, RFC 3864,
              Сентябрь 2004 г.
   [OWASP] ван дер Сток, А., изд., «Руководство по созданию безопасных веб-сайтов».
              Приложения и веб-службы», Открытое веб-приложение
              Проект безопасности (OWASP) 2.0.1, июль 2005 г.,
              .
   [RFC2616] Филдинг Р., Геттис Дж., Могул Дж., Фристик Х.,
              Масинтер Л., Лич П. и Т. Бернерс-Ли, "Гипертекст
              Протокол передачи — HTTP/1.1", RFC 2616, 19 июня.99.
Отслеживание стандартов Fielding & Reschke [Страница 14] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
   [RFC2617] Фрэнкс Дж., Халлам-Бейкер П., Хостетлер Дж., Лоуренс С.,
              Лич, П., Луотонен, А., и Л.  Стюарт, "HTTP
              Аутентификация: базовая и краткая аутентификация доступа»,
              RFC 2617, июнь 1999 г.
   [RFC3986] Бернерс-Ли, Т., Филдинг, Р., и Л. Масинтер, "Униформа
              Идентификатор ресурса (URI): общий синтаксис», STD 66,
              RFC 3986, январь 2005 г.
   [RFC4648] Йозефссон, С., «Данные Base16, Base32 и Base64».
              Кодировки», RFC 4648, октябрь 2006 г.
   [RFC5226] Нартен, Т. и Х. Альвестранд, «Рекомендации по написанию
              Раздел рекомендаций IANA в RFC", BCP 26, RFC 5226,
              май 2008 г.
   [RFC5246] Диркс, Т. и Э. Рескорла, "Безопасность транспортного уровня
              (TLS) Протокол версии 1.2", RFC 5246, август 2008 г.
Трек стандартов Fielding & Reschke [Страница 15] 

---

RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
Приложение A. Отличия от RFC 2616 и 2617
   Фреймворк HTTP-аутентификации теперь определяется этим
   документ, а не RFC 2617.
   Параметр «область» больше не всегда требуется в испытаниях;
   следовательно, ABNF разрешает вызовы без каких-либо параметров аутентификации. 
   (Раздел 2)
   Добавлена ​​альтернатива token68 спискам auth-param для
   совместимость с устаревшими схемами аутентификации, такими как «Basic».
   (Раздел 2)
   Эта спецификация вводит реестр схем аутентификации,
   вместе с соображениями о новых схемах аутентификации.
   (раздел 5.1)
Приложение B. Импортированный ABNF
   Следующие основные правила включены посредством ссылки, как определено в
   Приложение B.1 [RFC5234]: ALPHA (буквы), CR (возврат каретки),
   CRLF (CR LF), CTL (управление), DIGIT (десятичные 0-9), DQUOTE (двойной
   цитата), HEXDIG (шестнадцатеричный 0-9/A-F/a-f), LF (перевод строки), OCTET (любой
   8-битная последовательность данных), SP (пробел) и VCHAR (любой видимый символ US-ASCII).
   персонаж).
   Приведенные ниже правила определены в [RFC7230]:
     BWS = 
     OWS = 
     кавычка = <строка в кавычках, см. [RFC7230], раздел 3.2.6>
     token = <токен, см. [RFC7230], раздел 3.2.6>
Трек стандартов Fielding & Reschke [Страница 16] 

---

RFC 7235 HTTP/1. 1 Аутентификация, июнь 2014 г.
Приложение C. Собранные ABNF
   В собранном ниже ABNF правила списка расширены в соответствии с разделом
   1.2 [RFC7230].
   Авторизация = учетные данные
   BWS = 
   OWS = 
   Proxy-Authenticate = *( "," OWS ) вызов *( OWS "," [ OWS
    вызов ] )
   Прокси-авторизация = учетные данные
   WWW-Authenticate = *( "," OWS ) вызов *( OWS "," [ OWS вызов
    ] )
   auth-param = токен BWS "=" BWS ( токен / строка в кавычках )
   схема авторизации = токен
   вызов = схема авторизации [ 1 * SP ( token68 / [ ( "," / параметр аутентификации ) * (
    OWS "," [ OWS auth-param ] ) ] ) ]
   учетные данные = схема аутентификации [ 1 * SP ( token68 / [ ("," / параметр аутентификации )
    *( OWS "," [ OWS параметр авторизации ] ) ] ) ]
   кавычка = <строка в кавычках, см. [RFC7230], раздел 3.2.6>
   token = <токен, см. [RFC7230], раздел 3.2.6>
   token68 = 1*( АЛЬФА / ЦИФРА / "-" / "." / "_" / "~" / "+" / "/" )
    знак равно
Трек стандартов Филдинга и Решке [Страница 17] 

---

RFC 7235 HTTP/1. 1 Аутентификация, июнь 2014 г.
Индекс
   4
      401 Несанкционировано (код состояния) 6
      407 Требуется аутентификация прокси (код состояния) 6
   А
      Поле заголовка авторизации 8
   С
      Канонический корневой URI 5
   грамм
      Грамматика
         параметр авторизации 4
         схема авторизации 4
         Авторизация 8
         вызов 4
         учетные данные 5
         Прокси-аутентификация 8
         Прокси-авторизация 9
         токен68 4
         WWW-аутентификация 7
   п
      Защитное пространство 5
      Поле заголовка Proxy-Authenticate 8
      Поле заголовка Proxy-Authorization 9р
      Царство 5
   Вт
      Поле заголовка WWW-Authenticate 7
Отслеживание стандартов Fielding & Reschke [Страница 18] 

---

 RFC 7235 HTTP/1.1 Аутентификация, июнь 2014 г.
Адреса авторов
 Рой Т. Филдинг (редактор)
 Adobe Systems Инкорпорейтед
 345 Парк Авеню
 Сан-Хосе, Калифорния 95110
 США
 Электронная почта: [email protected]
 URI: http://roy.gbiv.com/
 Джулиан Ф.
No related posts.