Должен ли я возвращать код ответа 401 или 405 пользователю REST API без достаточного доступа?

Я разрабатываю API, который также будет иметь компонент аутентификации/авторизации.

Любой, независимо от статуса проверки подлинности, сможет писать (POST), но в зависимости от того, не прошли ли вы проверку подлинности, прошли проверку подлинности как обычный пользователь или прошли проверку подлинности как администратор и к какому ресурсу вы пытаетесь получить доступ, я собираюсь вернуть разные ответы. для GET, DELETE и PUT.

Я пытаюсь выяснить наиболее подходящий код ответа для пользователя, который не прошел проверку подлинности и/или не авторизован.

Имейте в виду http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

Неавторизованный -> 401

Запрещено -> 403

Метод не разрешен -> 405

Давайте использовать конкретные примеры:

  • John Doe не аутентифицирован, при DELETE он должен получить 401 или 405?
  • Эми аутентифицирована, но не авторизована, при удалении она должна получить 403 или 405?

(Имейте в виду, что даже несмотря на то, что Джон и Эми запрещены или не авторизованы, это не означает, что они не могут получить доступ к одному и тому же ресурсу с помощью другой ГЛАГОЛ HTTP.)

Спасибо.


http api rest httpresponse http-status-codes
person Chris W.    schedule 26.06.2012    source источник
comment
См. также stackoverflow.com/questions /3297048/   -  person Ry-♦    schedule 26.06.2012
comment
Итак, Джон должен получить 401, Эми должна получить 403.   -  person Ry-♦    schedule 26.06.2012
comment
405 Method Not Allowed кажется совершенно не связанным.   -  person Ry-♦    schedule 26.06.2012
comment
@minitech, дело в том, что другие методы все еще разрешены, например, GET может быть разрешен, даже если DELETE запрещен. Таким образом, кажется, что кто-то может захотеть сделать 405, чтобы прояснить, что весь ресурс запрещен не только этот конкретный ГЛАГОЛ, связанный с ним.   -  person Chris W.    schedule 26.06.2012

Ответы (2)


arrow_upward
13
arrow_downward

405 Method Not Allowed следует использовать только в том случае, если вы не поддерживаете этот метод. Его не следует использовать, чтобы сообщить клиенту, что он не может использовать этот метод.

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

person laurent    schedule 26.06.2012
comment
Почти. Если вы прошли аутентификацию, но вам не разрешено выполнять операцию, это будет 403. - person Julian Reschke; 26.06.2012
comment
@JulianReschke, хм, не уверен. Для 403 в стандарте указано, что в отличие от ответа 401 Unauthorized, аутентификация не имеет значения. Но в этом случае аутентификация будет иметь значение, поскольку она позволит получить доступ к ресурсу. - person laurent; 26.06.2012
comment
Лоран: Сервер понял запрос, но отказывается его авторизовать. Предоставление других учетных данных для проверки подлинности пользователя может быть успешным, но любые учетные данные, предоставленные в запросе, недостаточны. Запрос НЕ ДОЛЖЕН повторяться с теми же учетными данными. -- greenbytes.de/tech/ вебдав/ - person Julian Reschke; 26.06.2012

arrow_upward
35
arrow_downward

В этом случае, я думаю, полезно привести несколько примеров для пояснения:

  • Неаутентифицированный + Поддерживаемый метод = 401
  • Неаутентифицированный + неподдерживаемый метод = 405
  • Аутентифицированный + Авторизованный + Поддерживаемый метод = 2xx
  • Аутентифицированный + авторизованный + неподдерживаемый метод = 405
  • Аутентифицированный + Неавторизованный + Поддерживаемый метод = 403
  • Аутентифицированный + неавторизованный + неподдерживаемый метод = 405

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

  1. Проверьте, поддерживаются ли методы. Если нет: 405
  2. Если поддерживается, проверьте, аутентифицирован ли пользователь. Если нет: 401
  3. Если аутентифицирован, проверьте, авторизован ли пользователь. Если нет: 403
  4. Если разрешено: 2xx

EDIT: я наткнулся на эту диаграмму и подумал, что она может быть полезна всем, кто может наткнуться на этот пост. Нажмите, чтобы увеличить.

введите описание изображения здесь

Оригинал здесь.

person docksteaderluke    schedule 02.02.2016
comment
Вау, это невероятно подробно. Я молю богов-разработчиков, чтобы мне никогда не пришлось использовать более 5% этой блок-схемы. - person Chris W.; 16.11.2016