403 Запрещенных против 401 Несанкционированных HTTP-ответов
https://stackoverflow.com/questions/3297048
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Для веб-страницы, которая существует, но для которой пользователь не имеет достаточных привилегий (он не вошел в систему или не принадлежит к соответствующей группе пользователей), каков правильный HTTP-ответ для обслуживания?
401 Unauthorized?
403 Forbidden?
Что-то еще?
То, что я прочитал о каждом из них до сих пор, не очень ясно показывает разницу между ними.Какие варианты использования подходят для каждого ответа?
Решение
Ясное объяснение от Даниэль Ирвин :
Есть проблема с 401 несанкционированным , код состояния HTTP для ошибок аутентификации. И это всего лишь: это для аутентификации, а не разрешения. Получение ответа 401 - это сервер, рассказывающий вам: «Вы не аутентифицирован - либо не аутентифицирован вообще или аутентифицирован неправильно - но, но, пожалуйста, погрузитесь и попробуйте снова ». Чтобы помочь вам, Он всегда будет включать в себя WWW-аутентифицировать заголовок , который описывает, как аутентифицировать.
Это ответ, обычно возвращенный вашим веб-сервером, а не в сети Приложение.
Это также что-то очень временно; Сервер просит вас попробовать снова.
Так, для авторизации я использую the em> 403 запрещенного ответа . Его постоянный, он связан с моей прикладной логикой, и это более бетон ответ, чем 401.
Получение ответа 403 - это сервер, который говорит вам: «Извините. я знаю кто ты - я верю, кто вы говорите, вы, но у вас просто нет разрешение на доступ к этому ресурсу. Может быть, если вы спросите систему Администратор красиво, вы получите разрешение. Но, пожалуйста, не беспокойтесь Меня снова, пока ваши преобразования не меняются. "
Таким образом, A 401 неавторизованный ответ должен использоваться для отсутствия или плохая аутентификация, а a 403 запрещено реагированием после этого, когда пользователь аутентифицирован, но не авторизован выполнить запрошенную операцию на данном ресурсе.
Еще один Хороший живописный формат о том, как коды состояния HTTP должны быть используется.
Другие советы
См. см. rfc2616 :
401 Несанкционировано:
Если запрос уже включал учетные данные авторизации, то ответ на 401 указывает на то, что разрешение было отказано для этих учетных данных.
403 Запрещено:
Сервер понял запрос, но отказывается от его выполнения.
<Сильное> Обновление
Из вашего корпуса использования, кажется, пользователь не аутентифицирован.Я бы вернул 401.
Редактировать: RFC2616 устарел, см.href="https://tools.ietf.org/html/rfc7231#section-6.5.5. rel=" noreferrer "> RFC7231 и RFC7235 .
Чего не хватает в других ответах, так это того, что необходимо понимать, что аутентификация и авторизация в контексте RFC 2616 относятся ТОЛЬКО к протоколу HTTP аутентификации RFC 2617.Аутентификация по схемам, отличным от RFC2617, не поддерживается в кодах состояния HTTP и не учитывается при принятии решения об использовании 401 или 403.
Краткий и немногословный
Неавторизованный указывает, что клиент не прошел проверку подлинности по 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.
+-----------------------
| RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
+-----------------------
| |
NO | v YES
v +-----------------------
404 | IS LOGGED-IN ? (authenticated, aka has session or JWT cookie)
or +-----------------------
401 | |
403 NO | | YES
3xx v v
401 +-----------------------
(404 no reveal) | CAN ACCESS RESOURCE ? (permission, authorized, ...)
or +-----------------------
redirect | |
to login NO | | YES
| |
v v
403 OK 200, redirect, ...
(or 404: no reveal)
(or 404: resource does not exist if private)
(or 3xx: redirection)
.
Проверки обычно делаются в этом порядке:
- .
- 404, если ресурс публично и не существует или не существует или 3xx перенаправление
- иначе:
- 401 Если не вошедший в систему или сеанс истек срок действия
- 403 Если пользователь не имеет разрешения на доступ к ресурсу (файл, json, ...)
- 404, если ресурс не существует или не желает ничего раскрывать, или 3xx перенаправление
Как упомянуто @chrish. Есть несколько вариантов для
Согласно RFC 2616 (http / 1.1) 403 отправляется, когда:
Другими словамиСервер понял запрос, но отказывается отдать его.Авторизация не поможет, и запрос не должен повторяться.Если метод запроса не был головой, и сервер желает публиковать, почему запрос не был выполнен, он должен описывать причину отказа в организации.Если сервер не хочет сделать эту информацию для клиента, код состояния 404 (не найден) может использоваться вместо этого
, если клиент может получить доступ к ресурсу путем аутентификации, 401 следует отправлять.
403 Запрещено используется при доступе к ресурсу запрещено каждому или ограничено данной сети или разрешено только через SSL, что угодно, что не связано с аутентификацией HTTP.
Если аутентификация HTTP не используется и сервис схема аутентификации на основе файла cookie как нора в настоящее время, то не должна возвращаться 403 или 404.
Относительно 401, это от RFC 7235 (протокол гипертекстового переноса (HTTP / 1.1): аутентификация):
3.1. 401 неавторизован
401 (неавторизованный) код состояния указывает, что запрос имеет не применяется, потому что ему не хватает действительных учетных данных аутентификации для целевого ресурса. Сервер происхождения должен отправить Поле заголовка WWW-аутентификации (раздел 4.4), содержащее хотя бы один Вызов, применимая к целевому ресурсу. Если запрос Включены учетные данные аутентификации, затем отклик 401 указывает на то, что разрешение было отказано для тех учетные данные . Клиент может повторить запрос с новым или Заменил поле заголовка авторизации (раздел 4.1). Если 401. ответ содержит тот же вызов, что и предыдущий ответ, а также пользовательский агент уже попытался аутентификацию хотя бы один раз, затем Агент пользователя должен представить прилагаемое представление Пользователь, поскольку он обычно содержит соответствующую диагностическую информацию.
семантика 403 (и 404) изменилась со временем. Это с 1999 года (RFC 2616):
10.4.4 403 Запрещено
Сервер понял запрос, но отказывается от его выполнения.
и запрос не должен повторяться.
<Сильные> Авторизация не поможет
Если метод запроса не был головой, и сервер желает сделать
публично, почему запрос не был выполнен, он должен описать Причина отказа в организации. Если сервер не хочет Сделайте эту информацию доступной для клиента, код состояния 404
(Не найден) можно использовать вместо этого.
В 2014 году RFC 7231 (протокол передачи гипертекста (HTTP / 1.1): семантика и контент) изменили значение 403:
6.5.3. 403 запрещено
403 (запрещен) код состояния указывает, что сервер Понял запрос, но отказывается разрешать его. Сервер этому желает публиковать, почему запрос был запрещен, может Опишите эту причину в полезной нагрузке отклика (если таковые имеются).
Если учетные данные аутентификации были предоставлены в запросе,
Сервер считает их недостаточными для предоставления доступа. Клиент
Не должен автоматически повторять запрос с тем же
реквизиты для входа. Клиент может повторить запрос с новыми или другими реквизиты для входа. Тем не менее, запрос может быть запрещен по причинам не связано с учетными данными.Сервер происхождения, который желает «скрыть» текущее существование
Запретный целевой ресурс может вместо этого ответить с кодом состояния
404 (не найден).
Таким образом, 403 (или 404) теперь может означать о чем-либо. Предоставление новых учетных данных может помочь ... или это не может.
Я считаю, что это изменилось, это изменилось, это RFC 2616, предполагаемая http-аутентификация http будет использоваться, когда на практике сегодняшние веб-приложения будут построить пользовательские схемы аутентификации, используя например формы и файлы cookie.
- .
- 401 несанкционировано : я не знаю, кто ты есть. это ошибка аутентификации.
- 403 запрещено : Я знаю, кто вы есть, но у вас нет разрешения на доступ к этому ресурсу. Это ошибка авторизации.
Это старый вопрос, но один вариант, который никогда не был воспитан, должен был вернуть 404. С точки зрения безопасности, самый высокий голосованный ответ страдает от потенциала Уязвимость утечки информации .Например, скажите, что в вопросе защищенной веб-страницы является страницей администратора системы, или, возможно, более широко, является записью в системе, к которой пользователь не имеет доступа.В идеале вы бы не хотели бы, чтобы злонамеренный пользователь даже знал, что там есть страница / запись, не говоря уже о том, что у них нет доступа.Когда я строю что-то вроде этого, я постараюсь записывать неаутентичные / несанкционированные запросы во внутреннем журнале, но верните 404.
owasp есть некоторые Дополнительная информация О том, как атакующий может использовать этот типинформации как часть атаки.
Этот вопрос был задан некоторое время назад, но мышление людей движется дальше.
Раздел 6.5.3 В этом проекте (автор поставки поля и Reschke) дает код состояния 403 немного другого значения, документированного в RFC 2616 .
Это отражает то, что происходит в схем аутентификации и авторизации, используемых несколькими популярными веб-серверами и каркасами.
Я подчеркнул, что я думаю, что является наиболее важным.
6.5.3. 403 запрещено
403 (Запретный) код состояния Указывает, что сервер понял запрос, но отказывается от его разрешения. Сервер, который желает обнаружил, почему запрос был запрещен, может описать эту причину в полезной нагрузке на ответ (если таковые имеются).
Если учетные данные аутентификации были предоставлены в запросе, сервер рассматривает их недостаточно для предоставления доступа. клиент не должен повторять запрос с теми же учетными данными. Клиент может повторить запрос с новыми или разными учетными данными. Однако запрос может быть запрещен по причинам, не связанным с учетными данными.
Сервер происхождения, который желает «скрыть» текущее существование запрещенного целевого ресурса, может вместо этого отвечать с помощью кода состояния 404 (не найден).
Какая бы ни была, как вы используете конвенцию, важная вещь - обеспечить однородность на вашем сайте / API.
TL; DR
- .
- 401: отказ, который связан с аутентификацией
- 403: отказ, который не имеет ничего общего с аутентификацией
Практические примеры
Если apache требует аутентификации (через .htaccess), а вы попали в Cancel, он ответит на 401 Authorization Required
Если nginx находит файл, но не имеет права доступа (user / group) для чтения / доступа, он ответит с помощью 403 Forbidden
RFC (2616 раздел 10)
401 Несанкционировано (10.4.2)
Значение 1:
Запрос требует аутентификации пользователя. ...
Значение 2: <Сильная> Аутентификация Недостаточно
... Если запрос уже включал учетные данные авторизации, то ответ на 401 указывает на то, что разрешение было отказано для этих учетных данных. ...
403 Запрещено (10.4.4)
Значение:
... Авторизация не поможет ...
Подробнее:
- .
-
Сервер понял запрос, но отказывается от его выполнения.
-
Следует описать причину отказа в объекте
-
код состояния 404 (не найден) может использоваться вместо этого
(если сервер хочет сохранить эту информацию от клиента)
Они не вошли в систему или не принадлежат к соответствующей группе пользователей
Вы заявили два разных случая; Каждый случай должен иметь другой ответ:
- Если они не вошли вообще вообще, вы должны вернуться 401 несанкционированные
- Если они вошли в систему, но не принадлежат к соответствующей группе пользователей, вы должны вернуться
403 Запрещено
Примечание на RFC на основе комментариев, полученных на этот ответ:
Если пользователь не вошел в систему, они не аутентифицированы, HTTP-эквивалент которого составляет 401 и вводится в заблуждение, называется несанкционированным в RFC. Как Раздел 10.4.2 Штаты для
"запрос требует пользователя аутентификации ."
Если вам неактуально, 401 - это правильный ответ. Однако, если вы неавторизованы, в семантически правильном смысле 403 - это правильный ответ.
на английском языке:
401
Вы потенциально разрешаете доступом, но по какой-то причине по этому запросу вы были отклонен.Такие как плохой пароль?Попробуйте еще раз, с правильным запросом Вместо этого вы получите ответ успеха.
Вы не допускаются.Ваше имя не в списке, вы не будете когда-либо войти, уходи, не отправляйте запрос повторной попытки, он будет отказано, всегда.Уйти.
Это значения:
Это проще в моей голове, чем где угодно, так что:
401: Вам нужен основной Auth Auth, чтобы увидеть это.
403: Вы не можете видеть это, и HTTP Basic Auth не поможет.
Если пользователю просто нужно войти в систему, используя стандартную форму входа в систему вашего сайта HTML, 401 не подходит, потому что он специфичен для HTTP Basic Auth.
Я не рекомендую использовать 403, чтобы отрицать доступ к вещам, такими как /includes, потому что, поскольку в Интернете связаны, эти ресурсы вообще не существуют и поэтому 404.
Это листья 403 как «вы должны войти в систему».
Другими словами, 403 означает «этот ресурс требует некоторой формы аутентификации, кроме HTTP Basic Auth».
https://www.w3.org/protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
Я думаю, важно учитывать, что для браузера 401 инициирует диалоговое окно аутентификации для пользователя для ввода новых учетных данных, в то время как 403 этого не делает.Браузеры считают, что если возвращается значение 401, то пользователь должен пройти повторную аутентификацию.Таким образом, 401 означает недопустимую аутентификацию, в то время как 403 означает отсутствие разрешения.
Вот несколько случаев в рамках этой логики, когда при проверке подлинности или авторизации будет возвращена ошибка, причем важные фразы выделены жирным шрифтом.
- Ресурс требует аутентификации, но нет учетных данных были указанный.
401:Клиент должен указать учетные данные.
- Указанные учетные данные находятся в недопустимый формат.
400:Это ни 401, ни 403, поскольку синтаксические ошибки всегда должны возвращать значение 400.
- Указанные учетные данные ссылаются на пользователь который не существует.
401:Клиент должен указать действительные учетные данные.
- Указанный учетные данные являются недействительный но укажите действительного пользователя (или не указывайте пользователя, если указанный пользователь не требуется).
401:Опять же, клиент должен указать действительные учетные данные.
- Указанный учетные данные иметь истек срок действия.
401:Это практически то же самое, что иметь недействительные учетные данные в целом, поэтому клиент должен указать действительные учетные данные.
- Указанные учетные данные полностью действительны, но не достаточно конкретный ресурс, хотя возможно, что учетные данные с большим разрешением могли бы.
403:Указание действительных учетных данных не предоставит доступ к ресурсу, поскольку текущие учетные данные уже действительны, но только не имеют разрешения.
- Конкретный ресурс является недоступный независимо от учетных данных.
403:Это не зависит от учетных данных, поэтому указание действительных учетных данных не может помочь.
- Указанные учетные данные полностью действительны, но конкретный клиент является заблокирован от их использования.
403:Если клиент заблокирован, указание новых учетных данных ничего не даст.
Given the latest RFC's on the matter (7231 and 7235) the use-case seems quite clear (italics added):
- 401 is for unauthenticated ("lacks valid authentication"); i.e. 'I don't know who you are, or I don't trust you are who you say you are.'
401 Unauthorized
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
- 403 is for unauthorized ("refuses to authorize"); i.e. 'I know who you are, but you don't have permission to access this resource.'
403 Forbidden
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
In the case of 401 vs 403, this has been answered many times. This is essentially a 'HTTP request environment' debate, not an 'application' debate.
There seems to be a question on the roll-your-own-login issue (application).
In this case, simply not being logged in is not sufficient to send a 401 or a 403, unless you use HTTP Auth vs a login page (not tied to setting HTTP Auth). It sounds like you may be looking for a "201 Created", with a roll-your-own-login screen present (instead of the requested resource) for the application-level access to a file. This says:
"I heard you, it's here, but try this instead (you are not allowed to see it)"
