Для веб-страницы, которая существует, но для которой пользователь не имеет достаточных привилегий (он не вошел в систему или не принадлежит к соответствующей группе пользователей), какой ответ HTTP должен быть предоставлен? 401? 403? Что-то еще? То, что я прочитал о каждом из них, пока что не очень ясно показывает разницу между ними. Какие случаи использования подходят для каждого ответа?
Четкое объяснение от Дэниела Ирвина:
Существует проблема с 401 Unauthorized, кодом статуса HTTP для ошибок аутентификации. И в этом все дело: он предназначен для аутентификации, а не для авторизации. Получение ответа 401 означает, что сервер говорит вам: "Вы не авторизованы". аутентифицированы - либо не аутентифицированы вообще, либо аутентифицированы неправильно, но, пожалуйста, пройдите повторную аутентификацию и попробуйте снова". Чтобы помочь вам, он всегда будет включать заголовок WWW-Authenticate, который описывает, как пройти аутентификацию.
Этот ответ обычно возвращается веб-сервером, а не веб-приложением. приложение.
Это также что-то очень временное; сервер просит вас попробовать еще раз.
Итак, для авторизации я использую ответ 403 Forbidden. Это постоянный, он привязан к логике моего приложения, и это более конкретный ответ, чем 401.
Получение ответа 403 означает, что сервер говорит вам: "Мне жаль. Я знаю. кто вы такой - я верю в то, за кого вы себя выдаете, но у вас просто нет разрешения на доступ к этому ресурсу. Возможно, если вы попросите системного администратора вежливо, вы получите разрешение. Но, пожалуйста, не беспокойте меня снова, пока ваше положение не изменится".
В целом, ответ 401 Unauthorized следует использовать для отсутствующей или плохой аутентификации, а ответ 403 Forbidden должен использоваться после этого, когда пользователь аутентифицирован, но не имеет права выполнить запрошенную операцию на данном ресурсе.
Еще один красивый наглядный формат того, как следует использовать коды состояния http.
См. RFC2616:
401 Unauthorized:
Если запрос уже содержал полномочия авторизации, то ответ 401 указывает, что авторизация для этих полномочий была отклонена.
403 Forbidden:
Сервер понял запрос, но отказывается его выполнять.
Обновление
Из вашего примера следует, что пользователь не прошел аутентификацию. Я бы вернул 401.
Редактирование: RFC2616 устарел, смотрите RFC7231 и RFC7235.
Что-то других ответов не хватает, что он должен понимать, что аутентификация и авторизация в контексте документе RFC 2616 относится только к протокол HTTP-аутентификация в RFC 2617. Аутентификация по схемам вне документе rfc2617 не поддерживается в коды состояния HTTP и не учитываются при принятии решения об использовании 401 или 403.
Несанкционированного указывает, что клиент не аутентифицирован в документе rfc2617 и сервер инициирует процесс проверки подлинности. Запрещено свидетельствует либо о том, что клиент в документе rfc2617 проверку подлинности и не имеет разрешения или что сервер не поддерживает документе rfc2617 для запрошенного ресурса.
То есть, если у вас есть свой собственный ролл ваш собственный процесс входа в систему и не использовать HTTP-аутентификации, 403-это всегда правильный ответ 401 и никогда не должны использоваться.
Из адресу rfc2616
10.4.2 401 несанкционированного
запрос требует проверки подлинности пользователя. Ответ должен содержать веб-проверки подлинности заголовка (раздел 14.47), содержащий вызов, применимый к запрошенному ресурсу. Клиент может повторить запрос с подходящим полем заголовка Authorization (раздел 14.8).
и
10.4.4 403 запрещено сервер понял запрос, но отказывается выполнять его. Авторизация не поможет, и запрос не должен быть повторен.
Первое, что нужно иметь в виду, что "подлинности" и "авторизации" в контексте данного документа относятся к протоколам проверки подлинности http из RFC 2617. Они не относятся к любой крен-ваш-собственные протоколы проверки подлинности, которые могли быть созданы с помощью страницы входа и т. д. Я буду использовать на "логин", чтобы обратиться к аутентификации и авторизации иными методами, чем в документе rfc2617
Так что реальная разница не в чем проблема и есть ли решение. Разница в том что сервер ожидает клиента делать дальше.
401 указывает, что ресурс не может быть предоставлен, но сервер просит авторизации клиентов через HTTP-аутентификации и послал заголовки ответа для начала процесса. Возможно, есть разрешения, что позволит получить доступ к ресурсу, возможно, нет, но позвольте's дайте ему попробовать и посмотреть, что происходит.
403 указывает, что ресурс не может быть предоставлен и есть, для текущего пользователя, не могу решить это путем документе rfc2617 и никакого смысла в попытке. Это может быть потому, что известно, что не уровень проверки является достаточным (например, ИС черного списка), но это может быть потому, что пользователь уже прошел проверку подлинности и не имеет полномочий. В документе rfc2617 модели-пользователей, в одну учетные данные на случай, когда пользователь может иметь второй набор учетных данных, которые могут быть разрешены могут быть проигнорированы. Он не предполагает и не подразумевает, что какую-то страницу входа или других лиц-в документе rfc2617 протокола проверки может или не может помочь - вне стандартов rfc2616 и определения.
Edit: адресу rfc2616 является устаревшим, см. RFC7231 и RFC7235.
в <предварительно> Ресурс существует ? (если частная это часто Проверено после того, как двиг проверить) | | НЕТ | | ДА В. В. 404 вошел в систему ? (с проверкой подлинности, ака сессия) или | | 401 НЕТ | | ДА 403 | | В. В. 401 может получить доступ к ресурсу ? (разрешение, право) ? (404 не раскрыть) | | или 301 нет | | да перенаправление | | для входа в в 403 ОК 200, 301, ... (или 404: не раскрыть)
</пред>
Проверки, как правило, осуществляется в таком порядке:
Несанкционированный: код состояния (401), указывающий, что запрос требует аутентификация, обычно это означает, что пользователь должен быть зарегистрированным (сессии). Пользователь/агент неизвестным сервером. Можно повторить с другими учетными данными. Примечание: это сбивает с толку, так как это нужно было назвать 'подлинности' вместо 'несанкционированного'. Это также может произойти после входа, если сессия истекла. Особый случай: можно использовать вместо 404, чтобы избежать выявления присутствия или отсутствия-наличия ресурсов (кредиты @gingerCodeNinja)
Запрещено: код состояния (403), указывающий на сервер понял запрос, но отказался его выполнять. Пользователя/агента, известных серверу, но недостаточными полномочиями. Повторяю запрос не будет работать, если данные изменились, что очень маловероятно за короткий промежуток времени. Особый случай: можно использовать вместо 404, чтобы избежать выявления присутствия или отсутствия-наличия ресурсов (кредиты @gingerCodeNinja)
Не нашла: код состояния (404), указывая, что запрашиваемый ресурс не доступен. Пользователь/агент известен, но сервер не откроет что-нибудь о ресурсе, вообще как будто его не существует. Повторения не будет работать. Это специальное использование 404 (гитхаб это к примеру).
Согласно RFC 2616(http/1.1) 403 отправляется, когда:
Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не HEAD и сервер желает сообщить, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в сущности. Если сервер не хочет предоставлять эту информацию клиенту, вместо нее можно использовать код состояния 404 (Not Found).
Другими словами, если клиент МОЖЕТ получить доступ к ресурсу путем аутентификации, следует отправить 401.
При проверке подлинности http (ВСП-аутентификации и авторизации заголовки) используется, при проверке подлинности другого пользователя предоставить доступ к запрошенному ресурсу, то 401 несанкционированный должны быть возвращены.
403 запрещено используется, когда доступ к ресурсу запрещен всем или только определенной сети или допускается только по протоколу SSL, что пока это не связано с проверкой подлинности http.
Если HTTP-аутентификация не используется и служба печенье-схемы проверки подлинности на основе, как это сегодня норма, то 403 или 404 должна быть возвращена.
Что касается 401, это из RFC 7235 (протокол передачи гипертекста (HTTP/1.1): проверка подлинности):
3.1. 401 несанкционированного
и GT; 401 (несанкционированный) код состояния указывает, что запрос не применялись, поскольку в ней отсутствуют действительные учетные данные для проверки подлинности для целевого ресурса. Исходный сервер должен отправить веб-проверки подлинности заголовка (раздел 4.4), содержащий по меньшей мере один задачи, применимые к целевой ресурс. Если запрос включены учетные данные для проверки подлинности, то ответ 401 указывает, что авторизация была отклонена для тех учетными данными. Клиент может повторить запрос с новой или заменено полем заголовка Authorization (раздел 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, будет использоваться, когда на практике сегодня'веб-приложения с построения собственных схем проверки подлинности, используя, например, формы и печенье.
Это старый вопрос, но один вариант, который никогда не был воспитан, чтобы возвращать 404. С точки зрения безопасности, самый высокий проголосовали ответ, страдает от потенциального сведения об уязвимости утечки. Скажем, например, что защищенные веб-страницы в страницу администрирования системы, или, возможно более обычно, запись в системе, которые пользователь не'т иметь доступ к данным. В идеале вы бы'т хотим, чтобы злонамеренный пользователь может даже не знать, что там'ы страница / запись есть, а уж что они Дон'т иметь доступ. Когда я'м дома что-то вроде этого, я'постараюсь записать unauthenticate / несанкционированных запросов в внутренний журнал, но возвращает 404.
Список OWASP имеет некоторые дополнительная информация о том, как злоумышленник может использовать данную информацию в качестве части нападения.
Этот вопрос был задан некоторое время назад, но люди'ы мышление движется дальше.
Раздел 6.5.3 в этот проект (автор Филдинг и Решке) дает код состояния 403 немного другой смысл описанным в в RFC 2616.
Она отражает то, что происходит в аутентификации & схемы авторизации трудился на различных популярных веб-серверов и фреймворков.
Я'вэ подчеркнули бит, я думаю, является наиболее важным.
6.5.3. 403 запрещено
в 403 (запрещено) код статуса означает, что сервер понял запрос, но отказывается авторизовать его. Сервер, который хочет сделать обществу, почему запрос был запрещен могу описать, что причина в содержимое ответа (если таковые имеются).
если учетные данные были предоставлены в запрос, сервер считает их недостаточными для предоставления доступа. Клиент не должен повторять запрос с теми же учетными данными. Клиент может повторить запрос с новыми или другими учетными данными. Однако запрос может быть запрещено по причинам, не связанным с учетными данными.
сервера-источника, что желает, чтобы "спрятать" в нынешнее существование запрещенной целевой ресурс может Вместо ответа с кодом состояния 404 (не найдено).
Независимо от конвенции, которую вы используете, главное-обеспечить равномерность на ваш сайт / API-интерфейса.
Если Апач требует проверки подлинности (через .откройте файл. htaccess
), и вы нажмете "отмена", он будет отвечать с 401 требуется авторизация
Если nginx в находит файл, но не имеет права доступа (пользователь/группа) для чтения/доступа к нему, он ответит 403 запрещено
Смысл 1: необходимости проверки подлинности
запрос требует проверки подлинности пользователя. ...
Смысл 2: Проверка подлинности недостаточны
... если запрос уже включены учетные данные для авторизации, то ответ 401 указывает, что авторизация была отклонена на этих полномочий. ...
Смысл: , не связанных с проверкой подлинности
... авторизация не поможет ...
Подробнее:
сервер понял запрос, но отказывается выполнять его.
Это следует описать причину отказа в объекте
код состояния 404 (не найдено) может использоваться вместо этого
(Если сервер хочет держать эту информацию от клиента)
они не вошли в систему или не принадлежат соответствующей группе пользователей
Вы указали два разных случая, каждый случай должен иметь другой ответ:
Обратите внимание на сервер, на основе замечаний, полученных в ответ:
Если пользователь не вошел в систему, он не-подлинности по протоколу HTTP эквивалентом которого является 401 и вводящее в заблуждение название несанкционированных в RFC. Как раздел 10.4.2 государств за 401 несанкционированного:
"по желанию требует пользователей аутентификация.&и"
Если вы'повторно не прошедший проверку подлинности, 401 правильный ответ. Однако, если вы'повторного несанкционированного, в семантически правильном смысле, 403 правильный ответ.
401: я Дон'т знаю, кто вы. Эта ошибка проверки подлинности. 403: я знаю, кто ты. Но вы не'т иметь разрешение на доступ к этому ресурсу. Это ошибка авторизации.
Это проще в моей голове, чем здесь, поэтому:
401: необходимо по HTTP basic авторизации, чтобы увидеть это.
403: вы можете'т вижу это, и HTTP basic авторизации выиграл'т помочь.
Если пользователь просто должен войти в систему с помощью вашего сайта's стандартный форма входа в формате HTML, 401, было бы нецелесообразно, поскольку она относится к базовой аутентификации http.
Я не'т рекомендуем использовать 403 запрет доступа к вещи, как включает
, потому что касается интернета, эти ресурсы Дон'т существуют вообще и, следовательно, 404.
Это оставляет 403 как "Вы должны войти в".
Другими словами, 403 означает "этот ресурс требует определенной формы авторизации, отличный от HTTP basic авторизации и".
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: если клиент заблокирован, с указанием новых учетных данных не будет ничего делать.
Учитывая последний документ RFC's на этот вопрос (7231 и 7235) использовать-дело, кажется, вполне ясен (Курсив мой):
401 несанкционированного
и GT; 401 (несанкционированный) код состояния указывает, что запрос не применяется, потому что он не действует аутентификации учетные данные для целевой ресурс. Сервер генерирует ответ 401 необходимо отправить веб-проверки подлинности заголовка (раздел 4.1), содержащий по меньшей мере один вызов применимые к целевой ресурс.
если запрос включен учетные данные для проверки подлинности, то 401 ответ указывает на то, что авторизация была отклонена для тех учетные данные. Агент пользователя может повторить запрос с новой или заменил поле заголовка Authorization (раздел 4.2). Если 401 ответ содержится в той же проблемой, что и в предыдущем ответе, и агент пользователя уже предпринималась попытка проверки подлинности по крайней мере один раз, затем агент пользователя должен представить заключенный представление пользователей, поскольку она обычно содержит соответствующую диагностическую информацию.
403 запрещено
в 403 (запрещено) код статуса означает, что сервер понял просьбу а отказывается авторизовать его. Сервер, который желает обнародовать, почему запрос был запрещен могу описать, что причина в содержимое ответа (если таковые имеются).
если учетные данные были предоставлены в заявке, сервер считает их недостаточными для предоставления доступа. Клиент Не должно автоматически повторить запрос с теми же учетные данные. Клиент может повторить запрос с новой или другой учетные данные. Однако запрос может быть запрещено по причинам не связанных с учетными данными.
происхождение сервере, который желает, чтобы "спрятаться" в нынешнем существовании вместо запрещенного целевой ресурс может ответить кодом состояния 404 (Не Найдено).
В случае 401 против 403, это уже отвечали много раз. По сути, это 'HTTP-запроса окружающей среды' дискуссии, не 'применение' дискуссии.
Там, кажется, вопрос на самокрутки-логин выпуска (приложение).
В данном случае, просто не вошли в не достаточно, чтобы отправить 401 или 403, если вы используете HTTP аутентификации против страницу входа в систему (не связана с настройкой HTTP аутентификации). Это звучит, как вы может быть ищете "в 201 создан" В, С самокрутки-экран для входа в настоящее время (вместо запрошенных ресурсов) для применения на уровне доступа к файлу. Это говорит:
"Я слышал, что вы, это's здесь, но попробуйте вместо этого (вы не позволили увидеть его) и"