- Регистрация
- 10.12.2015
- Сообщения
- 619
- Реакции
- 318
- Баллы
- 63
Приветствую уважаемых посетителей форума Zennolab. В данной статье я хочу поделиться опытом разработки одного из самых крупных и нестандартных проектов, которым мне довелось заниматься с момента прошлого конкурса.
Суть идеи такова, что управлять работой шаблона мы будем при помощи Telegram, через интерфейс которого мы будем как передавать необходимые шаблону данные, так и получать обратную связь. Причем общаться шаблон сможет одновременно со многими пользователями.
В качестве примера использования такой идеи возьмем ситуацию, когда есть много людей с сим картами, которые готовы продавать коды дешевле чем аналогичные сервисы и мы хотим на их номера, регистрировать аккаунты, скажем, одноклассников.
В данной статье у меня пойдёт речь о сервисе с ограниченным количеством пользователей, то есть каждый работник будет добавляться вручную, но возможно, в развитие идеи у кого-то выйдет создать сервис под неограниченное количество участников.
Для работы нам потребуется либо Zennoposter версии стандарт и выше (нужно минимум 2 потока), либо зеннобокс, также купленный через лицензию стандарт и выше, т.к. потребуется добавлять несколько шаблонов и телеграмм.
Ссылка на русскую документацию, описывающую API Телеграм тут: https://tlgrm.ru/docs/bots/api
Первым делом создадим бота.
Добавляем в телеграм контакт @BotFather
Вводим боту последовательность команд, с названием бота и именем, которое должно заканчиваться на «bot».
В итоге получаем наш ключ для использования API телеграма:
Use this token to access the HTTP API:
313403030:AAHSGy5ebCE9alwUNKa1iJk6H8SUEDEbrPU
На этом создание бота завершено. В дальнейшем можно поменять боту описание, иконку, но клавиатуры и другие вещи настраивать не нужно, так как за это будет отвечать наш шаблон.
-----------------------------------------------------------------------
Далее вкратце опишу структуру того, что мы будем писать для ZennoPoster. Для получения информации об новых сообщениях в боте в телеграме используется два диаметрально противоположных по логике способа получать обновления от вашего бота: getUpdates и вебхуки. Входящие обновления будут храниться на сервере до тех пор, пока вы их не обработаете, но не дольше 24 часов.
Так как вебхуки предназначены для серверных приложений, мы будем слать на телеграм с максимальной частотой get запрос по методу getUpdates , а дальше обрабатывать ответ согласно нашей логике.
Для того, чтобы шаблон, который выполняет непосредственно задачу регистрации аккаунтов не находился постоянно в работе, т.к. он использует браузер и потребляет больше ресурсов, мы вводим понятие пользовательской сессии. Сессия будет открываться после получения проверяющим шаблоном соответствующей команды на начало работы. В случае открытой сессии первый шаблон передает все команды шаблону сессии, если активной сессии нет, то обрабатывает сам. Кроме команды на начало работы мы отдадим первому шаблону, назовем его для удобства шаблон проверки информационные запросы, такие как «инструкции», «о сервисе» и так далее, которые не требуют запуска браузера. Возможные варианты мы покажем пользователю в виде всплывающей клавиатуры. На неизвестный запрос мы также запрограммируем отдельный текст. Подробней работа шаблона проверки будет описана далее.
Как уже было упомянуто выше, необходим также шаблон работы с сессией. Данный шаблон будет запрашивать от пользователя необходимые данные, такие как номер телефона и ввода кода и передавать их шаблонам, отвечающим за ввод этих данных на целевом сайте. Кроме того, будет некоторое количество служебных команд, например, повторный запрос кода, начало работы с новым номером, принудительное закрытие сессии и так далее.
Сам шаблон регистратора мы разобьем на 2 части, первая часть будет отрабатывать регистрацию и ввод номера и отрабатывать до момента запроса кода, после чего возвращаться в шаблон сессии. Далее шаблон сессии запрашивает у пользователя код подтверждения, после получения которого, вторая часть исполняющего шаблона будет пытаться ввести этот код. Эти 2 части исполняющего шаблона будут встроены в шаблон сессии как «проект в проекте» для удобства обмена переменными между ними.
-------------------------------------------------------------------------
1. Шаблон проверки новых сообщений
Как уже говорилось выше, данный шаблон шлет с максимальной частотой запросы к api телеграма, для проверки входящих сообщений от пользователей:
Код:
https://api.telegram.org/bot{-Variable.bot_token-}/getUpdates?offset={-Variable.last_update_id-}
{-Variable.last_update_id-} – это токен, который мы получили при создании бота, советую в этом и послеюущих шаблонах вынести его во входные настройки.
{-Variable.last_update_id-} – айди последнего обновления, при первом запросе переменная пустая, чтобы получить все обновления и спарсить айди последнего.Далее на всякий случай стоит проверка на успешный ответ, делается это простой регуляркой "ok":.*true в ответе. Очень редко, но случается, что запрос уходит со сбоем, поэтому рекомендую все-таки ставить бесконечное количество запусков этому шаблону, а не один.
Ответы телеграм шлет в формате json, на момент написания шаблонов функционала парсинга не было, поэтому я собирал все регуляркой.
Напишем нашему боту любой текст, посмотрим, что мы получаем от телеграма в ответе:
Код:
{"message_id":4,"from":{"id":153478981,"first_name":"Vasiliy","last_name":"Pupkin","username":"vierasen"},"chat":{"id":153478981,"first_name":"Vasiliy","last_name":"Pupkin","username":"vierasen","type":"private"},"date":1482137729,"text":"634634634634"}}]}Тут мы видим ID сообщения, теоретически мы можем отправлять ответ на конкретное сообщение, но можно просто слать ответ пользователю. Далее мы видим ID пользователя, это очень важный параметр, указывая его в команде ответа телеграм знает, какому пользователю отправить то или иное сообщение. Имя и фамилию и ник пользователя мы опустим, но может кому-то понадобятся эти данные. Тип сообщения и дата нам тоже не понадобится. Поле Text это собственно то, что отправил нам пользователь, по нему мы будем определять, что же делать дальше с поступившими данными.
Далее идет проверка на активную сессию пользователя, проверка осуществляется при помощи файла-маркера {-Variable.chat_id-)_.txt Если данный файл существует, то команда записывается в файл {-Variable.chat_id-).txt (без нижнего прочерка) и ответ шаблоном проверки не дается. Этот файл (без нижнего прочерка) будет постоянно очищаться шаблоном работы с сессией. В случае наличия активной сессии данные передаются другому шаблону, шаблон проверки ответ не дает.
Если активной сессии не обнаружено, то шаблон определяет суть поступившей команды. Вы можете обратить внимание на Switch
В свиче запрограммированы общие информационные ответы (содержание которых указывается во входных настройках), команда start_work, при получении которой создается 2 файла {-Variable.chat_id-)_.txt и {-Variable.chat_id-).txt (это значит, что сессия открыта). Весь default, то есть нераспознанная команда дает соответствующее сообщение пользователю.
Что еще хотелось бы сказать о данном шаблоне. Для того чтобы пользователь видел клавиатуру, мы к каждому ответу добавляем параметр {-Variable.reply_markup-}
Подробней как это сделано, можно увидеть в шаблоне, который я приложу в конце статьи. Содержание клавиатуры я установил в значении переменной по умолчанию.
Пользователь видит клавиатуру вот так:
Второй шаблон я прикладывать целиком описывать не буду, так как общая суть точно такая же, прием данных от пользователя из поля text и ведение с ним диалога, в зависимости от результатов работы шаблона. Распишу тут лишь особенности:
Команды от пользователя мы получаем из файла, а не путем отправки запроса на сервер телеграм. После завершения сессии, у меня это происходит в следующих случаях: таймаут, больше количество бессмысленных сообщений, большое количество неудачных попыток регистраци, соответствующая команда от пользователя на завершение сессии.
Структура шаблона такая, есть центральный блок, к которому всегда возвращаемся и получаем обновление команды и остальные блоки, в которых имеются управляющие переменные отвечающие за то, в какой блок нужно посылать команду в настоящий момент.
Слегка объясню на пальцах, к примеру первый блок, это получение от пользователя номера телефона. Первая стрелка от блока получения команды ведет к нему. В начале блока стоит переменная, которая по умолчанию имеет значение True. При таком значении мы выполняем в данный момент этот блок. После того как номер получен и проверен, изменяем значение этой переменной на False и в следующий раз после получения новой команды шаблон будет пропускать этот блок и идти к следующему. После выполнения следующего блока, опять закрываем его изменением значения переменной и так далее. Каждый блок после завершения возвращается к блоку получения команды, оттуда уже последовательно проверяются блоки на предмет того, какому отдавать команду. По завершению цикла возвращаем переменным первоначальные значения.
Непосредственно с самим сайтом работаем аналогичным образом, в моем случае это 2 шаблона, привязанных как «проект в проекте». Работают как отдельные блоки, описанные выше. Первый шаблон принимает на вход номер, на выходе дает результат либо good (ожидайте получение кода), либо иной статус, к примеру номер не подошел. Во втором случае возвращаем шаблон к состоянию ожидания номера телефона. Второй шаблон уже вводит код и так же возвращает состояние. Результаты записываются в таблицу в удобном формате.
-------------------------------------------------------------------
Надеюсь, статью написал более-менее понятно, если какие-то моменты нужно прояснить, задавайте свои вопросы в комментариях.- Номер конкурса статей
- Шестой конкурс статей
- Тема статьи
- Нестандартные хаки
