Можно ли вернуть HTTP 401 для несуществующего ресурса вместо 404 для предотвращения раскрытия информации?

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

Представьте, что я создаю веб-сервис с автопомощи.

Предположим, что <

GET /api/persons/angela/location

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

Также рассмотрите запрос

GET /api/persons/john/location

когда пользователь не позвонил john в систему. Нет ресурса john, не говоря уже о ресурсе для местоположения john, поэтому это, очевидно, возвращает 404 Not Found. Или это?

Что делать, если я не хочу показывать, зарегистрирован ли john в системе?

(Возможно, имена пользователей взяты из небольшого пула университетских логинов, и в кампусе есть очень воинственная группа по велоспорту, которая принимает очень тусклый взгляд на использование автомобиля, даже если вы собираете пул? Они могут делать запросы по URL-адресу для каждого пользователя, и если они получают 401 вместо 404, сделайте вывод, что пользователь является автозагрузчиком)

Имеет ли смысл возвращать 401 Unauthorized для этого запроса, хотя ресурс не существует и нет возможного набора учетные данные, которые могут быть предоставлены в запросе, чтобы сервер возвращал 200?

Ответ 1

Собственно, W3C рекомендует (RFC 2616 §10.4.4 403 Запрещено) делает обратное. Если кто-то пытается получить доступ к ресурсу, но не имеет надлежащей аутентификации, верните 404, а не 403 (Запрещено). Это все еще решает проблему раскрытия информации.

Если сервер не желает эта информация доступна для клиент, код состояния 404 (Not Найдено).

Таким образом, вы никогда не вернете 403 (или 401). Однако, я думаю, ваше решение также разумно.

EDIT: Я думаю, что Гейб на правильном пути. Вам придется пересмотреть часть дизайна, но почему бы и нет:

Не найдено - 404
Недопустимое разрешение для пользователя - 404
Общее недопустимое разрешение (никто не может получить доступ) - 403
Не вошел - 401

Ответ 2

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

Hackable urls отлично подходят для информации, в которой вы хотите, чтобы все могли легко получить доступ. Однако для клиента RESTful нет проблем с использованием URI, которые полностью непрозрачны.

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

Ответ 3

Я думаю, что это нормально, если вы хотите вернуть 401 Unauthorized, если запрос сделан клиентом, который не является пользователем. Однако, если пользователь делает запрос и проходит проверку подлинности, то я не думаю, что оптимальным решением является 401. Если вы считаете, что возвращение 404 может поставить под угрозу безопасность некоторых пользователей, то вы можете захотеть вернуть 403 Forbidden или, возможно, 200 OK, но просто не указывайте местоположение. Если я запрошу для пользователя bob и получить ответ и запрос для пользователя sam и получить ответ об ошибке, будь то 401, 403, 404 и т.д., То я, вероятно, могу прийти к выводу, что это означает, что пользовательский sam не существует.

200 OK без указания местоположения может быть самым замаскированным решением.

Изменить: Просто для иллюстрации того, что я предлагаю. Верните 401, если клиент не авторизовался. В противном случае всегда возвращайте 200 OK.

<user-location for="bob">
    <location>geo-coordinates here</location>
</user-location>

<user-location for="sam">
    <location/>
</user-location>

На самом деле это не указывает, существует ли sam или нет, или, возможно, в настоящее время нет данных о местоположении для него.

Ответ 4

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

Ответ 5

Возвращает 401 Unauthorized в любом случае, когда пользователю не разрешено видеть конкретную страницу, независимо от того, существует она или нет.

Из RFC 2616: "Если запрос уже включил учетные данные авторизации, тогда ответ 401 указывает, что для этих учетных данных было отказано в авторизации".

Рассмотрим HTTP-серверы, которые используют отдельные списки учетных данных для аутентификации для разных URL-адресов. Очевидно, что сервер не должен проверять каждый список, когда запрашивается URL-адрес, поэтому, если учетные данные не входят в один применимый список, , поскольку HTTP-запросы полностью независимы друг от друга, имеет смысл вернуть 401 Unauthorized, если учетные данные недействительны для этого конкретного URL-адреса.

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