По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
По умолчанию, в Windows Server 2019 брандмауэр настроен на блокировку входящего трафика ICMP. Сюда входят эхо-запросы, которые используются командой ping, и это может затруднить устранение неполадок в сети. Некоторые системы мониторинга используют команду ping для отслеживания доступности серверов.
В этом руководстве рассмотрим, как включить правило, чтобы сервер стал отвечать на ping используя графический интерфейс Windows Server 2019, а также включим разрешающее правило через PowerShell и netsh.
Обычно просто отключают Windows Firewall полностью, однако это не рекомендуется делать в производственной среде, так как брандмауэр Windows хорошо справляется с обеспечением базового уровня защиты системы. Разрешим только конкретное правило, необходимое для успешного выполнения команды ping.
Разрешить проверку связи через брандмауэр Windows
Сначала нам нужно открыть брандмауэр Windows, это можно сделать несколькими способами. Один из методов - просто нажать клавишу Windows, чтобы открыть меню "Start", а затем начать вводить слово Firewall. Как показано ниже, брандмауэр Windows с расширенной безопасностью должен отображаться, выберите этот пункт.
Еще один быстрый способ: в PowerShell можно просто ввести "firewall" и нажать Enter. Откроется базовый интерфейс брандмауэра, а затем нажать кнопку "Advanced settings" в левой части. Откроется тот же интерфейс, что и через меню "Start".
Следующий способ открыть Firewall - ввести в CMD такой текст: "firewall.cpl"
В Брандмауэре в расширенном режиме перейдите в Inboud Rules (Правила для входящих подключений).
В перечне правил в Inboud Rules, найдите "File and Printer Sharing (Echo Request - ICMPv4-In)" и активируйте его.
Еще один вариант. Активируем разрешающее правило командлетом Powershell
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled True
Полную справку со всеми параметрами можно получить, набрав команду в PowerShell
help New-NetFirewallRule
Вариант создания правила через netsh
netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow
Примечание: Включение правила позволит получать ответы только на IPv4 запросы, если нужно получать ответы по IPv6, нужно разблокировать правило такое же правило, только с Echo Request - ICMPv6-In, перечисленное ниже. К тому же имеется несколько профилей: доменный, публичный, частный. Ненужные профили можно отключить в правиле, во вкладке Advanced.
После разблокировки правила сервер должен начать отвечать на запросы ping. С хоста виртуализации или другого пк в локальной сети протестируем ping'ом Windows Server 2019 по адресу 192.168.1.11 перед включением правила, а затем снова после его включения. Ниже видно, что время ожидания первых запросов истекло, так как входящие запросы ICMP были отключены по умолчанию в Windows Server 2019. После включения правила ICMP запросы ping успешно выполняются, что подтверждает ожидаемую работу.
Пример проверки связи:
Скачать видео.
Резюме
Стандартное правило брандмауэра - блокировать ICMP запросы, в итоге сервер не отвечает на ping. Включив это правило брандмауэра, мы включили команду ping в Windows Server 2019, которая поможет нам устранить неполадки в сети.
OpenAPI Spec – излюбленный выбор экспертов по разработке API, особенно если главным приоритетом является безопасность. Инструментарий Swagger в этом отношении кажется хорошим вспомогательным средством. Однако пытаться совместить эти два понятия – настоящая задача. Вы, наверное, уже запутались?
Не беспокойтесь. Эта статья поможет вам во всем разобраться.
OpenAPI: хронология его создания
OpenAPI – это всемирно признанная проектная спецификация RESTful API, разработанная под эгидой OpenAPI Initiative. Лучшие игроки IT-индустрии, такие как Google, Capital One, SmartBear, Microsoft, Apigee и PayPal, вместе запустили этот проект. Сама спецификация также поддерживается Linux Foundation.
OpenAPI также известен как коммерчески нейтральный и независимый от языка интерфейс для RESTful API. Он широко используется для того, чтобы пользователи и машины могли взаимодействовать без фактического доступа к документации, фрагментам исходного кода или аудита перегрузки сети.
Хронология создания
(2009) – OpenAPI и Swagger появились благодаря Тони Тэму, специалисту по программному обеспечению. Первоначально он запустил спецификацию Swagger с открытым исходным кодом для использования в компании.
(2011) – первая версия пользовательского интерфейса Swagger смогла описать JSON API для Wordnik. Она может использовать консоль разработчика/документацию компании, интеграцию кода и функции генерации кода.
(2012) – появилась усовершенствованная, но все же еще бета, версия.
(2014) – самая первая формализованная и официальная версия Swagger Spec0 была представлена публике в 2014 году. Она получила высокую оценку пользователей API.
(2015) – SmartBear приобрела Swagger Spec.
(2016) – Swagger стал «Спецификацией OpenAPI» и был переведен в другой репозиторий Git.
(2017) – входит в OpenAPI Initiative
На сегодняшний день уже доступна версия 3.1.0, которая пока считается лучшей. Для этой версии важно структурирование и форматирование API. Она выполняет процесс аутентификации и авторизации в соответствии со схемами аутентификации HTTP.
Помимо этого, аутентификация и авторизация пользователя могут быть выполнены путем отправки ключей API в качестве заголовка или файлов cookie. Также у вас есть возможность использовать методы обнаружения OAuth 2 или OpenID Connect из версии 3.1.0.
Swagger: история и инструментарий
Swagger – это, по своей сути, тип языка описания интерфейса, разработанный для эффективного определения процедур использования RESTful API. Он использует в своей основе JSON.
Набор инструментов Swagger включает в себя несколько инструментов с открытым исходным кодом и несколько коммерческих инструментов, которые могут использоваться в течение стандартного жизненного цикла API. Говоря без преувеличений, набор инструментов Swagger упрощает написание API. О его популярности можно судить по одному лишь факту – на 2017 год инструменты Swagger загружались более 100 000 раз в день.
В инструментарий Swagger вошли такие инструменты как:
SwaggerCore – это набор библиотек Java для подготовки, использования и развертывания определений OpenAPI.
Конечные пользователи могут использовать Swagger Editor с целью написания или модификации спецификаций OpenAPI на основе YAML через популярные веб-браузеры. С ним вы можете улучшить читаемость документации, провести предварительный просмотр от лица конечных пользователей и модифицировать ее, чтобы устранить ошибки и сделать ее более удобной в использовании.
Страницы HTML, JS и CSS в репозитории Swagger UI упрощают процесс написания документации.
Если вам необходим хороший инструмент для проектирования и документирования, то правильным выбором будет SwaggerHub. Его часто используют специалисты для всех типов проектов OpenAPI.
Swagger Parser позволяет анализировать определения.
Swagger Codegen – это инструмент для создания заглушек сервера API, SDK и других документов.
С помощью Swagger Inspector можно проверить процесс создания определения OpenAPI. Это поможет вам улучшить этот процесс благодаря тщательному тестированию.
Swagger vs OpenAPI: топ-4 отличия
Давайте начнем с основ: OpenAPI = Спецификация для правильного определения и описания RESTful API. Swagger = Набор инструментов, используемый для развертывания спецификаций API.
Swagger допускает комбинацию host+base_path для одного сервера. С другой стороны, OpenAPI позволяет добавлять несколько URL-адресов серверов и путей поддоменов для того, чтобы упростить вашу жизнь.
Все инструменты Swagger используют OpenAPI; обратное также должно быть верно.
Инструменты Swagger сохранили свои первоначальные названия, несмотря на то, что Swagger изменил название на спецификацию OpenAPI.
Общее влияние Swagger и OpenAPI на создателей API и API-отрасль
Когда Тони Тэм создавал Swagger, он даже предположить не мог, что в будущем изменит представление о безопасности API и API-отрасли в целом. С течением времени OpenAPI Spec и Swagger стали именами нарицательными при упоминании RESTful API.
Поскольку OpenAPI является бесплатным средством с открытым исходным кодом, которое предлагается пользователям API, то у начинающих разработчиков есть возможность научиться большему и показать весь свой потенциал. У разработчиков-новичков есть множество возможностей для работы и оттачивания своих навыков разработки API.
Главной задачей разработчиков оставалось поддержание стандартов безопасности на каждом этапе разработки API. Количество взломов API растет с каждым днем. Крупные предприятия, такие как Cisco Systems, Facebook и Shopify, регулярно сталкиваются с уязвимостями API и изо всех сил пытаются укрепить свою систему безопасности. Нарушение API в Equifax, которое стоило компании судебного иска в размере 700 миллионов долларов, вынудило предприятия лучше следить за безопасностью ИИ.
Использование OpenAPI положительно повлияло на методы разработки API, поскольку позволило команде разработчиков говорить на одном языке и, соответственно, легко общаться. Разработчикам больше не требуется убирать назначение API из ключевого функционала или исходного кода.
Принятие предопределенных стандартов безопасности является вполне осуществимой задачей, поскольку созданный API может взаимодействовать на простом языке и не вызывает беспокойства при обнаружении возможных брешей и угроз безопасности.
Что предлагают Swagger и OpenAPI на сегодняшний день?
OpenAPI, а равно и Swagger, на сегодняшний день являются движущей силой API-индустрии. Оин упрощают создание серверной заглушки для API. Разработчики могут создавать библиотеки клиентских API на более, чем 40 языках. Они расширяют возможности разработки API и повышают его безопасность за счет:
Создания интерактивного API: Разработчики могут использовать OpenAPI для написания интерактивной документации. Мало того, он позволяет запускать тесты API непосредственно из браузера во время подготовки документа.
Поддержки инструментов генерации кода: OpenAPI – это великое благословение, поскольку он полезен при создании серверных SDK и клиентских CDK на нескольких языках программирования. Он хорошо работает с инструментами генерации кода.
Аудита: OpenAPI Spec хорошо работает совместно с инструментом Contract Audit, который контролирует защиту операций, связанных с данными API. Фактически, этот инструмент является отличным ресурсом для обеспечения безопасности высокого уровня. При совместной работе OpenAPI Spec и Contract Audit выявление проблем безопасности в созданном API и их аудит становятся не такими утомительными. Можно выполнить аудит API с самого начала и избавить себя от аудита огромного количества API в конце разработки.
Куда держит курс Swagger?
OpenAPI – важная утилита, и эксперты рынка утверждают, что она имеет хорошие перспективы. Однако небольшая часть людей все же считает, что Swagger теряет свой лоск после передачи ключевых спецификаций OpenAPI. Учитывая, что на сегодняшний день он используется и играет решающую роль во многих задачах, особенно в тестировании API и повышении уровня безопасности, они могут ошибаться.
Инструменты Swagger позволяют наглядно увидеть код и протестировать практическую ценность фрагментов кода в режиме реального времени. Благодаря пользовательскому интерфейсу Swagger, разработчикам стало еще проще, чем когда-либо, запускать команды и получать всестороннее представление о функциональных возможностях системы.
Поддержание стандартизации в написании API также возможно с помощью Swagger, поскольку он совместно с OpenAPI предлагает всемирно признанный набор стандартов создания API.
Инструменты Swagger также могут помочь в написании API с нуля. Используя Swagger Editor, можно тестировать API в режиме реального времени. Это позволяет пользователям проверять проектное решение утилиты на соответствие спецификации OAS OpenAPI и узнать текущий визуальный результат. Лучшее свойство этого инструмента заключается в том, что его можно использовать из любой точки.
Также Swagger Inspector является одним из важнейших инструментов из набора Swagger, поскольку он позволяет создавать свои собственные спецификации API. Возможно не только создание настраиваемых API, но и передача этих API другим членам команды.
Когда речь идет о безопасности API в Интернете, то лучшее решение – это Swashbuckle. Это реализация Swagger с открытым исходным кодом, позволяющая конечным пользователям создавать живую документацию для всех своих API. Этот инструмент синхронизирует документацию с вашей текущей версией API и сокращает риски безопасности до нуля.
Заключение
Поскольку OpenAPI сформировался из Swagger, то тут явно было где запутаться.
Первая утилита предназначена для описания RESTful API. Это хороший инструмент с точки зрения безопасности, поскольку он сохраняет спецификацию в машиночитаемой форме. С другой стороны, вторая утилита – на сегодняшний день это фаворит разработчиков в случаях, когда речь идет о коммерчески нейтральном развертывании OpenAPI Spec.
Надеюсь, что когда в следующий раз вы услышите эти два понятия, то не запутаетесь и правильно разберетесь в фактах. Они оба оказывают положительное влияние на API-отрасль и способствуют развитию API.
Привет! В статье расскажем о бесплатном способе передачи информации о звонящем в момент звонка из Битрикс24. Проверять мы будем лид и контакт. В качестве системы, куда мы будет отправлять данные будет уютный Telegram :) Погнали.
Создаем Вебхук в Битрикс24
Переходим в Битрикс24 и открываем раскрывающееся меню в верхнем левом углу. Далее, выбираем «Вебхуки»:
Добавляем Входящий вебхук, нажав на зеленую кнопку в правом верхнем углу Добавить вебхук. Делаем следующие настройки:
Название - дайте имя. Например «Внешний доступ к REST API»;
Описание - «cоответствие номера клиента и его имени»;
Права доступа - необходимо выбрать «CRM (crm)»;
Нажимаем «Сохранить». Для нас будет сгенерирован Вебхук. Переходим к настройке скрипта.
Telegram - бот
Перед продолжение настройки, вам необходимо создать Telegram – бота. О том, как это сделать читайте по кнопке:
Создание бота
Скрипт интеграции
Из предыдущего шага, у вас должен быть идентификатор чата в Telegram, токен бота, вебхук и доменное имя вашего Битрикс24. Все, остальное дело скрипта:
#!/usr/bin/php -q
<?php
#подключаем AGI - библиотеку;
require('phpagi.php');
$agi = new AGI();
$cid = $agi->request['agi_callerid'];
#от провайдера, номер на нашу АТС прилетает в формате 79ХХХХХХХХХ. В CRM номера записаны как 89ХХХХХХХХХ. Поэтому, мы стрипаем цифру спереди и подставлем 8ку;
$phone = substr($cid, 1);
$phone = "8$phone";
$phoneFieldset = "Коллеги, входящий звонок. Звонящий: ";
#укажите служебные параметры: токен бота, идентификатор чата, хостовое имя CRM (то, что между https:// и до .bitrix24.ru) и вебхук, который мы получили ранее;
$token = "333333333:MMMMMEEEEE_RRRIIIIOOOO_NNNNEEEETTTT";
$chat_id = "-1001001001001";
$crm_id = "имя_вашего_Битрикс24";
$webhook = "wblhahgytuwrnwer";
#проверяем существование лида по номеру;
$bitrix_lead_url = "https://$crm_id.bitrix24.ru/rest/2/$webhook/crm.lead.list.json?filter[PHONE]=$phone&select[]=TITLE&select[]=NAME&select[]=LAST_NAME";
$btl = curl_init();
curl_setopt ($btl, CURLOPT_URL,$bitrix_lead_url);
curl_setopt ($btl, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
curl_setopt ($btl, CURLOPT_TIMEOUT, 60);
curl_setopt ($btl, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($btl, CURLOPT_RETURNTRANSFER, 1);
$bitrix_lead = curl_exec ($btl);
curl_close($btl);
$bitrix_lead_o = json_decode($bitrix_lead, true);
$l_total = $bitrix_lead_o['total'];
#проверяем существование контакта по номеру;
$bitrix_contact_url = "https://$crm_id.bitrix24.ru/rest/2/$webhook/crm.contact.list.json?filter[PHONE]=$phone&select[]=TITLE&select[]=NAME&select[]=LAST_NAME";
$btc = curl_init();
curl_setopt ($btc, CURLOPT_URL,$bitrix_contact_url);
curl_setopt ($btc, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
curl_setopt ($btc, CURLOPT_TIMEOUT, 60);
curl_setopt ($btc, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($btc, CURLOPT_RETURNTRANSFER, 1);
$bitrix_contact = curl_exec ($btc);
curl_close($btc);
$bitrix_contact_o = json_decode($bitrix_contact, true);
$c_total = $bitrix_contact_o ['total'];
#если найден лид, то: формируем массив и кидаем в сторону Telegram: имя, фамилия и идентификатор лида;
if ($l_total >= 1) {
$l_name = $bitrix_lead_o['result'][0]['NAME'];
$l_title = $bitrix_lead_o['result'][0]['TITLE'];
$l_l_name = $bitrix_lead_o['result'][0]['LAST_NAME'];
$l_id = $bitrix_lead_o['result'][0]['ID'];
$l_titleFieldset = "Входящий звонок от лида - ";
$l_FnameFieldset = "Его имя - ";
$l_linkFieldset = "Ссылка на лид - ";
$l_fullname = "$l_name $l_l_name";
$l_link = "https://$crm_id.bitrix24.ru/crm/lead/show/$l_id/";
$arr = array(
$l_titleFieldset => $l_title,
$l_FnameFieldset => $l_fullname,
$l_linkFieldset => $l_link,
);
foreach($arr as $key => $value) {
$txt .= "".$key." ".$value."%0A";
};
fopen("https://api.telegram.org/bot{$token}/sendMessage?chat_id={$chat_id}&parse_mode=html&text={$txt}","r");
}
#если найден контакт, то: формируем массив и кидаем в сторону Telegram: имя, фамилия и идентификатор контакта;
elseif ($c_total >= 1) {
$c_name = $bitrix_contact_o ['result'][0]['NAME'];
$c_c_name = $bitrix_contact_o ['result'][0]['LAST_NAME'];
$c_id = $bitrix_contact_o ['result'][0]['ID'];
$c_FnameFieldset = "Входящий звонок от контакта - ";
$c_linkFieldset = "Ссылка на контакт - ";
$c_fullname = "$c_name $c_c_name";
$c_link = "https://$crm_id.bitrix24.ru/crm/contact/show/$c_id/";
$arr = array(
$c_FnameFieldset => $c_fullname,
$c_linkFieldset => $c_link,
);
foreach($arr as $key => $value) {
$txt .= "".$key." ".$value."%0A";
};
fopen("https://api.telegram.org/bot{$token}/sendMessage?chat_id={$chat_id}&parse_mode=html&text={$txt}","r");
}
else {};
Скачать скрипт
По факту, от вас требуется изменить следующие переменные:
$token - токен вашего бота. Как его получить указано в стате по ссылке «Создание телеграм бота» выше;
$chat_id - идентификатор чата, в котором находится бот. Генерация так же указана в статье;
$crm_id - хостовая часть вашего Битрикс24. Если у вас URL CRM company.bitrix24.ru, то указать нужно company;
$webhook - вебхук. Мы показывали ранее, как его получить в Битрикс24 (у нас wblhahgytuwrnwer);
Сохраняем скрипт как b24.php закидываем его в директорию /var/lib/asterisk/agi-bin.
Адаптируем скрипт в unix – среде:
dos2unix /var/lib/asterisk/agi-bin/b24.php
chown asterisk:asterisk /var/lib/asterisk/agi-bin/b24.php
chmod 775 /var/lib/asterisk/agi-bin/b24.php
В диалплане (вставьте исполнение скрипта в транке, например):
exten => _.,n,AGI(b24.php)
Добавив в скрипт конструкцию вида $agi->set_variable("lookupcid", "$c_fullname"); для контакта или $agi->set_variable("lookupcid", "$l_fullname"); для лида, в диалплане мы сможем сделать следующее: Set(CALLERID(name)=${lookupcid}) мы получим имя звонящего в виде CallerID Name – например, на дисплее телефона.
Можете создать тестового лида (или контакт) со своим номером телефона или дождаться звонка клиента. Наслаждаемся :)