403 Запрещенные и 401 несанкционированные HTTP-ответы

для веб-страницы, которая существует, но для которой пользователь, который не имеет достаточных привилегий (они не вошли в систему или не принадлежат к соответствующей группе пользователей), каков правильный ответ HTTP для обслуживания? 401? 403? Что-то еще? То, что я прочитал на каждом из них до сих пор, не очень ясно о разнице между ними. Какие варианты использования подходят для каждого ответа?

14 ответов


четкое объяснение от Даниэль Ирвин:

есть проблема с 401 несанкционированный, код состояния HTTP для ошибок аутентификации. И в этом все дело: это для аутентификации, а не для авторизации. Получение ответа 401-это сервер, который говорит вам: "вы не проверку подлинности не прошла проверку подлинности или проверку подлинности неправильно–но, пожалуйста, повторите проверку и повторите попытку.- Чтобы помочь тебе., он всегда будет включать в себя WWW-аутентификация что описывается удостоверять.

Это ответ, обычно возвращаемый вашим веб-сервером, а не вашим веб-сервером приложение.

Это также что-то очень временное; сервер просит вас попробовать снова.

Итак, для авторизации я использую 403-запрещено ответ. Это постоянно, это связано с моей логикой приложения, и это более конкретно ответ, чем 401.

получение ответа 403-это сервер, который говорит вам: "извините. Я знаю кто ты–я верю в то, кем ты себя называешь-но у тебя просто нет ... разрешение на доступ к этому ресурсу. Может быть, если вы спросите систему администратор мило, вы получите разрешение. Но, пожалуйста, не беспокойтесь. снова я, пока твое положение не изменится."

В общем, a 401 несанкционированный ответ должен использоваться для отсутствующих или плохая аутентификация и 403-запрещено ответ впоследствии, когда пользователь аутентифицируется, но не авторизован выполнить запрошенную операцию на данном ресурсе.

другое хороший графический формат о том, как следует использовать коды состояния http.


посмотреть адресу rfc2616:

401-доступ запрещен:

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

ошибка 403:

сервер понял запрос, но отказывается выполнять его.

обновление

из вашего варианта использования, похоже, что пользователь не аутентифицируется. Я бы вернул 401.


Edit:адресу rfc2616 устарел, см. RFC7231 и RFC7235.


Что-то другие ответы отсутствуют, это то, что необходимо понимать, что аутентификация и авторизация в контексте RFC 2616 относится только к протоколу аутентификации HTTP RFC 2617. Аутентификация по схемам вне RFC2617 не поддерживается в кодах состояния HTTP и не учитывается при принятии решения об использовании 401 или 403..

кратко и кратко

Unauthorized указывает, что клиент не прошел проверку подлинности RFC2617 и сервер инициирование процесса аутентификации. Запрещено означает, что клиент прошел проверку подлинности RFC2617 и не имеет авторизации или что сервер не поддерживает RFC2617 для запрашиваемого ресурса.

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

подробный и углубленный

с адресу rfc2616

10.4.2 401 Несанкционированный

запрос требует аутентификации пользователя. Ответ должен включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее вызов, применимый к запрашиваемому ресурсу. Клиент может повторить запрос с подходящим полем заголовка Authorization (раздел 14.8).

и

10.4.4 403 запрещено Сервер понял запрос, но отказывается выполнять его. Авторизация не поможет, и запрос Не следует повторять.

первое, что нужно иметь в виду, это то, что "аутентификация" и "авторизация" в контексте этого документа относятся конкретно к протоколам аутентификации HTTP от RFC 2617. Они не ссылаются на какие-либо протоколы аутентификации roll-your-own, которые вы, возможно, создали с помощью страниц входа и т. д. Я буду использовать "login" для ссылки на аутентификацию и авторизацию методами, отличными от RFC2617

Так что реальная разница не в том, что проблема или даже если есть решение. Разница в том что сервер ожидает клиента делать дальше.

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

403 указывает, что ресурс может не предоставляется, и для текущего пользователя нет способа решить эту проблему через RFC2617 и нет смысла пытаться. Это может быть потому, что известно, что уровень аутентификации недостаточен (например, из-за черного списка IP), но это может быть потому, что пользователь уже аутентифицирован и не имеет полномочий. Модель RFC2617 является однопользовательской, однопользовательской, поэтому случай, когда пользователь может иметь второй набор учетных данных, которые могут быть авторизованы, может игнорироваться. Она не предполагает ни подразумевает, что какая-то страница входа или другой протокол аутентификации, отличный от RFC2617, может помочь или не помочь - это выходит за рамки стандартов и определения RFC2616.


Edit:адресу rfc2616 устарел, см. RFC7231 и RFC7235.


по данным RFC 2616 (протокол HTTP/1.1) 403 отправляется, когда:

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

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


   GET, resource exists ?
    |      |
 NO |      | YES
    v      v
   404     Is authenticated (logged-in) ?
             |              |
          NO |              | YES
             v              v
             401            Can access resource (has permissions) ?
           (or: 404)        |            |
           or 301        NO |            | YES
           redirect         v            v
           to login        403           OK 200, 301, ...

проверки обычно выполняются в следующем порядке:

  • 401 если не вошел в систему или сеанс истек
  • 403 если пользователь не имеет разрешения на доступ к ресурсу
  • 404, если ресурс не существует

несанкционированный: код состояния (401), указывающий, что запрос требует проверка подлинности, обычно это означает, что пользователь должен войти в систему (сеанс). Пользователь / агент неизвестен серверу. Могу повторить с другие полномочия. Примечание: это сбивает с толку, поскольку это должно было быть названо "unauthenticated" вместо "unauthorized". Это также может завершиться ошибкой, если сеанс истек.

запрещен: код состояния (403), указывающий, что сервер понял запрос, но отказался его выполнить. Пользователь / агент, известный серверу, но имеет недостаточно учетных данных. Повторный запрос не будет работать, если учетные данные не будут изменены, что очень маловероятно за короткое время промежуток.

НЕ НАЙДЕНО: код состояния (404), указывающий, что запрошенный ресурс недоступен. Пользователь / агент известен, но сервер ничего не расскажет о ресурсе, как будто его не существует. Повторение не сработает. Это специальное использование 404 (github делает это, например).


Если аутентификация как другой пользователь предоставит доступ к запрошенному ресурсу, то 401 Unauthorized должен быть возвращен. 403 Forbidden в основном используется, когда доступ к ресурсу запрещен всем или ограничен данной сетью или разрешен только через SSL, независимо от того, пока он не связан с аутентификацией.

из RFC 7235 (протокол передачи гипертекста (HTTP / 1.1): аутентификация):

3.1. 401 несанкционированного

В 401 (Несанкционированного) код состояния указывает, что запрос не применено, поскольку отсутствуют действительные учетные данные проверки подлинности для целевого ресурса. Исходный сервер должен отправить WWW-поле заголовка аутентификации (раздел 4.4), содержащее по крайней мере один задача, применимая к целевому ресурсу. если запрос включены учетные данные проверки подлинности, затем ответ 401 указывает, что разрешение было отказано для тех верительные грамоты. Клиент Может повторить запрос с новым или заменил поле заголовка Authorization (раздел 4.1). Если 401 ответ содержит ту же задачу, что и предыдущий ответ, и агент пользователя уже предпринял попытку аутентификации по крайней мере один раз, затем агент пользователя должен представить прилагаемое представление пользователь, поскольку он обычно содержит соответствующую диагностическую информацию.

и это из RFC 2616:

10.4.4 403 Запрещено

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

Edit: RFC 7231 (протокол передачи гипертекста (HTTP / 1.1): семантика и содержание) изменяет значение 403:

6.5.3. 403 запрещено

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

если учетные данные были предоставлены в заявке,
сервер считает их недостаточными для предоставления доступа. Клиент
Не следует автоматически повторять запрос с тем же
полномочия. Клиент может повторить запрос с новым или другим полномочия. Однако запрос может быть запрещен по причинам
не связанные с верительными грамотами.

исходный сервер, который хочет "скрыть" текущее существование a
запрещенный целевой ресурс может вместо этого отвечать кодом состояния
404 (Не Найдено).

таким образом, 403 теперь может означать что угодно. Предоставление новых учетных данных может помочь... а может, и нет.


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

OWASP имеет некоторые дополнительная информация о том, как злоумышленник может использовать эту информацию как часть нападения.


этот вопрос был задан некоторое время назад, но мышление людей переходит на.

6.5.3 в этом проекте (автором которого являются Филдинг и Решке) код состояния 403 имеет несколько иное значение для задокументированного в RFC 2616.

Он отражает то, что происходит в схемах аутентификации и авторизации, используемых рядом популярных веб-серверов и фреймворков.

Я подчеркнул бит, который я думаю, больше всего выступ.

6.5.3. 403 запрещено

код состояния 403 (запрещено) указывает, что сервер понял запрос, но отказывается его авторизовать. Сервер, который хочет опубликовать, почему запрос был запрещен, может описать эту причину в полезной нагрузке ответа (если таковая имеется).

Если учетные данные были предоставлены в запрос, сервер считает их недостаточными для предоставления доступа. клиент не должен повторять запрос с теми же учетными данными. Клиент может повторить запрос с новыми или другими учетными данными. однако, запрос может быть запрещено по причинам, не связанным с учетными данными.

исходный сервер, который хочет "скрыть" текущее существование запрещенного целевого ресурса, может вместо этого ответить кодом состояния 404 (не найден).

какое бы соглашение вы ни использовали, важное дело в том, чтобы обеспечить единообразие на вашем сайте / API.


TL; DR

  • 401: отказ, который имеет отношение к аутентификации
  • 403: отказ, который не имеет ничего общего с аутентификацией

Практические Примеры

если apache требует проверки подлинности (via .htaccess) и нажмите Cancel, он ответит 401 Authorization Required

если nginx и находит файл, но нет права доступа (пользователь / группа) to чтение / доступ к нему, он ответит 403 Forbidden

RFC (2616 раздел 10)

401 несанкционированный (10.4.2)

значение 1: нужен для проверки подлинности

запрос требует аутентификации пользователя. ...

значение 2: недостаточной проверки подлинности

... Если запрос уже включал учетные данные авторизации, то ответ 401 указывает, что в выдаче этих полномочий было отказано. ...

403 запрещено (10.4.4)

значение: не связано с аутентификацией

... Авторизация не поможет ...

Подробнее:

  • сервер понял запрос, но отказывается выполнять его.

  • он должен описать причину отказа в объекте

  • вместо этого можно использовать код состояния 404 (не найден)

    (если сервер хочет сохранить эту информацию от клиента)


они не вошли в систему или не принадлежат к соответствующей группе пользователей

вы указали два разных случая; каждый случай должен иметь другой ответ:

  1. если они не вошли в систему вы должны возвратить 401 несанкционированный
  2. если они вошли в систему, но не принадлежат соответствующей группе пользователей, вы должны вернуть 403-запрещено

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

вот некоторые случаи в этой логике, когда ошибка будет возвращена из аутентификации или авторизации с важными фразами полужирный.

  • ресурс требует аутентификации, но нет полномочий были указано.

401 клиент должен указать учетные данные.

  • указанные учетные данные находятся в неверный формат.

400: это не 401 и не 403, так как синтаксические ошибки всегда должны возвращать 400.

  • ссылка на указанные учетные данные а пользователей, который не существует.

401: заказчик должен указать действительные учетные данные.

  • указанного полномочия are недействительным но укажите действительного пользователя (или не указывайте пользователя, поскольку указанный пользователь не требуется).

401: опять же, клиент должен указать действительные учетные данные.

  • указанного полномочия есть истек.

401: это практически то же самое, что неверные учетные данные в целом, поэтому клиент должен указать действительные учетные данные.

  • указанные учетные данные полностью допустимы, но не хватает в частности ресурс, хотя возможно, что учетные данные с большим разрешением могли бы.

403: Указание допустимых учетных данных не предоставляет доступ к ресурсу, поскольку текущие учетные данные уже действительны, но только не имеют разрешения.

  • в частности ресурс is недоступен независимо от учетных данных.

403: это независимо от учетных данных, поэтому указание действительных учетных данных не может помочь.

  • указанные учетные данные полностью действительны, но клиент is заблокирован от их использования.

403: если клиент заблокирован, указание новых учетных данных ничего не сделает.


Это проще в моей голове, чем где-либо здесь, поэтому:

401: вам нужно http basic auth, чтобы увидеть это.

403: вы не можете этого видеть, и HTTP basic auth не поможет.

если пользователю просто нужно войти в систему, используя стандартную форму входа HTML вашего сайта, 401 не будет подходящим, потому что он специфичен для HTTP basic auth.

Я не рекомендую использовать 403, чтобы запретить доступ к таким вещам, как /includes, потому что, насколько это касается интернета, те ресурсов вообще не существует и поэтому должно быть 404.

это оставляет 403 как "вам нужно войти в систему".

другими словами, 403 означает "этот ресурс требует некоторой формы аутентификации, отличной от базовой аутентификации HTTP".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2


учитывая последние RFC по этому вопросу (7231 и 7235) прецедент кажется вполне ясным (курсив добавлен):

  • 401 для unauthenticated ("отсутствует действительная аутентификация"); т. е. " я не знаю, кто вы, или я не верю, что вы тот, за кого себя выдаете.'

401 несанкционированный

код состояния 401 (несанкционированный) указывает, что запрос не было применяется, потому что это отсутствует действительная аутентификация учетные данные для целевой ресурс. Сервер, генерирующий ответ 401, должен отправить поле заголовка WWW-Authenticate (раздел 4.1), содержащее по крайней мере одно задача, применимая к целевому ресурсу.

Если запрос включал учетные данные аутентификации, то 401 в ответе указывается, что тем лицам было отказано в разрешении полномочия. Агент пользователя может повторить запрос с помощью новый или заменил поле заголовка Authorization (раздел 4.2). Если 401 ответ содержит ту же задачу, что и предыдущий ответ, и агент пользователя уже предпринял попытку аутентификации по крайней мере один раз, затем агент пользователя должен представить прилагаемое представление пользователь, поскольку он обычно содержит соответствующую диагностическую информацию.

  • 403 для несанкционированный ("не разрешает"); т. е. 'я знаю, кто вы, но вы нет разрешения на доступ к этому ресурсу.'

403-запрещено

код состояния 403 (запрещено) указывает, что сервер понял просьба но отказывается авторизовать его. Сервер, который желает обнародуйте, почему запрос был запрещен, может описать, что причина в полезной нагрузке ответа (если таковая имеется).

Если учетные данные были предоставлены в заявке, этот сервер считает их недостаточными для предоставления доступа. Клиент Не следует автоматически повторять запрос с тем же полномочия. Клиент может повторить запрос с новым или другим полномочия. Однако запрос может быть запрещен по причинам не связанные с верительными грамотами.

исходный сервер, который хочет "скрыть" текущее существование вместо этого запрещенный целевой ресурс может ответить кодом состояния 404 (не Найдено.)


в случае 401 против 403, это было отвечено много раз. Это, по сути, дебаты "среды HTTP-запросов", а не дебаты "приложения".

кажется, есть вопрос о проблеме roll-your-own-login (приложение).

в этом случае просто не войти в систему недостаточно для отправки 401 или 403, если вы не используете http Auth против страницы входа в систему (не привязаны к настройке http Auth). Похоже, вы можете искать "201 созданный", с roll-your-own-login screen present (вместо запрошенного ресурса) для доступа к файлу на уровне приложения. Это говорит:

" Я слышал вас, он здесь, но попробуйте это вместо этого (вам не разрешено его видеть)"