Telegram-бот для управления инфраструктурой

[buldo]

А chat id для конкретного пользователя всегда постоянный?

[lavilav]

Да. По крайней мере был всегда так.

[frkbvfnjh]

chat id может измениться если изменить администратора группы, да и вообще, изменение любых настроек чата ведет вроде как к изменению id, но состав пользователей вроде можно менять. У нас короче точно несколько раз id менялся

[infcl]

Глупость говоришь.
У пользователей айди всегда один. Он выглядит примерно так: 334463248.
Когда ты создаешь беседу (или группу, если тебе так удобнее называть), у беседы будет айди примерно такого же вида, только со знаком минус.
Если ты зайдешь в настройки этой группы и сделаешь её публичной, применишь настройки, то эта группа превратится в так называемую супер-группу. У супергрупп айди всегда такого вида: -1001492481741.
С этого момента айди группы у тебя не поменяется, что бы ты с ней не делал (кроме удаления этой группы, очевидно).
Также, когда ты в первый раз устанавливаешь приватность группы на значение «Публичная» и применяешь настройки, телеграм присылает 2 сообщения (если это CallbackApi) или ты «вытягиваешь» это сообщение (если это LongPoolApi). Одно из этих сообщений (или оба, точно не помню) сообщение содержит поля «migrate_from_chat_id» и «migrate_to_chat_id»
Подробнее можешь прочитать в официальной документации: core.telegram.org/bots/api#message

[IRT]

А long-polling можно реализовать в Powershell? Дергать API каждую секунду не самый изящный вариант.

[IRT]

Вы ошибаетесь. Long-polling это установка соединения с API и ожидание команд с сервера. Соединение при этом не разрывается и команды бот получает мгновенно, а не через N секунд.
Если сделать GET к методу GetUpdates с параметром offset больше, чем последнее полученное сообщение, то GET повиснет в ожидании данных с сервера, пока не наступит таймаут.

[YegorVin]

Да ладно. Сервера телеграмма будут держать открытым соединения с тысячами серверов управляющими ботами?

[IRT]

Они же держат соединения с тысячами десктопных клиентов, у которых нет push. Как функционируют тысячи ботов, у которых нет внешнего ip и сертификата на webhook, но которые отвечают мгновенно, не через секунду?
Посмотрите документацию core.telegram.org/bots/api#getupdates
Они там прямым текстом пишут, что лучше использовать таймаут побольше. Видимо, потому что накладные расходы на обслуживание нового соединения куда больше, чем на поддержание открытого.

[YegorVin]

Я не вижу в описании что коннект может остаться открытым. Я сейчас как раз пишу ВК бота. Там я получаю через long pool обновления и соединение закрывается. Бот периодически (где то раз в секунду) стучится на их сервера за новыми обновлениями.

[IRT]

Да, после получения обновлений соединение закрывается и нужно устанавливать новое. Смысл в том, что при ожидании обновлений соединение остается открытым. Вы делаете GET запрос к серверу, а он вам не сразу отвечает, а только когда будут обновления, до этого соединение висит открытым. Так понятнее?

Telegram API приводит же ссылку на wiki:
en.wikipedia.org/wiki/Push_technology#Long_polling

With long polling, the client requests information from the server exactly as in normal polling, but with the expectation the server may not respond immediately. If the server has no new information for the client when the poll is received, instead of sending an empty response, the server holds the request open and waits for response information to become available. Once it does have new information, the server immediately sends an HTTP/S response to the client, completing the open HTTP/S Request. Upon receipt of the server response, the client often immediately issues another server request.

Когда вы просто дергаете сервер раз в секунду, это называется short poll, обычно это не рекомендуют делать, возрастает нагрузка на сервер, плюс обновления приходят не мгновенно, а с задержкой в секунду. Да еще и лишний трафик по сети гуляет, что критично в случае мобильных клиентов.

[YegorVin]

Да так понятнее спасибо.
И какой максимальный таймаут допускает API телеграмма или сколько угодно долго?

[IRT]

Incoming updates are stored on the server until the bot receives them either way, but they will not be kept longer than 24 hours.

Раз в 24 часа соединение в любом случае прервется, поскольку они удаляют обновления, если их не забрали за сутки. Я обычно ставлю 5 минут, если после пяти минут ничего не пришло, то соединение закрывается и открывается новое. Так и трафик небольшой, и нагрузка на API слабая.

[Andrey_O]

Спасибо, действительно пропустил в одном месте. Смысл написания на PS был как раз в том, чтобы продемонстрировать подход, который мы использовали (уверен, что кому-то это будет полезно) + показать саму реализацию кода (функции, условия, обработка — опять таки, для тех, у кого не очень богатый опыт работы с PS)
Но идею с библиотекой возьму на заметку

[MegaShIzoID]

есть враперы на чем угодно, можно ими пользоваться, но использование голого апи более чем удобно, да и нет там ничего сложного, городить для этого библиотеку — глупо

[MegaShIzoID]

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

[Raivon]

Правильно я понимаю, что в настоящий момент нет возможности ограничить список chat_id через настройки бота при помощи BotFather? Как вы оцениваете вероятность нахождения бота и его DDoS? (Не придирки )

[Andrey_O]

Функционал ограничения через BotFather отсутствует. Кейсы с DDoS мы не проверяли, но точно могу сказать, что за время работы бота было несколько случаев, что ему писали с неизвестных chat_id. В целом, отказ бота возможен по причине утечки памяти

[werwolflg]

Так ограничивать через BotFather и не надо, легко же решается созданием списка с разрешенными chat_id, и проверять от кого пришло сообщение. Если этого chat_id нет в списке, то игнорировать его.

[Andrey_O]

Все верно, но это не сможет помешать кому угодно писать боту (да, он может не отвечать, но сообщения все равно будут обрабатываться)

[akio_alx]

ну вообще BotFather не для этого. Вы chat_id отфильтровываете в коде по любым вашим критериям. Поэтому все боты могут быть секторными по доступу.
DDoS — пробовал :) Для начала сервера телеграмма просто не пропустят ваши сообщения с ваших айди в несметном множестве. А если берем очень много id (которые кстати должны быть созданы и все они должны нажать старт в вашем боте, только потом они могут отправлять хоть что то в этот канал) — смотрим пункт выше — фильтруем по айдишникам. равносильно drop в iptables.