Какой код статуса должен быть возвращен, если кто-либо запрашивает доступ к объекту, который ему не разрешено видеть? Вероятно, вы скажете, что это 403: Запрещено. Но стоит ли вместо этого возвращать 404? Я не хочу, чтобы кто-то знал, что эта сущность даже существует, если ему не разрешено ее видеть. Как вы думаете?Доступ запрещен: 403 или 404?
Использование 404 Не найдено.
код 404 состояния также могут быть использованы в 403 случаях, когда сервер не хочет, чтобы отправить обратно причину, почему она отказывается служить запрос. Хорошим примером является то, что сервер чувствует какую-либо атаку , которая может быть атакой грубой силы. В этом случае сервер отвечает 404 не найденным вместо 403 запрещенного и объяснений.
Источник: Pro ASP.NET Web API Security
403 Forbidden. Если вы вернете это для каждого запроса, клиенту не разрешен доступ, и если вы никогда не возвращаете 404 Not Found, клиент ничего не знает.
Все зависит от того, насколько это важно для вас:
Я не хочу, чтобы кто знает, что этот объект существует даже если он не допускается, чтобы увидеть его.
Если это действительно важно, всегда возвращайте 403 Forbidden.
Это по существу то же самое, что и всегда возвращаемое 404, вы только что выбрали другой статус, чтобы вернуться для этих двух сценариев. Для записи, если вы всегда возвращаете 404, клиент ничего не узнает. – Anthony
Надеется, что вы получите некоторые разъяснения об ошибках HTTP, основанных на том, что я отправляю ниже:
HTTP 401 ошибка :: Эта ошибка происходит, когда посетитель сайта пытается получить доступ к ограниченному вебу-странице, но не авторизован для этого.
Ошибка HTTP 403 :: Эта ошибка аналогична ошибке 401, но обратите внимание на разницу между несанкционированными и запрещенными. Это может произойти, например, при попытке доступа к каталогу (запрещенному) на любом веб-сайте.
Ошибка HTTP 404 :: Ошибка 404 возникает при попытке доступа к ресурсу на веб-сервере (обычно в веб-странице), которого не существует.
: P Забыл, я не работал на моем домашнем портале. У этого есть только аналогичная функция, как то, что я только что принял! В любом случае, это ответ, что вы ищете? –
Нет, это просто определение кодов состояния, я знаю, что они означают. –
Ну .. это зависит ..
Если URL-адреса конечных точек раскрыть конфиденциальную информацию (например, в Dropbox API, вы обращаетесь к файлам по их именам, а не их Идентификаторы - поэтому URL-адреса содержат имена файлов) или, возможно, вы используете последовательные идентификаторы (например, восходящие идентификаторы, которые могут быть грубыми), возврат 404.
Если вам необходимо поддерживать функцию «Запросить доступ», ресурсов, на которые у вас нет разрешений, верните 403, поэтому ваши клиентские Идея может отличить друг от друга.
Вообще говоря, если ваш API использует идентификаторы и никогда не раскрывает информацию как часть своих URL-адресов, и вы используете UUID в качестве идентификаторов, я бы пошел с 403 .. как и со многими известными и очень защищенными приложениями в настоящее время (Google , Microsoft и т. Д.).
Это сложно, потому что 401 может использоваться и для сценария доступа к запросу. Или вы всегда можете вернуть 403 (как кто-то предложил) и разрешить запросы на доступ к несуществующим ресурсам, которые в основном просто идут прямо к корзине. – Anthony
Что бы вы вернули для ресурсов, которые делают * not *, и доступ к клиенту недоступен? –