http headers - ошибка - 403 Запрещено vs 401 Неавторизованные ответы HTTP




ошибка 302 (10)

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


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

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

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

TL; DR

  • 401: отказ, связанный с аутентификацией
  • 403: отказ, который НИЧЕГО не делает с аутентификацией

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

Если apache требует аутентификации (через .htaccess ), и вы нажмете « Cancel , он ответит с 401 Authorization Required

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

RFC (2616, раздел 10)

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

Значение 1: необходимость аутентификации

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

Значение 2: недостаточно аутентификация

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

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

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

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

Подробнее:

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

  • СЛЕДУЕТ описать причину отказа в юридическом лице

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

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


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

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

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

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

И это из RFC 2616:

10.4.4 403 Запрещено

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

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

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

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

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

Сервер происхождения, который хочет «скрыть» текущее существование
запрещенный целевой ресурс МОЖЕТ вместо этого отвечать кодом состояния
404 Не Найдено).

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


См. RFC2616 :

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

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

403 Запрещено:

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

Обновить

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

Изменить: RFC2616 устарел, см. RFC7231 и RFC7235 .


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

  • 401 - для не unauthenticated («отсутствует достоверная проверка подлинности»); т.е. «Я не знаю, кто вы, или я не верю, что вы такие, кем вы себя называете».

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

Код статуса 401 (Несанкционированный) указывает, что запрос не был применен, поскольку ему не хватает действительных учетных данных для целевого ресурса. Сервер, генерирующий ответ 401, ДОЛЖЕН отправить поле заголовка WWW-Authenticate (раздел 4.1), содержащее хотя бы одну проблему, применимую к целевому ресурсу.

Если запрос включает аутентификационные данные, то ответ 401 указывает, что для этих учетных данных было отказано в авторизации. Пользовательский агент МОЖЕТ повторить запрос с новым или замененным заголовком заголовка авторизации (раздел 4.2). Если ответ 401 содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже пытался выполнить аутентификацию хотя бы один раз, тогда пользовательский агент ДОЛЖЕН представить закрытое представление пользователю, поскольку оно обычно содержит соответствующую диагностическую информацию.

  • 403 предназначен для unauthorized («отказывается санкционировать»); т.е. «Я знаю, кто вы, но у вас нет разрешения на доступ к этому ресурсу».

403 Запрещено

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

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

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


Что-то, чего не хватает другим, заключается в том, что следует понимать, что аутентификация и авторизация в контексте 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), содержащее вызов, применимый к запрашиваемому ресурсу. Клиент МОЖЕТ повторить запрос с подходящим полем заголовка авторизации (раздел 14.8).

а также

10.4.4 403 Запрещено Сервер понял запрос, но отказывается его выполнять. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться.

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

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

401 указывает, что ресурс не может быть предоставлен, но сервер ЗАПРОСИТ, что клиент входит в систему через HTTP-аутентификацию и отправил заголовки ответов, чтобы инициировать процесс. Возможно, есть разрешения, которые разрешают доступ к ресурсу, возможно, нет, но давайте попробуем и посмотрим, что произойдет.

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

Изменить: RFC2616 устарел, см. RFC7231 и RFC7235 .


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

401: Для этого вам требуется HTTP basic auth.

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

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

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

Это оставляет 403 как «вам нужно войти в систему».

Другими словами, 403 означает, что «этот ресурс требует некоторой формы auth, кроме HTTP basic auth».

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


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

В разделе 6.5.3 этого проекта (автор Fielding и Reschke) код статуса 403 имеет несколько иной смысл, чем документ, документированный в RFC 2616 .

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

Я подчеркнул, что я думаю, что это наиболее важно.

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

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

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

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

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


Ясное объяснение Даниэля Ирвина :

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

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

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

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

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

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

Еще один приятный иллюстрированный формат использования кодов статуса http.


   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, если ресурс не существует

UNAUTHORIZED : код состояния (401), указывающий, что запрос требует аутентификации , обычно это означает, что пользователь должен быть зарегистрирован (сеанс). Пользователь / агент неизвестен сервером. Может повторяться с другими учетными данными. ПРИМЕЧАНИЕ. Это запутывает, поскольку это должно было быть названо «unauthenticated» вместо «unauthorized». Это также может произойти после входа в систему, если сеанс истек.

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

NOT FOUND : код состояния (404), указывающий, что запрошенный ресурс недоступен. Известный пользователь / агент, но сервер ничего не сообщает об этом ресурсе, как будто его не существует. Повторение не будет работать. Это специальное использование 404 (например, github).





http-response-codes