Можно ли считать допустимой ошибку 401 в HTTP:// или HTTPS://? — Общие темы ИТ — Кулер для воды

Это обсуждение заблокировано.

Вы больше не можете публиковать новые ответы в этом обсуждении. Если у вас есть вопрос, вы можете начать новую дискуссию

Я создаю мониторы URL-адресов для клиента как для HTTP://, так и для HTTPS:// с учетными данными, которых нет на сервере, поэтому, конечно, они не работают с сообщением «Удаленный сервер вернул ошибку: (401 ) Несанкционированный» ошибка. Клиент говорит, что он может назначить только один экземпляр конкретному пользователю в файлах конфигурации Servlet Exec. Их точка зрения заключалась в том, что если они получают ошибку 401, это означает, что сервер отвечает, отклоняя учетные данные, указанные в мониторе. Так является ли «401» ошибкой, жестко закодированной в мониторах компонентов для HTTP:// или HTTPS://? Я вижу «Игнорировать ошибки CA» и «Игнорировать ошибки CN», но не уверен, что они относятся к 401.

Спасибо,

Стив Б.

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

  Спасибо,

  Джереми

• Вы поняли это? У меня такая же проблема.

• посмотри этот сбаргер‌ https://support.microsoft.com/en-us/kb/0

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

• 8570000Z» data-yesvotes=»0″ data-novotes=»0″ data-url=»https://thwack.solarwinds.com/water-cooler/f/general-it-topics/24888/can-401-errors-in-http-or-https-be-considered-valid/181347#181347″>

  Прочтите эту тему:

  Монитор HTTP — 503 является UP

  http://orion/Orion/External.aspx?Title=thwack&URL=http://thwack.com/orion/default.aspx

• Спасибо за это, но PowerShell работает, так как узел является NetScaler

• 
  Тогда единственное, что я могу придумать, это запустить тест на промежуточной машине. .. я не знаю, можно ли вообще это сделать. Например, у меня было требование сделать количество файлов и каталогов, но каталог был в NetApp… я не могу получить доступ к NetApp, это не очень удобно. (Даже OCI не может этого сделать.) Итак, я взял компьютер с Linux, смонтировал диск, а затем запустил скрипт на промежуточной машине для подсчета каталогов и файлов.

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

• Такая же ситуация.

  Вместо этого используется монитор TCP-порта 443, но это действительно недопустимая замена. (Невозможно отслеживать конкретный URL-адрес — отслеживаются только IP-адреса и имена хостов, и даже тогда только статические. )

• Решение, которое я придумал (в процессе), заключается в использовании монитора Windows PowerShell для этих сайтов. Я опубликую больше, когда закончу, но пока это монитор PowerShell со следующей строкой:

  Try {Invoke-WebRequest -Uri https:// URL -ErrorAction Stop} Catch {Write-Host ‘Statistic.Response: ‘ $_.Exception.Message.Substring(($_.Exception. Message.IndexOf(‘(‘)+1),3)}

  В результате получается не что иное, как номер кода ответа HTTP. Единственное, что я не могу понять, это как передать переменную имени узла или другую соответствующую переменную вплоть до самого скрипта

• 5900000Z» data-yesvotes=»1″ data-novotes=»0″ data-url=»https://thwack.solarwinds.com/water-cooler/f/general-it-topics/24888/can-401-errors-in-http-or-https-be-considered-valid/105546#105546″>

  Я создал шаблон мониторинга HTTP на основе PowerShell, который решает эту проблему! Шаблон и описание размещены в обмене контентом.

401 Неавторизованный — объяснение кода состояния HTTP

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

СОДЕРЖАНИЕ

• ИСПОЛЬЗОВАНИЕ
• Пример
• Ссылки на код
• TAKEAWAY
• См. Также

Использование

, когда можно было получить. предоставляется до предоставления доступа к запрошенному ресурсу. Возможно, клиенту необходимо сначала войти в систему или предоставить учетные данные как часть HTTP-запроса. Также может случиться так, что учетные данные для входа недействительны. Важно отличать это от 403 Forbidden, которое информирует клиента о том, что действие не разрешено.

Когда сервер отправляет ответ 401 Unauthorized , он должен включать заголовок ответа WWW-Authenticate. Это информирует клиента о том, какие методы авторизации он разрешает. В IANA есть список стандартных схем аутентификации, различающихся как безопасностью, так и популярностью. Спецификации распространенных схем аутентификации можно найти по следующим ссылкам:

• Базовая

  Этот тип аутентификации представляет собой передачу учетных данных и пар ID/Пароль RFC 7617.

• Носитель

  Эта аутентификация, также известная как аутентификация с помощью маркера, основана на маркерах безопасности, которые генерируются сервером и возвращаются клиенту после успешного входа в систему. Клиент несет ответственность за отправку этих токенов при любой последующей попытке доступа к защищенным ресурсам RFC 6750.

• Digest

  Аутентификация доступа HTTP Digest — это протокол типа запрос-ответ, который можно использовать для аутентификации запросов ресурсов RFC 7616.

• HOBA

  Сокращенно от HTTP Origin-Bound Authentication — это схема, которая не требует от сервера ведения списка сохраненных паролей и, таким образом, неуязвима для фишинговых атак RFC 7486.

Взаимная

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

• AWS4-HMAC-SHA256

  Это алгоритм аутентификации, предназначенный для предоставления информации об аутентификации в Справочник по API Amazon Web Services AWS S3.

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

Примечание

Поисковые системы, такие как Google, не будут индексировать URL с 401 Неавторизованный статус ответа и, следовательно, URL-адреса, которые были проиндексированы в прошлом, но теперь возвращают этот код состояния HTTP, будут удалены из результатов поиска.

Пример

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

Первоначальный запрос

 GET /documents/tech-news HTTP/1.1
Хост: www.example.ai
 

Первоначальный ответ

 HTTP/1.1 401 Неавторизованный
WWW-аутентификация: базовая; realm="Документы"
WWW-аутентификация: взаимная
 

 GET /documents/tech-news HTTP/1.1
Хост: www.example.ai
Авторизация: Basic RXhhbXBsZTphaQ==
 

 HTTP/1.1 200 ОК
Тип содержимого: приложение/pdf
Длина контента: 25000

 

 HttpStatusCode.Unauthorized
 

 http::StatusCode::UNAUTHORIZED
 

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

 http.StatusUnauthorized
 

 Ответ::HTTP_UNAUTHORIZED
 

 http.HTTPStatus.UNAUTHORIZED
 

 java.net.HttpURLConnection.HTTP_UNAUTHORIZED
 

 org.apache.hc.core5.http.HttpStatus.SC_UNAUTHORIZED
 

 @angular/common/http/HttpStatusCode.Unauthorized