Я пишу небольшое приложение, которое предоставляет простой HTTP-API REST-ish. Я застрял, пытаясь решить, как сигнализировать о неудаче из-за отсутствия авторизации.
Приложение не имеет API для аутентификации, но вместо этого зависит от наличия cookie, содержащего токен сеанса, полученный клиентом через другую службу. Приложение проверяет сеанс и использует идентификатор, полученный с помощью процесса проверки, для выполнения авторизации приложения. Клиенту нет возможности аутентифицироваться непосредственно в этом приложении.
Моя проблема заключается в том, что очевидный код статуса HTTP для отклонения несанкционированных запросов "401 Unauthorized" указан в заголовке "WWW-Authenticate". См. rfc2616 с 10.4.2.
Ответ ДОЛЖЕН включать Поле заголовка WWW-Authenticate (раздел 14.47), содержащий запрос, применимый к запрашиваемому ресурсу.
Я не могу поверить, что это необычная проблема. Является ли распространением просто перегрузка 401 для включения более общих применений? Что касается браузеров, которые открывают диалоговые окна auth/e (что, кстати, я не видел в своем тестировании, возможно, это не так для POST)?
Нижняя строка: можно ли использовать 401 в этом контексте или есть лучшее решение?
Как правило, вы отправляете 401, если клиент может аутентифицировать и решить проблему, но поскольку вы не предоставляете способ аутентификации в API, я бы предложил вернуть ошибку 403 (запрещено). Это не будет требовать заголовка и укажет клиенту, что он не может получить доступ к службе.
Возвратите что-то вроде этого:
HTTP/1.1 401 Unauthorized
Location: https://example.com/auth-app/login