Q
Слишком короткий поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Мессенджеры с каждым днем все больше и больше интегрируются в нашу жизнь. Это невольно наводит на мысль о «бесшовной» интеграции мгновенных сообщений и бизнес инструментов. Размышляя на этот счет, под наш исследовательский порыв попал популярный в России мессенджер Telegram и CRM Битрикс24.
Нам захотелось присылать информацию о созданном лиде в Битриксе в групповой чат Telegram. Мы написали небольшой скрипт на .php и адаптировали его на Linux – машине. Что из этого получилось, спешим рассказать :)
Попробовать Битрикс24
Бот в Телеграме
Итак, первым делом создаем бота в Телеграме. В нашей базе уже есть пошаговый материал по созданию бота, поэтому, нажмите на кнопку ниже и пройдите по ссылке. Выполните все шаги, которые указаны в пункте «Создание бота в Telegram» - это займет примерно 5 минут. Как сделаете, переходим к следующему пункту.
Создание бота
Скрипт обработки
Все ли получилось на этапе ранее? У вас должен быть токен вида 331754110:AAHkMNalOz5I_Schh2kvj7ONhRcE8HuKV-c и ID (идентификатор) группового чата. Если все на месте, то вашему вниманию предлагается сам скрипт (комментарии по ходу скрипта после двойного слеша //):
<?php
$token = "Ваш_токен"; // тут вводим ваш токен;
$chat_id = "ID_чата"; // указываем идентификатор группового чата
$lead_name=$_GET['name']; //получает методом GET название лида, ответственного, источник и его идентификатор;
$lead_respons=$_GET['respons'];
$lead_source=$_GET['source'];
$lead_link=$_GET['link'];
$lead_link1 = "https://ваш_домен_битрикс.bitrix24.ru/crm/lead/show/$lead_link/"; // данную конструкцию мы используем для того, чтобы корректно сформировать и отправить ссылку на лида в Telegram;
#Оправляем в телеграм
$hello = "<b>Здравствуйте, коллеги!</b>"; // формируем элементы массива (сообщения), который будем отправлять в сторону Telegram – API;
$hello_1 = "";
$message = "В CRM Битрикс24 добавлен новый лид - ";
$repons = "Ответственный - ";
$src= "Источник - ";
$link = "Ссылка - ";
$arr = array( // формируем сам массив;
$hello => $hello_1,
$message => $lead_name,
$repons => $lead_respons,
$src => $lead_source,
$link => $lead_link1,
);
foreach($arr as $key => $value) {
if ($key == "Ссылка - ") { $txt .= "".$key." ".$value."%0A";} else {
$txt .= "".$key." ".$value."%0A";
}};
fopen("https://api.telegram.org/bot{$token}/sendMessage?chat_id={$chat_id}&parse_mode=html&text={$txt}","r"); // отправляем данные в сторону API Телеграма;
Скачать скрипт
После загрузки скрипта по ссылке, смените его расширение на .php
Подставляем свои данные, сохраняем скрипт как bitrixtelegram.php и закидываем его в WEB - директорию вашего сервера (сервера в вашей сети). На нашем сервере мы используем web – сервер Apache на базе CentOS – наша директория /var/www/html/.
Важно! Скрипт должен быть доступен по web из внешней сети (Битрикс24 будет обращаться к нему из бизнес – процесса). Мы рекомендуем использовать https, засекьюрить директорию, внутри которой будет находиться скрипт (например, дать ей имя v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0. Тем самым, полный путь до директории будет /var/www/html/v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0). Помимо этого, рекомендуем ограничить подключение к этой директории фильтрацией по IP (на уровне web – сервера и фаервола/маршрутизатора на уровне L3).
После этого, в консоли сервера, в случае Linux, даем команды (путь к файлу скрипта у вас может отличаться):
chmod 755 /var/www/html/v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0/bitrixtelegram.php
dos2unix /var/www/html/v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0/bitrixtelegram.php
Адаптация в бизнес – процесс в Битрикс24
Да – да, мы будем использовать вебхуки (Webhook). Это отличное средство, которое позволяет внедрять кастомные сценарии в обработку любой сущности в рамках Битрикс24. По факту, Битрикс просто будет кидать GET - запрос.
Переходим к настройке. Открываем CRM → Настройки → Автоматизация → Бизнес - процессы → Лид → Добавить шаблон:
Даем имя шаблону и указываем параметры запуска – «При добавлении». Внутри самого бизнес процесса, из правой палитры инструментов перетаскиваем элемент Webhook:
В настройка вебхука, в поле в хендлер копируем следующую конструкцию:
https://telegram.merionet.ru/ v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0/ bitrixtelegram.php?name={=Document:TITLE}&respons={=Document:ASSIGNED_BY_PRINTABLE}&source={=Document:SOURCE_ID}&link={=Document:ID}
Где:
https://telegram.merionet.ru - хостовая часть, на которой расположился наш скрипт;
v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0 - директория в корне web – сервера, в которой лежит скрипт;
bitrixtelegram.php - сам скрипт;
?name={=Document:TITLE}&respons={=Document:ASSIGNED_BY_PRINTABLE}&source={=Document:SOURCE_ID}&link={=Document:ID} - параметры, которые мы будем передавать в скрипт, а именно – имя лида, источник, ответственный и ID - лида;
Проверяем :) Вручную добавляем лид в CRM:
И вот что ждет нас в Telegram:
Одиннадцатая часть тут.
Если у вас есть сеть, подобная той, что показана на рисунке 1, и Вам нужно чтобы А распространятл тот же контент в G, H, M и N, как бы вы это сделали?
Вы можете либо сгенерировать четыре копии трафика, отправив по одному потоку на каждый из приемников с помощью обычной (одноадресной - unicast) переадресации, либо каким-то образом отправить трафик на один адрес, который сеть знает для репликации, чтобы все четыре хоста получили копию. Этот последний вариант называется многоадресной рассылкой (multicast), что означает использование одного адреса для передачи трафика нескольким получателям. Ключевая проблема, решаемая в многоадресной рассылке, заключается в том, чтобы пересылать и реплицировать трафик по мере его прохождения через сеть, чтобы каждый получатель, заинтересованный в потоке, получал копию.
Важно: набор устройств, заинтересованных в получении потока пакетов от источника многоадресной рассылки, называется группой многоадресной рассылки. Это может быть немного запутанным, потому что адрес, используемый для описания многоадресного потока, также называется группой многоадресной рассылки в некоторых ситуациях. Эти два применения практически взаимозаменяемы в том, что набор устройств, заинтересованных в получении определенного набора пакетов многоадресной рассылки, присоединится к группе многоадресной рассылки, что, по сути, означает прослушивание определенного адреса многоадресной рассылки.
Важно: в случаях, когда многоадресный трафик является двунаправленным, эту проблему гораздо сложнее решить. Например, предположим, что существует требование создать группу многоадресной рассылки с каждым хостом в сети, показанной на рисунке 2, кроме N, и далее, чтобы любая многоадресная рассылка, переданная по адресу группы многоадресной рассылки, доставлялась каждому узлу в группе многоадресной рассылки.
Ключевая проблема для решения многоадресной рассылки может быть разбита на две проблемы:
Как узнать, какие устройства хотели бы получить копию трафика, передаваемого в группу многоадресной рассылки?
Как вы определяете, какие устройства в сети должны реплицировать трафик и на каких интерфейсах они должны отправлять копии?
Одним из возможных решений является использование локальных запросов для построения дерева, через которое многоадресный трафик должен передаваться по сети. Примером такой системы является разреженный режим (Sparse Mode) в Protocol Independent Multicast (PIM). В этом процессе каждое устройство отправляет сообщение соединения для многоадресных потоков, которые его интересуют; эти соединения передаются вверх по потоку в сети до тех пор, пока не будет достигнут отправитель (хост, отправляющий пакеты через многоадресный поток). Для иллюстрации этого процесса используется рисунок 2.
На рисунке 2:
A посылает некоторый трафик в группу многоадресной рассылки (адрес) - назовем его Z.
N хотел бы получить копию Z, поэтому он посылает запрос (соединение) своему вышестоящему маршрутизатору D для копии этого трафика.
D не имеет источника для этого трафика, поэтому он посылает запрос маршрутизаторам, к которым он подключен, на копию этого трафика. В этом случае единственный маршрутизатор D отправляет запрос В.
При каждом переходе маршрутизатор, получающий запрос, помещает интерфейс, на котором он получил запрос, в свой список исходящих интерфейсов (Outbound Interface List - OIL) и начинает пересылку трафика, полученного в данной многоадресной группе, полученной через любой другой интерфейс. Таким образом, может быть построен путь от получателя к отправителю трафика -это называется деревом обратного пути.
Второй вариант определения того, какие хосты заинтересованы в получении трафика для определенной группы многоадресной рассылки, - через своего рода сервер регистрации. Каждый хост, который хотел бы получить копию потока, может зарегистрировать свое желание на сервере. Есть несколько способов, которыми хост может обнаружить присутствие сервера, в том числе:
Обращение с адресом группы многоадресной рассылки как с доменным именем и поиск адреса сервера регистрации путем запроса адреса группы многоадресной рассылки.
Построение и ведение списка или сопоставления групп с серверами, отображаемыми в локальной таблице
Использование некоторой формы хэш-алгоритма для вычисления регистрационного сервера по адресу группы многоадресной рассылки
Регистрации могут отслеживаться либо устройствами на пути к серверу, либо, когда набор приемников и передатчиков известен, сервер может сигнализировать соответствующим устройствам вдоль пути, какие порты следует настроить для репликации и пересылки пакетов.
В этой статье рассмотрим, как управлять учетными записями пользователей и групп в Linux. Также посмотрим различные базы данных, в которых хранится информация о пользователях и группах и что такое теневые пароли.
Изначально в Linux было 2 файла /etc/password и /etc/group. В первом файле хранилось:
Имя_пользователя : пароль : uid : gid : сведения (поле предназначено для персональных данных) : домашняя_папка : командная оболочк(которая запускается при входе пользователя в систему)
Во втором файле хранилось:
имя_группы : пароль : gid : члены_группы
У группы может быть пароль, но данную функцию очень редко, кто использует, в таком случае пароль будет запрашиваться при смене членства в группе. Данные файлы плохи тем, что у всех пользователей системы, по умолчанию, есть права на чтение. Такие права необходимы потому, что разные пользователи, разные демоны и сервисы обращаются к данным файлам, чтобы брать оттуда информацию. Соответственно в этих файлах хранился пароль пользователя, хотя и в зашифрованном виде, но с помощью различных методов криптографии подбора можно было воспользоваться данным паролем, потому что у всех пользователей был на эти файлы доступ.
Поэтому был создан механизм теневых паролей. Были созданы вот такие 2 файла: /etc/shadow и /etc/gshadow. И к этим двум файлам имеет полный доступ только пользователь root. Следовательно, теперь в файлах passwd и group указываются не пароли, а специальные символы, говорящие что пароли были перенесены в файлы shadow и gshadow.
В новом файле shadow хранится побольше информации о пароле пользователя. Это:
Логин
Пароль
Время после смены пароля – это если пароль сбрасывался после времени установки системы
Минимальный срок действия пароля - как часто можно менять пароль, если, например, стоит 5 дней, то пароль можно менять не чаще, чем раз в 5 дней.
Максимальный срок действия пароля – максимальное количество дней, по прошествии которых обязательно необходимо сменить пароль.
Срок предупреждения – за сколько дней до истечения пароля система предупредит о том, что необходимо сменить пароль.
Время работы с истекшим паролем – это параметр позволяет указанное число дней работать с истекшим паролем.
Срок для блокировки пароля – данный параметр отвечает за время жизни самого пароля, например, пароль будет работать 100 дней, после этого заблокируется.
Соответственно данные параметры можно при необходимости задавать при создании учетной записи пользователя и паролей. Если провести аналогию с операционной системой Windows, то подобные параметры в Windows мы можем задавать через GPO (Group Policy Object - набор правил или настроек, в соответствии с которыми производится настройка рабочей среды в операционных системах Windows). Отличие заключается в том, что в Windows эти параметры выставляются в абсолютных величинах числом, а в операционной системе Linux, относительно даты 1 января 1970 года.
Ну и соответственно gshadow имеет следующую структуру, разделенную символом :.
Имя группы
Пароль зашифрованный
Администраторы, те учетные записи, которые могут менять пароль группы или добавлять другие аккаунты
Члены групп
Следовательно, пароли могут хранится и в тех, и в тех файлах, отличие в том, что у пользователей есть доступ на чтение к файлам passwd и group, а к shadow и gshadow только у пользователя root. Данный механизм называется механизмом теневых паролей, и он присутствует во всех современных Linux системах.
Теперь, посмотрим, как это выглядит в операционной системе.
Заходим в файл passwd любым текстовым редактором, например, nano, без повышения привилегий.
Возьмем пользователя:
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
Логин - list, значок X говорит о том, что пароль хранится в теневом файле. Далее 38 – id пользователя, 38 - gid, прочая информация - Mailing List Manager, домашняя папка пользователя - /var/list и оболочка которая используется при входе - /usr/sbin/nologin.
Можно увидеть, что вместо оболочки у пользователя указан nologin – это означает, что пользователь не может войти, используя стандартный экран входа, используя стандартные средства. На картинке можно найти пользователя siadmin. Можно также увидеть все остальные параметры этого пользователя. У него совпадает uid и gid, это связанно с тем , что при создании пользователя создается одноименная группа. Можно, конечно, при создании указать, что пользователь будет входить в другую группу и не создавать одноименную, но по умолчанию она создается. В конце строчки мы можем увидеть /bin/bash, которая запускается при входе в систему. Можно обратить внимания на uid и gid все реальные пользователи их имеют числом выше 1000. Все пользователи, у которых число ниже – это служебные пользователи или созданные автоматически. В некоторых дистрибутивах Linux нумерация реальных пользователей начинается с 500.
Посмотрим файл с группами, вводим команду nano /etc/group
Данная база очень простая. Указано наименование группы, знак X говорит, о том, что пароль хранится в теневой базе, идентификатор группы и список пользователей в данной группе. Единственный нюанс - если пользователь входит в свою же группу, то после знака двоеточие пользователь не отображается.
Далее файлы /etc/shadow и /etc/gshadow, данные файлы не редактируются с помощью текстовых редакторов, а через специальные команды. Данные файлы — это просто хранилище информации. Эти утилиты будут рассмотрены в следующем уроке.
Зайти в эти файлы могут только пользователи имеющие права root или с помощью команды повышающей привилегии sudo.
sudo nano /etc/shadow
Теперь мы видим в данном файле через двоеточие:
Имя пользователя
* или зашифрованный пароль
Срок с последнего изменения пароля в днях
Минимальный срок изменения пароля, если 0, то сменить пароль можно сразу
99999 - срок действия пароля, 7 - количество дней за которое до истечения пароля придет предупреждение
Символ * говорит о том, что под данным пользователем нельзя зайти стандартным способом, обычно это применяется для служебных аккаунтов, т.е вход вообще заблокирован под данным аккаунтом.
Вот так вот реализуется механизм теневых паролей.