Кратко

  • 480 отклонял команду в текущем состоянии соединения, а не откладывал её до завершения аутентификации.
  • После AUTHINFO клиент заново узнавал доступные возможности и сам повторял запрос ресурса.
  • Успешная аутентификация не означала всеобщего допуска: повторная команда могла получить 502 по локальной политике.

Два одинаковых запроса с разными основаниями

Сначала клиент отправляет GROUP local.research. Сервер отвечает 480 Permission denied. Клиент выясняет допустимые способы входа, выполняет AUTHINFO и получает 281 Authentication accepted. В этот момент группа всё ещё не выбрана.

Для выбора нужна вторая строка GROUP local.research. Первая попытка закончилась ответом 480. Сервер не держал её в скрытой очереди и не связывал с первой подходящей личностью, которая появится позднее.

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

Развёрнутые системы раньше стандарта закрепили повтор

RFC 2980 описал распространённые расширения NNTP. В исходной схеме AUTHINFO USER и AUTHINFO PASS сервер отвечал 480, мог потребовать пароль через 381 и подтверждал принятую комбинацию кодом 281. Затем клиент должен был снова послать исходную команду, а сервер — обработать новую попытку обычным образом.

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

У исторического метода была серьёзная уязвимость. RFC 2980 прямо отмечал, что вся информация аутентификации передавалась открытым текстом. Правильная граница повторного запроса не обеспечивала тайну пароля. Для этого требовалась отдельная защищённая среда.

AUTHINFO не присвоил себе решение о доступе

RFC 4643 формализовал AUTHINFO, оставил USER/PASS ради совместимости, отказался от SIMPLE и GENERIC и определил профиль SASL. Документ проводит принципиальную границу: расширение аутентифицирует пользователя, а авторизация остаётся политикой конкретного сайта.

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

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

CAPABILITIES описывал текущий момент

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

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

Перечень механизмов SASL намеренно остаётся прежним. Он служит контрольной точкой для обнаружения активного понижения согласованных вариантов. Сохранение списка не разрешает новый вход: способность AUTHINFO уже исчезла.

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

У обмена личностью были собственные стоп-сигналы

AUTHINFO разрешалось начать после 480 или заранее, если способность объявлена. Но продолжать после первого шага можно было лишь при ответе класса 38x, явно приглашающем к следующему этапу. Любой иной ответ завершал обмен; отправлять дополнительные секреты было нельзя.

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

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

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

Код 483 сообщал об отсутствии подходящей защиты соединения. RFC 4642 определил STARTTLS: после криптографического перехода прикладное состояние строилось заново, а возможности перечитывались. USER/PASS мог появиться только внутри защищённого канала; выбор SASL также мог измениться.

Протокол сохранял четыре отдельных вопроса. Защищена ли линия? Принята ли личность? Разрешён ли ей этот ресурс? Послал ли клиент команду заново в таком состоянии? TLS, AUTHINFO, локальная политика и повтор отвечали каждый на своё.

Ни TLS, ни AUTHINFO не удостоверяли новостную статью сквозным образом. TLS защищал одно соединение NNTP. AUTHINFO устанавливал личность клиента сеанса, но не обязательно автора текста и не все последующие ретрансляторы.

Отказ был свидетельством, а не отложенной работой

RFC 3977 показывает доступ к защищённому ресурсу как последовательность: команда группы, 480, обмен аутентификации и новая команда группы. Сам повтор доказывает завершённость первой попытки.

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

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

IANA зарегистрировала переходы, а не разрешения

Реестр параметров NNTP IANA отдельно перечисляет AUTHINFO, SASL и STARTTLS со своими нормативными ссылками. Общий словарь позволяет согласовывать разные изменения состояния, не смешивая их.

Запись в реестре не доказывает поддержку на конкретном сервере, безопасность USER/PASS в любом канале или права счёта. Доказательствами остаются список возможностей этого соединения и ответ на команду, которую клиент решил отправить снова.

Историческое решение NNTP применимо далеко за пределами сетевых новостей. Более сильная личность может исправить контекст отклонённого действия, но не должна автоматически получать право на его воспроизведение. Система узнаёт, кто говорит, и всё равно ждёт нового ответа на вопрос: что вы хотите сделать сейчас?

Источники