Https dostup website: Плагин для Google Chrome

Содержание

Настройка HTTPS на ArcGIS Server при доступе через ArcGIS Web Adaptor—ArcGIS Enterprise

Когда ArcGIS Web Adaptor настроен на перенаправление запросов на сайт ArcGIS Server, необходимо включить HTTPS на веб-сервере, где находится ArcGIS Web Adaptor, и настроить HTTPS на сайте ArcGIS Server. Чтобы начать, выполните следующие шаги.

Создайте новый самозаверенный сертификат.
Отправьте запрос в центр сертификации на подпись сертификата.
Настройте ArcGIS Server на использование нового сертификата.
Настройте каждую машину в вашем развертывании.
Настройте доступ только через HTTPS для вашего сайта.
Настройте HTTPS на ArcGIS Web Adaptor.
Осуществите доступ к сайту при помощи HTTPS.

Создание нового самозаверенного сертификата

Войдите в ArcGIS Server Administrator Directory по адресу https://gisserver. domain.com:6443/arcgis/admin.
Перейдите в machines > [имя компьютера] > sslcertificates.
Щёлкните создать
Введите значения параметров на этой странице:
Щелкните Создать, чтобы сформировать сертификат.

Обращение в центр сертификации с запросом на подпись сертификата

Если ArcGIS Web Adaptor будет единственным шлюзом на ваш сайт, а политика IT-безопасности вашей организации разрешает использование самозаверенных сертификатов, вы можете пропустить этот раздел. Но если пользователи хотя бы иногда будут обходить ArcGIS Web Adaptor и подключаться непосредственно к ArcGIS Server, или в IT-политике не разрешено использование самозаверенных сертификатов, рекомендуется направить запрос в центр сертификации (CA) для подписания вашего сертификата, для чего необходимо выполнить следующие шаги.

Откройте самозаверенный сертификат, созданный вами в предыдущем разделе, и щелкните generateCSR. Скопируйте содержимое в файл (обычно с расширением CSR).
Отправьте CSR-файл в выбранный центр сертификации. Вы можете получить сертификаты с кодировкой Distinguished Encoding Rules (DER) или Base64. Если CA запрашивает тип веб-сервера, для которого готовится сертификат, укажите Other\Unknown или Java Application Server. После проверки вашей личности вам будет отправлен файл *.crt или *.cer.
Сохраните подписанный сертификат, полученный из центра сертификации, на компьютере. Помимо подписанного сертификата центр сертификации также издает корневой сертификат. Сохраните корневой сертификат на компьютере.
Выполните вход в ArcGIS Server Administrator Directory: https://gisserver.domain.com:6443/arcgis/admin.
Выберите machines > [имя компьютера] > sslcertificates > importRootOrIntermediate, чтобы импортировать корневой сертификат центра сертификации. Если центр сертификации издал дополнительные промежуточные сертификаты, импортируйте их тоже.
Перейдите в меню machines > [имя компьютера] > sslcertificates.
Выберите имя самозаверенного сертификата, направленного в центр сертификации.
Щелкните importSignedCertificate и перейдите к местоположению, где находится сохраненный подписанный сертификат, полученный из центра сертификации.
Щелкните Подтвердить. Он заменит самозаверенный сертификат, который вы создали ранее, на сертификат, подписанный центром сертификации.

Настройка ArcGIS Server на использование сертификата

Чтобы указать сертификат, который должен использоваться ArcGIS Server, выполните следующие действия:

Войдите в ArcGIS Server Administrator Directory по адресу https://gisserver.domain.com:6443/arcgis/admin.
Перейдите к компьютеры > [имя компьютера].
Выберите Редактировать.
Введите имя сертификата, который будет использоваться, в поле SSL-сертификат веб-сервера.
Нажмите кнопку Сохранить изменения, чтобы применить изменения. Сайт ArcGIS Server будет автоматически перезагружен.
После перезапуска сайта проверьте, что у вас имеется доступ к URL-адресу https://gisserver.domain.com:6443/arcgis/admin. Если вы не получаете ответа с этого URL-адреса, ArcGIS Server не может использовать указанный SSL-сертификат. Проверьте сертификат SSL и настройте ArcGIS Server на использование нового или другого сертификата.
На текущей странице проверьте значение свойства SSL-сертификат веб-сервера, где для HTTPS должен быть указан нужный SSL-сертификат.

Настройка каждой машины в вашем развертывании

Если в развертывании ArcGIS Server имеется несколько машин, необходимо настроить каждую из них на использование сертификата. Повторите шаги предыдущего раздела, чтобы настроить сертификат на каждой из машин ArcGIS Server.

Настройка доступа только через HTTPS для вашего сайта

Войдите в ArcGIS Server Administrator Directory по адресу https://gisserver. domain.com:6443/arcgis/admin.
Перейдите в меню security > config > update.
Установите параметр Протокол, выбрав опцию Только HTTPS, затем щелкните Обновить. ArcGIS Server будет перезапущен.
После перезапуска сервера проверьте, что ArcGIS Server доступен по URL-адресу HTTPS, например, https://gisserver.domain.com:6443/arcgis/rest/services.

Настройка HTTPS на ArcGIS Web Adaptor

Включите HTTPS на веб-сервере, где размещен ArcGIS Web Adaptor. Полные инструкции можно найти в документации к вашему веб-серверу. Подробнее о HTTPS см. в разделе Включение HTTPS на веб-сервере.

Прежние версии:

В версии 10.2.1 и более ранних требовалась перенастройка ArcGIS Web Adaptor после обновления протокола связи ArcGIS Server. В 10.2.2 и более новых версиях этого больше не требуется.

Доступ к сайту с помощью HTTPS.

После настройки HTTPS вы можете безопасно производить доступ непосредственно на ArcGIS Server через HTTPS, используя порт 6443 или URL-адрес Web Adaptor. Если переименовать ArcGIS Server при включенном протоколе HTTPS, доступ к ArcGIS Server с использованием HTTPS сохранится; однако необходимо создать новый сертификат и настроить ArcGIS Server на его использование. URL-адреса имеют следующий формат:


ArcGIS Server Manager	Доступ к Manager через сервер: https://gisserver.domain.com:6443/arcgis/manager. Доступ к Manager через ArcGIS Web Adaptor (только если включен административный доступ): https://webadaptorhost.domain.com/webadaptorname/manager.
ArcGIS Server Services Directory	Доступ к Services Directory через сервер: https://gisserver.domain.com:6443/arcgis/rest/services. Доступ к Services Directory через ArcGIS Web Adaptor: https://webadaptorhost. domain.com/webadaptorname/rest/services.

Отзыв по этому разделу?

Web доступ

Удаленный доступ к системе видеонаблюдения с помощью веб-браузера из любой точки мира через компьютеры или мобильные устройства.
Простой в использовании Web-клиент c удобным интерфейсом для просмотра и воспроизведения видео, управлением качеством трансляции и просмотром журнала событий позволяет работать с системой VideoNet с мобильных устройств или персонального компьютера, подключенных к Internet или находящихся в локальной сети, используя для этого web-браузер.
Вам не потребуется устанавливать на Ваше мобильное устройство или компьютер какое-либо специальное программное обеспечение.
Не имеет значения, где вы сейчас находитесь – на работе, дома, в командировке, на отдыхе.

Управлять качеством и параметрами трансляции видеоизображения для различных режимов просмотра

Выполнять пользовательские события (пользовательские команды)

Просматривать журналы событий всех компьютеров сети VideoNet

Воспроизводить записи по камерам (просмотр архива)

VideoNet Web-сервер поддерживает работу по протоколу HTTPS, что обеспечивает конфиденциальность, целостность, при передаче и хранении информации, и аутентификацию. Данные, которые передаются по этому протоколу, “упаковываются” в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных.

Web-доступ к системе VideoNet можно выполнить через Internet или с компьютера локальной сети. Web- доступ организуется следующим образом.

Пользователь подключается на своем персональном компьютере или мобильном устройстве к web-серверу VideoNet. Web-сервер VideoNet – это компьютер с установленной системой VideoNet и дополнительным программным обеспечением web- сервера. В конфигурации данного компьютера находятся камеры, как собственные, так и камеры других компьютеров этой сети. VideoNet Web-сервер работает по протоколу HTTP. Если локальная сеть или отдельный компьютер уже настроены для работы с web-приложениями, то дополнительных настроек не потребуется.

Демонстрация работы: http://promo.videonet.ru

Логин: web; Пароль: 123456

Скачать документацию и дистрибутив

Видео-инструкция установки Web-server

Для корректной работы с системой VideoNet через Web-доступ необходимо соблюсти следующие минимальные требования к оборудованию и программному обеспечению.

Требования для web-сервера VideoNet:

Операционная система (64 бита)

Microsoft Windows Server 2016 (версии 1709 и выше)
Microsoft Windows Server 2019
Microsoft Windows Server 2022
Microsoft Windows 10 Home/Pro/Enterprise (версии 1903 и выше)

Microsoft Windows 11 Home/Pro

Требования для web-клиента VideoNet:

Для web-клиента на мобильных устройствах:

Android browser (2.3, 3.2, 4.0, 4.1 и выше)
Opera Mobile (12.1)
iOS browser (5.1)

Разрешение экрана не менее 480х800.

Для web-клиента на ПК:

Microsoft Internet Explorer (9, 10, 11)
Google Chrome (23.0.хх и выше)
Safari (5.1.7 и выше)
Opera (12.11 и выше)

HTTP-аутентификация — HTTP | МДН

HTTP обеспечивает общую основу для контроля доступа и аутентификации. Эта страница представляет собой введение в структуру HTTP для аутентификации и показывает, как ограничить доступ к вашему серверу с помощью схемы HTTP «Basic».

RFC 7235 определяет структуру проверки подлинности HTTP, которая может использоваться сервером для оспаривания клиентского запроса и клиентом для предоставления информации для проверки подлинности.

Поток запросов и ответов работает следующим образом:

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

Приведенный выше общий поток сообщений одинаков для большинства (если не для всех) схем аутентификации. Фактическая информация в заголовках и способ ее кодирования действительно меняются!

Предупреждение: «Базовая» схема проверки подлинности, используемая на приведенной выше диаграмме, отправляет учетные данные в закодированном, но не зашифрованном виде.

Это было бы совершенно небезопасно, если бы обмен не осуществлялся через защищенное соединение (HTTPS/TLS).

Аутентификация прокси

Тот же механизм запроса и ответа можно использовать для аутентификации прокси-сервера . Поскольку и аутентификация ресурсов, и аутентификация прокси-сервера могут сосуществовать, необходим другой набор заголовков и кодов состояния. В случае прокси-серверов запрашивающий код состояния — 407 (требуется проверка подлинности прокси-сервера), заголовок ответа Proxy-Authenticate содержит как минимум один запрос, применимый к прокси-серверу, и Proxy-Authorization 9.Заголовок запроса 0011 используется для предоставления учетных данных прокси-серверу.

`Доступ запрещен`

Если (прокси) сервер получает неверные учетные данные , он должен ответить 401 Неавторизованный или 407 Требуется аутентификация прокси 9 0011, и пользователь может отправить новый запрос или замените поле заголовка Authorization .

Если (прокси) сервер получает действительные учетные данные, которые не соответствуют для доступа к данному ресурсу сервер должен ответить кодом состояния 403 Forbidden . В отличие от 401 Unauthorized или 407 Proxy Authentication Required , аутентификация для этого пользователя невозможна, и браузеры не будут предлагать новую попытку.

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

`Аутентификация образов разных источников`

Потенциальной дырой в безопасности (которую с тех пор устранили в браузерах) была аутентификация межсайтовых изображений. Начиная с Firefox 59, ресурсы изображений, загруженные из разных источников в текущий документ, больше не могут вызывать диалоги HTTP-аутентификации (ошибка Firefox 1423146), предотвращая кражу учетных данных пользователя, если злоумышленники смогли встроить произвольное изображение на стороннюю страницу.

 .
 Кодировка символов HTTP-аутентификации 
 Браузеры используют кодировку  utf-8  для имен пользователей и паролей.
 Firefox когда-то использовал  ISO-8859-1  , но был изменен на  utf-8  для соответствия другим браузерам и во избежание потенциальных проблем, как описано в ошибке Firefox 1419658.  WWW-Authenticate  и 9001 0 Прокси- Заголовки ответа Authenticate  определяют метод аутентификации, который следует использовать для получения доступа к ресурсу. Они должны указать, какая схема аутентификации используется, чтобы клиент, желающий авторизоваться, знал, как предоставить учетные данные.
   Синтаксис этих заголовков следующий:
 WWW-Authenticate:  realm=
Прокси-аутентификация:  realm=
 
 Здесь  <тип>  — это схема аутентификации («Базовая» — наиболее распространенная схема, представленная ниже). Область   используется для описания защищенной области или для указания объема защиты. Это может быть сообщение вроде «Доступ к промежуточному сайту» или подобное, чтобы пользователь знал, к какому пространству он пытается получить доступ.
 Заголовки запросов  Authorization  и  Proxy-Authorization  содержат учетные данные для аутентификации агента пользователя на (прокси) сервере. Здесь снова требуется 
   , за которым следуют учетные данные, которые могут быть закодированы или зашифрованы в зависимости от используемой схемы аутентификации.
 Авторизация: <тип> <учетные данные>
Прокси-авторизация:  
 
 Общая структура аутентификации HTTP является основой для ряда схем аутентификации.
 IANA ведет список схем аутентификации, но есть и другие схемы, предлагаемые хост-сервисами, такими как Amazon AWS.
 Некоторые распространенные схемы аутентификации включают:
  Basic 
 См. RFC 7617, учетные данные в кодировке base64. Дополнительная информация ниже.
  Носитель 
 См. RFC 6750, токены носителя для доступа к ресурсам, защищенным OAuth 2.0
  Дайджест 
 См. RFC 7616. Firefox 93 и более поздние версии поддерживают алгоритм SHA-256. Предыдущие версии поддерживают только хеширование MD5 (не рекомендуется).
  ХОБА 
 См. RFC 7486, раздел 3,  H  TTP  O  rigin-  B  ound  A  аутентификация на основе цифровой подписи
  Взаимный 
 См. RFC 8120
 Согласовать  /  NTLM 
 См. RFC4599
  БЕСПЛАТНЫЙ 
 См. RFC 8292
  СКРАМ 
 См. RFC 7804
  АВС4-HMAC-SHA256 
 См.
  документы AWS. Эта схема используется для аутентификации сервера AWS3.
 Схемы могут различаться степенью защиты и доступностью в клиентском или серверном программном обеспечении.
 «Базовая» схема аутентификации обеспечивает очень низкую безопасность, но широко поддерживается и проста в настройке.
Более подробно он представлен ниже.
 "Базовая" схема HTTP-аутентификации определена в RFC 7617, которая передает учетные данные в виде пар идентификатор пользователя/пароль, закодированных с использованием base64.
 Безопасность базовой аутентификации 
 Поскольку идентификатор пользователя и пароль передаются по сети в виде открытого текста (кодировка base64, но base64 является обратимой кодировкой), базовая схема аутентификации  не является безопасным  . HTTPS/TLS следует использовать с базовой аутентификацией. Без этих дополнительных улучшений безопасности базовая проверка подлинности не должна использоваться для защиты конфиденциальной или ценной информации.
 Ограничение доступа с помощью Apache и базовая аутентификация 
 Для защиты паролем каталога на сервере Apache вам потребуются файлы  .htaccess  и  .htpasswd .
 Файл  .htaccess  обычно выглядит так:
 Основной тип аутентификации
AuthName "Доступ к промежуточному сайту"
AuthUserFile /путь/к/.htpasswd
Требовать действительного пользователя
 
 Файл  .htaccess  ссылается на файл  .htpasswd , в котором каждая строка состоит из имени пользователя и пароля, разделенных двоеточием (  :  ). Вы не можете видеть фактические пароли, поскольку они хэшируются (в данном случае с использованием хеширования на основе MD5). Обратите внимание, что вы можете назвать свой файл  .htpasswd  по-разному, если хотите, но имейте в виду, что этот файл не должен быть доступен никому. (Apache обычно настроен на запрет доступа к  .ht*  файлов).
 аладдин:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. 
пользователь2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
 
 Ограничение доступа с помощью Nginx и базовой аутентификации 
 Для Nginx вам нужно будет указать местоположение, которое вы собираетесь защищать, и директиву  auth_basic , которая задает имя защищенной паролем области.
Затем директива  auth_basic_user_file  указывает на файл  .htpasswd , содержащий зашифрованные учетные данные пользователя, как в приведенном выше примере Apache.
 местоположение/статус {
    auth_basic "Доступ к промежуточному сайту";
    auth_basic_user_file /etc/apache2/.htpasswd;
}
 
 Доступ с использованием учетных данных в URL-адресе 
 Многие клиенты также позволяют избежать запроса на вход в систему, используя закодированный URL-адрес, содержащий имя пользователя и пароль, например:
 https://имя пользователя:пароль@www.example.com/

Использование этих URL устарело . В Chrome часть имя пользователя: пароль @ в URL-адресах даже удалена из соображений безопасности. В Firefox проверяется, действительно ли сайт требует аутентификации, и если нет, Firefox предупредит пользователя с подсказкой «Вы собираетесь войти на сайт 9».0010 www.example.com с именем пользователя имя пользователя , но веб-сайт не требует аутентификации. Это может быть попыткой обмануть вас».

WWW-аутентификация
Авторизация
Прокси-авторизация
Прокси-аутентификация
401 , 403 , 407

Обнаружили проблему с содержанием этой страницы?

Отредактируйте страницу на GitHub.
Сообщить о проблеме с содержимым.
Посмотреть исходный код на GitHub.

Хотите принять участие?

Узнайте, как внести свой вклад.

Последний раз эта страница была изменена 10 апреля 2023 г. участниками MDN.

как использовать командную строку curl для доступа к веб-странице с базовой аутентификацией HTTP

Задавать вопрос

спросил 7 лет, 8 месяцев назад

Изменено 11 месяцев назад

Просмотрено 27 тысяч раз

Раньше я использовал команду curl в терминале для доступа к веб-странице php для тестирования некоторых API-интерфейсов на веб-странице. Это работает нормально.

Например:

 curl www.somesite.com -d имя_параметра=значение

Теперь эта страница имеет базовую HTTP-аутентификацию. Я знал, что мне просто нужно добавить -u, чтобы указать имя пользователя и пароль. Я также гуглил, и почти все предлагают сделать то же самое:

 curl -u имя пользователя:пароль www. somesite.com -d имя_параметра=значение
curl --user имя пользователя:пароль www.somesite.com -d имя_параметра=значение

или

 curl http://имя пользователя:пароль@www.somesite.com -d имя_параметра=значение

Пробовал оба, ни один не работает. Я получил такое же сообщение об ошибке, как показано ниже:

<заголовок> 401 Требуется авторизация <тело>

Требуется авторизация

Этот сервер не смог подтвердить, что вы имеют право доступа к документу просил. Либо вы неправильно указали учетные данные (например, неверный пароль) или ваши браузер не понимает, как предоставить необходимые учетные данные.

Кроме того, требуется авторизация 401 произошла ошибка при попытке использовать ErrorDocument для обработки запроса.

<час> <адрес>Apache/2.2.29(Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 Сервер на www.somesite.com, порт 80

Я пытался получить доступ к веб-сайту через браузеры. После того, как я ввел имя пользователя и пароль в окне подсказки. Я могу получить доступ к этому веб-сайту.

Кто-нибудь знает, что здесь происходит? Спасибо.

Когда у меня возникла эта проблема, оказалось, что сервер не принимает схему аутентификации «Базовая», но curl использует «Базовую», если не указано иное.

Проверьте параметры командной строки curl, касающиеся схемы аутентификации. Вы можете использовать --basic , --digest , --ntlm , --negotiate и --anyauth . Подробности смотрите на справочных страницах curl.

В то время как --anyauth или --negotiate звучат так, будто curl может согласовать правильный метод аутентификации с сервером, ни один из них не работал у меня. Вместо этого мне пришлось явно использовать --digest , например:

 curl --digest -u имя пользователя:пароль -d parm1=value1&parm2=value2&submit=true https://www.