- Регистрация
- 08.11.2015
- Сообщения
- 1 863
- Благодарностей
- 2 580
- Баллы
- 113
Иметь возможность пользоваться бесконечными почтовыми ящиками – это довольно неплохо.
Решение я написал несколько месяцев назад.
Друзья и знакомые уже зарегистрировали и использовали десятки тысяч email.
Сейчас схема рабочая.
Но, такой заголовок - это первое что пришло на ум, когда решился писать статью.
В реальности термин "бесконечные" спорный - ведь в любой момент все может измениться.
Не нужно обращать на него внимание, как и написаное в статье не стоит принимать как "истину в последней инстанции".
Я могу ошибаться и заблуждаться, и даже не правильно ставить запятые в тексте - это нормально.
В случае необходимости читать более грамотный текст - стоит просто отправить статью какому-то чату-GPT, он быстро исправит все ошибки, сделает сокращенную версию, и даже в случае необходимости, сможет расширить те пункты, о которых я даже не подумал.
От автора
Уже почти 10 лет я использую ZennoPoster и помог многим разобраться в его тонкостях.
Кто знает, может, это и единственная причина, почему мою статью читаешь и ты...
Более подробное представление себя я давал в предыдущих конкурсах.
Если твой путь только начинается — рекомендую ознакомиться с моими работами:
О чём здесь
В основном здесь будет пример построения сложной системы.
На сколько стоит вникать в сложности - решит каждый себе самостоятельно.
Будет предоставлено готовое решение регистрации почты и получения последнего письма.
Что получишь
Пример реализации TelegramBot:
Отделяю email от его обслуживания
Представь себе, что вместо ZennoPoster работает живой человек, задача которого — брать email, выполнять какие-то действия, после чего авторизоваться в этом email и проверить, пришло ли письмо.
Всё это требует времени.
А если мы еще и скажем, что не хотим давать этому человеку пароль от email?
Конечное решение — система с нулевым доверием.
В качестве примера будет использоваться TelegramBot.
Но, в целом бывает полезно сделать так, чтобы один шаблон в ZennoPoster не имел больше информации, чем ему нужно в текущий момент.
Актуальность
Сообществу форума нет необходимости объяснять, насколько важно всегда иметь под рукой работающие email.
В идеале — в бесконечном количестве.
Частично эту проблему решают сервисы временной почты.
Также люди ищут брошенные домены, продают их.
Многие сервисы временной почты закрываются (Копеечка - помним и скорбим).
Регистрация же на Gmail, Yahoo, Outlook сопровождается капчами, SMS-подтверждениями, банами по IP и не только.
Новичкам которые пытаются что-то автоматизировать используя ZennoPoster это может создавать кучу проблем.
А также работа с почтой может быть затратной: покупка аккаунтов, оплата решений капч или CapMonster2, оплата приватных или мобильных прокси, оплата виртуальных номеров для SMS.
А ведь это мы еще не говорим о потенциальных потерях...
Реальность
Возможно даже у тебя был подобный случай — напиши об этом в комментариях.
Альтернатива
Есть ли альтернатива? Да! Это децентрализованная криптовалютная почта.
Название указывать не буду, но любопытный читатель найдет ссылку внутри шаблонов, а вот Google не узнает об автоматизации этого сервиса.
Сейчас нет ни капчи, ни номера телефона, ни SMS – только генерация приватного ключа и подпись сообщения.
В моем решении они будут сгенерированы без браузера и Metamask.
Само взаимодействие с сервисом исключительно на post/get запросах.
Реализовано в шаблонах Action_1 и Action_2 - забирай и изучай тонкости реализации.
В этой статье технического разбора этой реализации не будет - вдруг завтра сервис закроется, тогда моя статья станет не актуальной, так что направление статьи заточено под вечнозеленую тему - как строить сложные решения.
Нужные DLL и пример кода
Чтобы всё заработало необходимо взять библиотеки, о которых уже расказывал пользователь @Zedx.
Nethereum - Работаем с блокчейном напрямую
NBitcoin - Генератор/чекер криптовалютных кошельков -
Забрасываю библиотеки в папку ExternalAssemblies: C:\Путь к Зенно\ZennoPoster Pro V7\7.7.18.1\Progs\ExternalAssemblies
И добавляю на них ссылки в GAS.
- Nethereum.Accounts.dll
- Nethereum.HdWallet.dll
- Nethereum.Signer.dll
- Nethereum.Util.dll
- Nethereum.Hex.dll
- System.Numerics.dll
- netstandard.dll 2.0.0
Дальше в Директивы using и Общий код добавляю:
Вот такой код генерирует SEED-фразу.
Вот такой код создает кошелек в нужном формате.
Вот такой код подписывает сообщение.
Теперь, когда DLL уже добавлены есть смысл ознакомиться с логикой взаимодействия моих шаблонов.
Логика шаблонов - начальный уровень
В Action_1 – проходит регистрацию аккаунта
Здесь генерируется SEED фраза, подписывается сообщение.
И чтобы почта имела возможность принимать письма - читается входящее письмо.
Результатом выполнения будет json с аккаунтом (seed, wallet, email и данные авторизации).
В Action_2 – Проходит авторизацию
Естественно, если она не пройдена, получение последнего письма и его удаление из аккаунта.
Этот шаблон принимает на вход json который был получен шаблоном Action_1.
На выходе отдает json с информацией о письме (кто отправил, когда отправил, какая тема письма, какой html письма).
Эти шаблоны можно использовать в проект-в-проекте, передавая результат первого во второй.
Case_1 - показывает как практически можно использовать шаблоны Action_1 и Action_2.
Пример строится на заполнении формы при регистрации на сайте.
В нем происходит весь путь от получения почты до получения письма.
И его очевидная проблема - это хранение на своей стороне данных об авторизации, seed фразы, которая явно не нужна в этом шаблоне.
Не всегда хочется держать под рукой данные авторизации. Чаще всего достаточно просто почты и письма.
Поэтому можно написать шаблон, который дублирует логику, но сохраняет авторизационные данные.
Тогда можно передавать на вход только email: если он есть – обрабатываем письмо, если нет – регистрируем новую почту и возвращаем её.
Tool_1 - это пример такого шаблона, который выполняет данную логику.
Он хранит в своем списке, который привязан к текстовому файлу данные об аккаунте почты.
И на вход принимает либо пустое значение - тогда регистрирует почту, либо почту - тогда ищет её в списке и получает последнее письмо.
Этот шаблон легко использовать как проек-в-проекте.
Case_2 - это наглядный пример шаблона, который использует Tool_1.
Выполняет целевые действия (регистрации почты и чтения последнего полученного письма).
Это шаблон который дублирует логику шаблона Case_1.
Просто убирает необходимость держать у себя в памяти данные авторизации.
Это реализация, которая доступна для понимания любому новичку, который начинает работать с ZennoPoster.
И сейчас уже с пониманием того, от чего мы отталкиваемся и как выглядит базовая реализация - будем строить что-то более сложное. При этом, думаю, предыдущих шаблонов уже достаточно для использования - можно бесконечно регистрировать email и читать входящие письма. Описанный подход легко адаптировать для любых других задач и других сервисов.
Выбор усложнения системы
Конечно, если хочется ещё усложнить – можно привязать к базе данных, добавить обработку ошибок (например, если письмо не пришло – подождать и попробовать снова), добавить дополнительное логирование и тп - нет предела совершенству, нет предела в построении сложных систем.
Важный принцип в программировании - инкапсуляция - скрывать сложную логику.
Мы можем сложность скрывать как в общем коде, так и в других мелких шаблонах.
Все индивидуально, зависит от мастерства и опыта разработчика.
Вот мы плавно перешли к тому, что если наша система взаимосвязанных шаблонов работает через прокси (а я часто использую вот эти прокси – , промо-код на скидку:
Я решил пойти другим путем – использовать webhook, нечто вроде API.
Тогда можно работать только через post/get-запросы, а всю логику базы данных оставить на стороне сервиса, минимизируя ошибки и упрощая шаблоны.
Свой webhook я иногда пишу на PHP (ссылка на мою статью во внеконкурсных), но есть бесплатные open-source решения, которые можно использовать.
В данном случае – n8n (сейчас он популярен благодаря простому и быстрому созданию AI-агентов).
Ccылка на github проекта.
Настроил это так: добавил свой поддомен в Cloudflare, направив его на белый IP.
На локальной машине развернул Nginx, который проксирует запросы к сервису на порт 5678.
При запуске через командную строку указываю домен, чтобы корректно работал вебхук для Telegram-ботов.
Перед установкой можно бесплатно протестировать облачную версию – вот реф. ссылка – попробовать без необходимости разворачивать собственный сервер.
Также у меня локально установлена база данных MySQL.
Она используется моими вебхуками, которые дёргаются моими шаблонами, речь о которых пойдет ниже.
Данные доступа к MySQL настроил внутри n8n в разделе credentials.
Основная идея которая мною руководила - избавиться от работы с базой на уровне ZennoPoster.
Модель моих табличек в MySQL выглядит как на скриншоте ниже.
Для продолжения у тебя также должны быть такие таблички.
Также вполне вероятно, что я добавлю исходники шаблонов для настройки вебхука.
Предполагается, что импортироваться они будут в облачную версию N8N, это бесплатно, просто новичкам проще будет посмотреть, покликать прежде чем погружаться в установку и настройку своего сервера или компьютера.
При этом, у меня всё работает на локальном компьютере.
У меня просто опасения, что не у каждого есть белый IP, домен, чтобы сразу сходу проверить работоспособность - а отложив проверку решения может быть что больше никогда руки не дойдут погрузиться во все эти сложности.
Собственно ниже под спойлером скриншот как импортировать шаблон.
Необхоимо обратить внимание после импорта на кубики которые работают с базой данных.
В них необходимо выбрать credential для подключения к своей базе данных.
В этой базе данных должны быть таблички, которые описаны выше.
В каждом самом левом кубике можно найти ссылку своего вебхука.
Эту ссылку нужно подавать на вход шаблонам.
Логика шаблонов - продвинутый уровень
Worker_1 - использует WebHook_1, чтобы получать задачи на регистрацию почты.
Если задача получена - выполняет её и возвращает результат обратно.
Для выполнения задачи использует шаблон Action_1.
Worker_2 - использует WebHook_1, чтобы получать задачи на проверку почты.
Если задача получена - выполняет её и возвращает результат обратно.
Для выполнения задачи использует шаблон Action_2.
Шаблоны Worker_1 и Worker_2 - это рабочие лошадки.
Они запускается автоматически каждую минуту в ZennoPoster.
Их без проблем ожно разнести по разным серверам.
Case_3 - это пример шаблона, который общается с WebHook_2.
Он отправляет задачи на выполнение (например на регистрацию почты, на проверку почты).
Проверяет состояние задач.
И проходит заполнение формы (для чего ему и нужна была почта).
Проблема в том, что Case_3 не должен ничего знать о WebHook_2.
Не удобно так работать - нужно убрать сложность отдельно.
Case_3 ожидает что где-то по расписанию работают шаблоны Worker_1 и Worker_2
Логика взаимодействия выглядит примерно так:
Tool_2 - это шаблон, который призван решить проблему шаблона Case_3.
Он берет на себя общение с WebHook_2, а значит выполняет необходимую работу.
Хранит внутри себя ссылку на вебхук.
На вход принимает пустую строку (тогда ставит задачу на регистрацию почты, дожидается ответа, возвращает результат).
Либо принимает почту - тогда ставит задачу на получение письма, дожидается выполнения и возвращает письмо.
Другими словами это тот же Tool_1, только адаптирован под работу с вебхуком.
Tool_2 ожидает что где-то по расписанию работают шаблоны Worker_1 и Worker_2
Case_4 - это шаблон, который ничего не знает о вебхуках.
Он просто вызывает через проект-в-проекте шаблон Tool_2 и ожидает от него необходимый результат.
Естественно, чтобы всё работало где-то по расписанию должны работать Worker_1 и Worker_2.
В результате получилось примерно такое взаимодействие:
Демонстрация по-шагам
Для наглядного понимания всего процесса я подготовил видео.
В нем разобрана структура шаблонов, показаны примеры их использования и взаимодействия.
Думаю каждому кто читает эту статью важно посмотреть это видео.
Это позволит расширить понимание о том, как все описанное в статье работает на практике.
Это не просто теория. После просмотра у тебя будет понимание, как ты можешь внедрить эту логику в свои проекты.
Все шаблоны, которые упоминались выше находятся во вложении тут.
А тем временем я прехожу к схеме, когда шаблон Case не нужен, так как его функцию будет выполнять телеграм.
Именно телеграм посредством бота будет передавать данные пользователю.
А пользователь посредством телеграм будет передавать команды на исполнение Зеннопостеру.
И... Пользователь может никогда и не узнает, что его задачи решал ZennoPoster и какая-то сложная архитектура...
Пользователю это и не важно, важно это только разработчикам подобных решений.
А пользователь... Он хочет просто получить email, в идеальном случае бесплатно и без ограничений.
Также хочет иметь возможности проверять наличие входящих писем на эту почту...
Вишенка на торте - готовый телеграм бот
Ссылка на самого бота тут: @TempMyEmailBot - возможно можно будет покликать, посмотреть как это в реальности работает.
Исходники шаблонов для ZennoPoster которые будут обслуживать очередь и рабочие процессы вебхуков n8n можно найти в прикрепленных сообщениях или тут.
Какие-то инструкции, по-ходу дела я написал в текстовых файлах внутри архивов с шаблонами, чтобы напомнить что должно быть.
В целом, бота можно не смотреть - что-то подобное скоро может быть запущено у тебя своё личное.
Но, скриншот прикольный - из-за чего добавлю его для истории, кто знает, вдруг найдется время и мотивация поддерживать и расширять проект в будущем.
Вот примерно так у меня выглядят таблички, которые обслуживают базу данных.
Запросы, которые помогут их создать - ниже под спойлером.
Значит что ещё стоит добавить - это то, что шаблоны в архиве, который имеет отношение к телеграм боту, должны работать в ZennoPoster, стоять на расписании например.
Думаю, что можно даже как-то их подкорректировать, поменять им логику, чтобы завершали работу только когда обработали всю очередь задач, или что-то в этом роде.
А как пользоваться?
Добавляем dll - без них никак.
А остальное - зависит от варианта, какой функционал нужен.
Для новичков:
Для тех, кто решил иметь дело с вебхуком:
Для тех, кому нужен свой телеграм бот:
И на конец
В свою очередь, когда я писал шаблоны, и описывал их взаимодействие, я старался максимально упростить, как только мог.
Но, если продолжать упрощать, например убрав какие-то проверки, то вся схема работы могла становиться не рабочей.
Также я понимаю, что не охватил множество технических аспектов, что-то даже специально упустил, посчитал не уместным.
Из-за чего даю решение в виде "как есть", осознаю, что оно может стать не рабочим в любой момент.
Надеюсь, что логика на описание которой я потратил все это время кому-то пригодится.
Если же есть вопросы, которые появляются сами по себе, из-за того, что как-то не полно раскрыл тему - пишите - время от времени буду на них отвечать в этой теме.
Спасибо, что нашли время изучить мою статью!
Решение я написал несколько месяцев назад.
Друзья и знакомые уже зарегистрировали и использовали десятки тысяч email.
Сейчас схема рабочая.
Но, такой заголовок - это первое что пришло на ум, когда решился писать статью.
В реальности термин "бесконечные" спорный - ведь в любой момент все может измениться.
Не нужно обращать на него внимание, как и написаное в статье не стоит принимать как "истину в последней инстанции".
Я могу ошибаться и заблуждаться, и даже не правильно ставить запятые в тексте - это нормально.
В случае необходимости читать более грамотный текст - стоит просто отправить статью какому-то чату-GPT, он быстро исправит все ошибки, сделает сокращенную версию, и даже в случае необходимости, сможет расширить те пункты, о которых я даже не подумал.
От автора
Уже почти 10 лет я использую ZennoPoster и помог многим разобраться в его тонкостях.
Кто знает, может, это и единственная причина, почему мою статью читаешь и ты...
Более подробное представление себя я давал в предыдущих конкурсах.
Если твой путь только начинается — рекомендую ознакомиться с моими работами:
- 13.05.2017 Работа с API Youtube
- 24.09.2017 Автоматизация в Pinterest
О чём здесь
В основном здесь будет пример построения сложной системы.
На сколько стоит вникать в сложности - решит каждый себе самостоятельно.
Будет предоставлено готовое решение регистрации почты и получения последнего письма.
Что получишь
Пример реализации TelegramBot:
- Отправляешь в TelegramBot команду +, а он тебе возвращает email.
- Отправляешь еще раз + — а он в ответ последнее письмо.
- Отправляешь - — очистит очередь обработки
- Шаблон который регистрирует криптовалютную почту.
- Шаблон который возвращает последнее письмо на этой почте.
- Все остальные шаблоны и примеры о которых говорится в публикации.
- Исходники проектов, которые можно просто импортировать для поднятия вебхуков.
- Представление о логике построении сложных систем.
Отделяю email от его обслуживания
Представь себе, что вместо ZennoPoster работает живой человек, задача которого — брать email, выполнять какие-то действия, после чего авторизоваться в этом email и проверить, пришло ли письмо.
Всё это требует времени.
А если мы еще и скажем, что не хотим давать этому человеку пароль от email?
Конечное решение — система с нулевым доверием.
В качестве примера будет использоваться TelegramBot.
Но, в целом бывает полезно сделать так, чтобы один шаблон в ZennoPoster не имел больше информации, чем ему нужно в текущий момент.
Актуальность
Сообществу форума нет необходимости объяснять, насколько важно всегда иметь под рукой работающие email.
В идеале — в бесконечном количестве.
Частично эту проблему решают сервисы временной почты.
Также люди ищут брошенные домены, продают их.
Многие сервисы временной почты закрываются (Копеечка - помним и скорбим).
Регистрация же на Gmail, Yahoo, Outlook сопровождается капчами, SMS-подтверждениями, банами по IP и не только.
Новичкам которые пытаются что-то автоматизировать используя ZennoPoster это может создавать кучу проблем.
А также работа с почтой может быть затратной: покупка аккаунтов, оплата решений капч или CapMonster2, оплата приватных или мобильных прокси, оплата виртуальных номеров для SMS.
А ведь это мы еще не говорим о потенциальных потерях...
Реальность
Уверен, что такие истории не редкость.Совсем недавно произошла реальная история. Один знакомый год назад купил Gmail-аккаунты и использовал их по назначению. Через некоторое время Google заблокировал их без возможности восстановления. Такая ситуация привычна для покупных аккаунтов. Но в этот раз проблема была серьезнее: на аккаунты, которые зарегистрированы на эти почты, в октябре начислили Airdrop — по несколько десятков долларов на каждом аккаунте. А сервис, с которого пришли деньги, не позволил сменить почту. Результат? Потерянный потенциальный доход, потери пол года работы, потеря денег на обслуживание аккаунтов (прокси, сервера, время).
Возможно даже у тебя был подобный случай — напиши об этом в комментариях.
Альтернатива
Есть ли альтернатива? Да! Это децентрализованная криптовалютная почта.
- Нет паролей — доступ получают только владельцы приватных ключей.
- Нет капчи — нет расходнов на её распознавание
- Трастовость — в криптовалютных проектах такой email считается надежным (но это не точно).
Название указывать не буду, но любопытный читатель найдет ссылку внутри шаблонов, а вот Google не узнает об автоматизации этого сервиса.
Сейчас нет ни капчи, ни номера телефона, ни SMS – только генерация приватного ключа и подпись сообщения.
В моем решении они будут сгенерированы без браузера и Metamask.
Само взаимодействие с сервисом исключительно на post/get запросах.
Реализовано в шаблонах Action_1 и Action_2 - забирай и изучай тонкости реализации.
В этой статье технического разбора этой реализации не будет - вдруг завтра сервис закроется, тогда моя статья станет не актуальной, так что направление статьи заточено под вечнозеленую тему - как строить сложные решения.
Нужные DLL и пример кода
Чтобы всё заработало необходимо взять библиотеки, о которых уже расказывал пользователь @Zedx.
Nethereum - Работаем с блокчейном напрямую
NBitcoin - Генератор/чекер криптовалютных кошельков -
Забрасываю библиотеки в папку ExternalAssemblies: C:\Путь к Зенно\ZennoPoster Pro V7\7.7.18.1\Progs\ExternalAssemblies
И добавляю на них ссылки в GAS.
- Nethereum.Accounts.dll
- Nethereum.HdWallet.dll
- Nethereum.Signer.dll
- Nethereum.Util.dll
- Nethereum.Hex.dll
- System.Numerics.dll
- netstandard.dll 2.0.0
Дальше в Директивы using и Общий код добавляю:
C#:
using NBitcoin;
using Nethereum.Signer;
using Nethereum.HdWallet;
using Nethereum.Util;
using Nethereum.Hex.HexConvertors.Extensions;
using System.Security.Cryptography;
C#:
var wallet = new Wallet(Wordlist.English, WordCount.Twelve);
var seed = wallet.Words;
return string.Join(" ", seed);
C#:
string seed = "тут 12 слов фразы";
var wallet_obj = new Wallet(seed, null);
string wallet = wallet_obj.GetAccount(0).Address;
wallet = wallet.ToLower();
return wallet;
C#:
string seed = "тут 12 слов фразы";
string sign_message = "тут сообщение которое нужно подписать";
string sign = string.Empty;
var wallet = new Wallet(seed, null);
var pk = wallet.GetAccount(0).PrivateKey;
var signer = new EthereumMessageSigner();
sign = signer.EncodeUTF8AndSign(sign_message, new EthECKey(pk));
return sign;
Логика шаблонов - начальный уровень
В Action_1 – проходит регистрацию аккаунта
Здесь генерируется SEED фраза, подписывается сообщение.
И чтобы почта имела возможность принимать письма - читается входящее письмо.
Результатом выполнения будет json с аккаунтом (seed, wallet, email и данные авторизации).
В Action_2 – Проходит авторизацию
Естественно, если она не пройдена, получение последнего письма и его удаление из аккаунта.
Этот шаблон принимает на вход json который был получен шаблоном Action_1.
На выходе отдает json с информацией о письме (кто отправил, когда отправил, какая тема письма, какой html письма).
Эти шаблоны можно использовать в проект-в-проекте, передавая результат первого во второй.
Case_1 - показывает как практически можно использовать шаблоны Action_1 и Action_2.
Пример строится на заполнении формы при регистрации на сайте.
В нем происходит весь путь от получения почты до получения письма.
И его очевидная проблема - это хранение на своей стороне данных об авторизации, seed фразы, которая явно не нужна в этом шаблоне.
Не всегда хочется держать под рукой данные авторизации. Чаще всего достаточно просто почты и письма.
Поэтому можно написать шаблон, который дублирует логику, но сохраняет авторизационные данные.
Тогда можно передавать на вход только email: если он есть – обрабатываем письмо, если нет – регистрируем новую почту и возвращаем её.
Tool_1 - это пример такого шаблона, который выполняет данную логику.
Он хранит в своем списке, который привязан к текстовому файлу данные об аккаунте почты.
И на вход принимает либо пустое значение - тогда регистрирует почту, либо почту - тогда ищет её в списке и получает последнее письмо.
Этот шаблон легко использовать как проек-в-проекте.
Case_2 - это наглядный пример шаблона, который использует Tool_1.
Выполняет целевые действия (регистрации почты и чтения последнего полученного письма).
Это шаблон который дублирует логику шаблона Case_1.
Просто убирает необходимость держать у себя в памяти данные авторизации.
Это реализация, которая доступна для понимания любому новичку, который начинает работать с ZennoPoster.
И сейчас уже с пониманием того, от чего мы отталкиваемся и как выглядит базовая реализация - будем строить что-то более сложное. При этом, думаю, предыдущих шаблонов уже достаточно для использования - можно бесконечно регистрировать email и читать входящие письма. Описанный подход легко адаптировать для любых других задач и других сервисов.
Выбор усложнения системы
Конечно, если хочется ещё усложнить – можно привязать к базе данных, добавить обработку ошибок (например, если письмо не пришло – подождать и попробовать снова), добавить дополнительное логирование и тп - нет предела совершенству, нет предела в построении сложных систем.
Важный принцип в программировании - инкапсуляция - скрывать сложную логику.
Мы можем сложность скрывать как в общем коде, так и в других мелких шаблонах.
Все индивидуально, зависит от мастерства и опыта разработчика.
Вот мы плавно перешли к тому, что если наша система взаимосвязанных шаблонов работает через прокси (а я часто использую вот эти прокси – , промо-код на скидку:
SKOHBD_717909
), нам может быть полезно настроить её так, чтобы один ZennoPoster работал на сервере (VPS для своих задач беру тут) и обрабатывал задачи на регистрацию почты и проверку входящих писем. Другими словами - разделить ответственность. Это полезно, если прокси привязаны к конкретному IP, чтобы никто другой не использовал оплаченный нами трафик. Обычно для синхронизации используют базу MySQL напрямую с ZennoPoster, правда это усложняет логику и увеличивает время разработки.Я решил пойти другим путем – использовать webhook, нечто вроде API.
Тогда можно работать только через post/get-запросы, а всю логику базы данных оставить на стороне сервиса, минимизируя ошибки и упрощая шаблоны.
Свой webhook я иногда пишу на PHP (ссылка на мою статью во внеконкурсных), но есть бесплатные open-source решения, которые можно использовать.
В данном случае – n8n (сейчас он популярен благодаря простому и быстрому созданию AI-агентов).
Ccылка на github проекта.
Настроил это так: добавил свой поддомен в Cloudflare, направив его на белый IP.
На локальной машине развернул Nginx, который проксирует запросы к сервису на порт 5678.
При запуске через командную строку указываю домен, чтобы корректно работал вебхук для Telegram-ботов.
Перед установкой можно бесплатно протестировать облачную версию – вот реф. ссылка – попробовать без необходимости разворачивать собственный сервер.
Также у меня локально установлена база данных MySQL.
Она используется моими вебхуками, которые дёргаются моими шаблонами, речь о которых пойдет ниже.
Данные доступа к MySQL настроил внутри n8n в разделе credentials.
Основная идея которая мною руководила - избавиться от работы с базой на уровне ZennoPoster.
Модель моих табличек в MySQL выглядит как на скриншоте ниже.
Для продолжения у тебя также должны быть такие таблички.
Запросы на создания табличек в MySQL:
CREATE TABLE `tasks` (
`md5` varchar(32) NOT NULL,
`status` tinyint(3) unsigned NOT NULL,
`timestamp` int(10) unsigned NOT NULL,
PRIMARY KEY (`md5`),
UNIQUE KEY `md5` (`md5`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `emails` (
`md5` varchar(32) NOT NULL,
`email` varchar(255) NOT NULL,
`data` json NOT NULL,
`status` tinyint(3) unsigned NOT NULL,
`timestamp` int(10) unsigned NOT NULL,
PRIMARY KEY (`md5`),
UNIQUE KEY `md5` (`md5`),
UNIQUE KEY `email` (`email`),
CONSTRAINT `key1` FOREIGN KEY (`md5`) REFERENCES `tasks` (`md5`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `mails` (
`md5` varchar(32) NOT NULL,
`email` varchar(255) NOT NULL,
`data` json NOT NULL,
`timestamp` int(10) unsigned NOT NULL,
PRIMARY KEY (`md5`),
UNIQUE KEY `md5` (`md5`),
KEY `email` (`email`),
CONSTRAINT `key2` FOREIGN KEY (`email`) REFERENCES `emails` (`email`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
В левом углу кликаем на крестик и выбираем Credential:
Дальше в поле ввода пишем MySQL.
После чего кликаем на кнопку Continue.
Дальше просто указываем свои данные авторизации в базе.
Дальше в поле ввода пишем MySQL.
После чего кликаем на кнопку Continue.
Дальше просто указываем свои данные авторизации в базе.
Также вполне вероятно, что я добавлю исходники шаблонов для настройки вебхука.
Предполагается, что импортироваться они будут в облачную версию N8N, это бесплатно, просто новичкам проще будет посмотреть, покликать прежде чем погружаться в установку и настройку своего сервера или компьютера.
При этом, у меня всё работает на локальном компьютере.
У меня просто опасения, что не у каждого есть белый IP, домен, чтобы сразу сходу проверить работоспособность - а отложив проверку решения может быть что больше никогда руки не дойдут погрузиться во все эти сложности.
Собственно ниже под спойлером скриншот как импортировать шаблон.
Необхоимо обратить внимание после импорта на кубики которые работают с базой данных.
В них необходимо выбрать credential для подключения к своей базе данных.
В этой базе данных должны быть таблички, которые описаны выше.
В каждом самом левом кубике можно найти ссылку своего вебхука.
Эту ссылку нужно подавать на вход шаблонам.
Логика шаблонов - продвинутый уровень
Worker_1 - использует WebHook_1, чтобы получать задачи на регистрацию почты.
Если задача получена - выполняет её и возвращает результат обратно.
Для выполнения задачи использует шаблон Action_1.
Worker_2 - использует WebHook_1, чтобы получать задачи на проверку почты.
Если задача получена - выполняет её и возвращает результат обратно.
Для выполнения задачи использует шаблон Action_2.
Шаблоны Worker_1 и Worker_2 - это рабочие лошадки.
Они запускается автоматически каждую минуту в ZennoPoster.
Их без проблем ожно разнести по разным серверам.
Case_3 - это пример шаблона, который общается с WebHook_2.
Он отправляет задачи на выполнение (например на регистрацию почты, на проверку почты).
Проверяет состояние задач.
И проходит заполнение формы (для чего ему и нужна была почта).
Проблема в том, что Case_3 не должен ничего знать о WebHook_2.
Не удобно так работать - нужно убрать сложность отдельно.
Case_3 ожидает что где-то по расписанию работают шаблоны Worker_1 и Worker_2
Логика взаимодействия выглядит примерно так:
Tool_2 - это шаблон, который призван решить проблему шаблона Case_3.
Он берет на себя общение с WebHook_2, а значит выполняет необходимую работу.
Хранит внутри себя ссылку на вебхук.
На вход принимает пустую строку (тогда ставит задачу на регистрацию почты, дожидается ответа, возвращает результат).
Либо принимает почту - тогда ставит задачу на получение письма, дожидается выполнения и возвращает письмо.
Другими словами это тот же Tool_1, только адаптирован под работу с вебхуком.
Tool_2 ожидает что где-то по расписанию работают шаблоны Worker_1 и Worker_2
Case_4 - это шаблон, который ничего не знает о вебхуках.
Он просто вызывает через проект-в-проекте шаблон Tool_2 и ожидает от него необходимый результат.
Естественно, чтобы всё работало где-то по расписанию должны работать Worker_1 и Worker_2.
В результате получилось примерно такое взаимодействие:
Демонстрация по-шагам
Для наглядного понимания всего процесса я подготовил видео.
В нем разобрана структура шаблонов, показаны примеры их использования и взаимодействия.
Думаю каждому кто читает эту статью важно посмотреть это видео.
Это позволит расширить понимание о том, как все описанное в статье работает на практике.
Это не просто теория. После просмотра у тебя будет понимание, как ты можешь внедрить эту логику в свои проекты.
Все шаблоны, которые упоминались выше находятся во вложении тут.
А тем временем я прехожу к схеме, когда шаблон Case не нужен, так как его функцию будет выполнять телеграм.
Именно телеграм посредством бота будет передавать данные пользователю.
А пользователь посредством телеграм будет передавать команды на исполнение Зеннопостеру.
И... Пользователь может никогда и не узнает, что его задачи решал ZennoPoster и какая-то сложная архитектура...
Пользователю это и не важно, важно это только разработчикам подобных решений.
А пользователь... Он хочет просто получить email, в идеальном случае бесплатно и без ограничений.
Также хочет иметь возможности проверять наличие входящих писем на эту почту...
Вишенка на торте - готовый телеграм бот
Ссылка на самого бота тут: @TempMyEmailBot - возможно можно будет покликать, посмотреть как это в реальности работает.
Исходники шаблонов для ZennoPoster которые будут обслуживать очередь и рабочие процессы вебхуков n8n можно найти в прикрепленных сообщениях или тут.
Какие-то инструкции, по-ходу дела я написал в текстовых файлах внутри архивов с шаблонами, чтобы напомнить что должно быть.
В целом, бота можно не смотреть - что-то подобное скоро может быть запущено у тебя своё личное.
Но, скриншот прикольный - из-за чего добавлю его для истории, кто знает, вдруг найдется время и мотивация поддерживать и расширять проект в будущем.
Вот примерно так у меня выглядят таблички, которые обслуживают базу данных.
Запросы, которые помогут их создать - ниже под спойлером.
SQL:
CREATE TABLE `tg_users` (
`user_id` bigint(20) NOT NULL,
`status` int(1) unsigned NOT NULL,
`timestamp` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`user_id`),
UNIQUE KEY `user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `emails` (
`md5` varchar(32) NOT NULL,
`email` varchar(255) DEFAULT NULL,
`data` json DEFAULT NULL,
`status` int(10) unsigned NOT NULL,
`timestamp` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`md5`),
UNIQUE KEY `md5` (`md5`),
UNIQUE KEY `email` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `mails` (
`md5_mail` varchar(32) NOT NULL,
`md5_email` varchar(32) NOT NULL,
`data` json DEFAULT NULL,
`status` int(11) NOT NULL,
`timestamp` int(10) unsigned DEFAULT NULL,
PRIMARY KEY (`md5_mail`),
UNIQUE KEY `md5_mail` (`md5_mail`),
KEY `md5_email` (`md5_email`),
CONSTRAINT `key2` FOREIGN KEY (`md5_email`) REFERENCES `emails` (`md5`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `tasks_create` (
`user_id` bigint(20) NOT NULL,
`status` int(1) unsigned NOT NULL,
`timestamp` int(10) unsigned DEFAULT NULL,
PRIMARY KEY (`user_id`),
UNIQUE KEY `user_id` (`user_id`),
CONSTRAINT `key1` FOREIGN KEY (`user_id`) REFERENCES `tg_users` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `tasks_read` (
`md5_email` varchar(32) NOT NULL,
`status` int(1) unsigned NOT NULL,
`timestamp` int(10) unsigned DEFAULT NULL,
PRIMARY KEY (`md5_email`),
CONSTRAINT `key3` FOREIGN KEY (`md5_email`) REFERENCES `emails` (`md5`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `user_email` (
`id_user` bigint(20) NOT NULL,
`md5_email` varchar(32) NOT NULL,
PRIMARY KEY (`id_user`,`md5_email`),
UNIQUE KEY `id_user` (`id_user`,`md5_email`),
UNIQUE KEY `md5_email` (`md5_email`),
CONSTRAINT `key4` FOREIGN KEY (`id_user`) REFERENCES `tg_users` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT `key5` FOREIGN KEY (`md5_email`) REFERENCES `emails` (`md5`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Значит что ещё стоит добавить - это то, что шаблоны в архиве, который имеет отношение к телеграм боту, должны работать в ZennoPoster, стоять на расписании например.
Думаю, что можно даже как-то их подкорректировать, поменять им логику, чтобы завершали работу только когда обработали всю очередь задач, или что-то в этом роде.
А как пользоваться?
Добавляем dll - без них никак.
А остальное - зависит от варианта, какой функционал нужен.
Для новичков:
- Берем шаблон Case_2 в качестве примера.
- Заменяем часть по заполнению почты на свой сайт на котором регистрируемся.
- Решение возьмет на себя проблему регистрации почты и получения писем.
Для тех, кто решил иметь дело с вебхуком:
- Создаем в базе данных таблички.
- Импортируем рабочий процесс в n8n (есть в приложеном архиве).
- Проверяем, чтобы данные доступа к базе подтянулись корректные.
- Запускаем процес.
- Копируем адрес вебхука.
- Заполняем адрес вебхука в переменной шаблона Tool_2.
- Заполняем адрес второго вебхука в шаблонах Worker_1 и Worker_2.
- В расписание ZennoPoster добавляем два шаблоны Worker_1 и Worker_2.
- Берем шаблон Case_4 и заменяем часть по заполнению почты на свой сайт, на котором регистрируемся.
- Работу по обработке почты возьмут на себя шаблоны которые работают по расписанию, общаться будут через вебхук.
- Как результат Case_4 может быть запущен на разных серверах, а Worker_1 и Worker_2 будут работать на одном сервере.
- Получаем систему, которую можно масштабировать (работа с почтой как пример - а ведь действия могут быть разные, например подписывание транзакций, регистрация каких-то других аккаунтов, постинг и тп).
Для тех, кому нужен свой телеграм бот:
- Создаем ключ телеграм бота и добавляем его в n8n.
- Создаем в базе данных таблички.
- Добавляем доступ к базе в n8n.
- Импортируем рабочие процессы в n8n (есть в приложеном архиве).
- Проверяем, чтобы данные доступа к базе подтянулись корректные.
- Проверяем, что данные телеграм аккаунта подтянулись корректные.
- Запускаем процесы содержащие в имени WebHook.
- Копируем адрес вебхука.
- Заполняем адрес вебхука в шаблонах Worker_3 и Worker_4.
- В расписание ZennoPoster добавляем два шаблоны Worker_3 и Worker_4.
- Переходим в своего телеграм бота.
- Отправляем ему /start
- После чего - отправляем ему + когда нужно получить почту.
- Отправляем ещё раз + если нужно прочитать письма.
- Если письмо ещё не пришло - снова шлем +.
- Если хотим изменить на другую почту - шлем - чтобы очистить очередь.
- После чего снова + тогда бот зарегистрирует новую почту.
И на конец
В свою очередь, когда я писал шаблоны, и описывал их взаимодействие, я старался максимально упростить, как только мог.
Но, если продолжать упрощать, например убрав какие-то проверки, то вся схема работы могла становиться не рабочей.
Также я понимаю, что не охватил множество технических аспектов, что-то даже специально упустил, посчитал не уместным.
Из-за чего даю решение в виде "как есть", осознаю, что оно может стать не рабочим в любой момент.
Надеюсь, что логика на описание которой я потратил все это время кому-то пригодится.
Если же есть вопросы, которые появляются сами по себе, из-за того, что как-то не полно раскрыл тему - пишите - время от времени буду на них отвечать в этой теме.
Спасибо, что нашли время изучить мою статью!
Вложения
-
640,9 КБ Просмотры: 64
-
82,7 КБ Просмотры: 50
Последнее редактирование: