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

Question

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

Answer 1

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

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

• Ресурс требует аутентификации, но нет учетных данных были указаны .

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

• Указанные учетные данные имеют недопустимый формат .

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

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

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

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

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

• Указанные учетные данные имеют срок действия истек .

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

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

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

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

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

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

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

Answer 2

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

401: вам нужна базовая аутентификация HTTP, чтобы увидеть это.

403: вы не можете видеть это, а базовая HTTPаутентификация не поможет.

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

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

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

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

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

Answer 3

Учитывая последние RFC по этому вопросу ( 7231 и 7235 ), сценарий использования выглядит вполне понятным (курсив добавлен):

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

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

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

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

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

403 Запрещено

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

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

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

Answer 4

В случае 401 против 403 на этот вопрос отвечали много раз. По сути, это дебаты «среды HTTP-запросов», а не «приложений».

Похоже, что возникает вопрос о проблеме «подкатить-под-своим-логином» (приложение).

В этом случае просто не войти в систему недостаточно для отправки 401 или 403, если только вы не используете HTTP Auth против страницы входа (не привязанной к настройке HTTP Auth). Похоже, вы ищете «201 Created», с присутствующим на экране экраном для входа в систему (вместо запрошенного ресурса) для доступа к файлу на уровне приложения. Это говорит:

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