An existing application has webhooks set up with the Telegram API.
A newer application want to use the same bot to send messages, eventually with the same named action webhook.
Initially, one would want to first query existing webhooks to identify existing ones, then possibly delete them, based on the increasing complexity of the operating context. The telegram API documentation does not appear to have methods for such actions.
A) can one query one's bot webhooks and delete them?
In any instance, the new server will have its own certificate for TLS communications.
curl -F "url=https://b.example.online/<WEBHOOKLOCATION>" https://api.telegram.org/bot<YOURTOKEN>/setWebhook
B) If one sets a new webhook with the same action (or webhooklocation in Telegram-speak) name, does that kill the existing ones, say
curl -F "url=https://a.example.online/<WEBHOOKLOCATION>" https://api.telegram.org/bot<YOURTOKEN>/setWebhook
or will the notifications be sent to two webhooks (i.e. the combination of certified URL and action name are considered a unique object) ?
C) what happens to the basic webhooks /start /help etc. ? Are they responded to by the Telegram servers if webhooks not present? Again, can they have multiple certified domain destinations to the same action
One avenue is to revoke the token #BotFather which probably kills the related webhooks. The new token allows webhook creation anew.
There is a deleteWebhook action though not documented at the official documentation link
Through trial an error, the conclusion is that only one webhook exists per bot. Having set different webhooks for different apps with the same bot, only the last one is active (the old one is deleted).
Related
I'm trying to write a simple server side script that will run every once in a while and check for new messages in certain Telegram channels. I've created a bot, but it looks like a bot can't me a member of a channel, so bot API is of no use here. So what I fugured I need to do is to write a very basic set of requests to do authentication with my own credentials and then fetch messages from certain channels I'm subscribed to and then check if any new messages are there.
Is it possible to do this on a very basic level with HTTP requests, without having to learn and use bot frameworks and such?
I wrote a piece of code which sends messages to a Telegram bot. In order to do so, I use the chat_id of the last conversation retrieved via the getUpdates method.
id = requests.get(f"https://api.telegram.org/bot{token}/getUpdates").json()['result'][-1]['message']['chat']['id']
My understanding is that the a conversation exists if someone started one with the bot via /start.
How can I initiate, from my code, a conversation to make sure a chat_id is available? (= that there is a conversion I can query).
I am also sure that the conversations, should they exist, are not kept indefinitely (this is another reason why requesting an update can yield empty results)
My understanding is that the a conversation exists if someone started one with the bot via /start.
Yes, conversation is always initiated by a user:
Bots can't initiate conversations with users. A user must either add them to a group or send them a message first. People can use telegram.me/ links or username search to find your bot.
Note that /start is not the only option here.
If you try to send a message for user, who didn't start conversation with bot, you will receive something like this: {"ok":false,"error_code":400,"description":"Bad Request: chat not found"}.
How can I initiate, from my code, a conversation to make sure a chat_id is available? (= that there is a conversion I can query).
Normally, you shouldn't worry about that. Bot does not query specific user actions/requests with getUpdates, it queries all interactions from all users and then decides what to do according to internal logic you provide.
You may want to store information about users and/or their requests in a database every time you receive an Update from particular user in getUpdates.
Based on that, bot can make a decision to send for example, a message to him.
I am also sure that the conversations, should they exist, are not kept indefinitely (this is another reason why requesting an update can yield empty results)
Yes, docs clearly state that
Incoming updates are stored on the server until the bot receives them either way, but they will not be kept longer than 24 hours.
An Update on a Telegram servers is an entity with a short life period.
If you haven't saved information about existing users, or lost a database, there's no way to retrieve that data from telegram servers.
P.S.: as a side note, I'd suggest using long polling, as Telegram Bot API is designed to be used with long polling if you're using getUpdates. The most important thing is the timeout request parameter of getUpdates method:
(timeout is) Timeout in seconds for long polling. Defaults to 0, i.e. usual short polling. Should be positive, short polling should be used for testing purposes only.
As written in question, you're using short polling.
We have created Robot on hipchat and yammer with hubot, and they worked very well.
Recently, our team want to create a bot using hubot on Microsoft Teams, but met some problems.
I read the guide document and find that we should first allow external apps in Microsoft Teams .We should ask our Microsoft Admin team to help to open this on. Now, we are review this with our security team about this.
There is something I want to get from you:
1.I find if I want to active the hubot, I should first set an endpoint, what is this used for? Why should we set this?
When we enterprise hubot with hipchat and yammer, we just need an account, set the user name and password, tell hubot the group
Name we want hubot join, and it worked like a normal user.
2.I found “#robot.router.post #endpoint, #connector.listen()” in the code,
So, how the botbuilder listen,and where it listen?
3.Are messages all transport by http? Is it safe enough?
I just went through setting up our Hubot in teams as we will be moving from Hipchat and thought I could answer some of these questions.
The endpoint is used to send messages to your bot since it does not join as a user like Hipchat. When run with the botframework adapter /api/messages is used for communicating with your bot by Microsoft.
I'm not certain where in the code it listens but you have to # mention the bot in order for the app in teams to send the message to the bot's endpoint
The endpoint has to be HTTPS, meaning you have to proxy Hubot. The endpoint also has to be publicly available, or at least available to the Microsoft IP range. However, I found there is authentication that happens:
while anyone can technically post to your api/messages endpoint, the message coming in has a JWT token signed by AAD to verify that it came from a proper source. The botbuilder SDK (package that this adapter relies on) does this check for every message. Every response is also authorized with a JWT token that your bot retrieves from AAD for us to verify as well.
Reference:
https://github.com/Microsoft/BotFramework-Hubot/issues/25#issuecomment-402223551
I'm trying to get started implementing Web Push in one of my apps. In the examples I have found, the client's endpoint URL is generally stored in memory with a comment saying something like:
In production you would store this in your database...
Since only registered users of my app can/will get push notifications, my plan was to store the endpoint URL in the user's meta data in my database. So far, so good.
The problem comes when I want to allow the same user to receive notifications on multiple devices. In theory, I will just add a new endpoint to the database for each device the user subscribes with. However, in testing I have noticed that endpoints change with each subscription/unsubscription on the same device. So, if a user subscribes/unsubscribes several times in a row on the same device, I wind up with several endpoints saved for that user (all but one of which are bad).
From what I have read, there is no reliable way to be notified when a user unsubscribes or an endpoint is otherwise invalidated. So, how can I tell if I should remove an old endpoint before adding a new one?
What's to stop a user from effectively mounting a denial of service attack by filling my db with endpoints through repeated subscription/unsubscription?
That's more meant as a joke (I can obvioulsy limit the total endpoints for a given user), but the problem I see is that when it comes time to send a notification, I will blast notification services with hundreds of notifications for invalid endpoints.
I want the subscribe logic on my server to be:
Check if we already have an endpoint saved for this user/device combo
If not add it, if yes, update it
The problem is that I can't figure out how to reliably do #1.
I will just add a new endpoint to the database for each device the user subscribes with
The best approach is to have a table like this:
endpoint | user_id
add an unique constraint (or a primary key) on the endpoint: you don't want to associate the same browser to multiple users, because it's a mess (if an endpoint is already present but it has a different user_id, just update the user_id associated to it)
user_id is a foreign key that points to your users table
if a user subscribes/unsubscribes several times in a row on the same device, I wind up with several endpoints saved for that user (all but one of which are bad).
Yes, unfortunately the push API has a wild unsubscription mechanism and you have to deal with it.
The endpoints can expire or can be invalid (or even malicious, like android.chromlum.info). You need to detect failures (using the HTTP status code, timeouts, etc.) when you try to send the push message from your application server. Then, for some kind of failures (permanent failures, like expiration) you need to delete the endpoint.
What's to stop a user from effectively mounting a denial of service attack by filling my db with endpoints through repeated subscription/unsubscription?
As I described above, you need to properly delete the invalid endpoints, once you realize that they are expired or invalid. Basically they will produce at most one invalid request. Moreover, if you have high throughput, it takes only a few seconds for your server to make requests for thousands of endpoints.
My suggestions are based on a lot of experiments and thinking done when I was developing Pushpad.
Another way is to have a keep alive field on you server and have your service worker update it whenever it receives a push notification. Then regularly purge endpoints which haven't been responded to recently.
I saw on internet that there is some programs that can use Telegram CLI.
I want to choose between them
for Telegram bot API there is much more documents explaining its functionality, but for CLI there isn't much that explains its features
it seems the only way to know about is to experiment with it.
unfortunately i don't have a linux distro installed on my pc so experimenting isn't an option right know.
so I thought to ask from people who already used it
I know about Telegram bot api, its powers and its limitations
here is my questions:
what can I do using Telegram CLI that I can't do with with bot api, and vice versa?
Telegram bot API:
do not require to register new Telegram account, so you don't need to have another phone number;
bot cannot write to user first, only after user sends a first message to bot;
already has the commands interface (/command);
can do stuff by simple HTTP POST (by sending request via cURL, for example). So you can hook to this tons of stuff (notifications about new articles at the website or so);
you can rather easily create lots of them;
you can write you own implementation in almost any programming language;
you have a list of bots you have created (thanks to #BotFather). If you have lost somehow control of your bot - just revoke the token via #BotFather and it's yours again;
pretty simple to use.
Telegram client application (in this case - CLI):
requires new Telegram account registration with phone number;
acts like any other actual Telegram user (can write to other users first, without invitation). Well, that's a good thing;
not really good cross-platform abilities for now (some lack of CLI-realisations);
not really easy to install and use;
you have to implement the commands handling part;
if you have lost your phone number - pretty much you lose this account, because it's not like you would make some precautions for CLI client account. So you will have to register a new one and repeat the setting procedure for client.
In conclusion, bots actually got rid of CLI clients, in my opinion. I had CLI account right to the moment the bots appeared. After that I deleted it and created a bot. And not just one :)
So, bots are for the "robot" stuff, and real accounts are for the real people.
The Telegram CLI library interacts directly with their MTproto protocol, which means it's like their desktop/mobile app...but for the console. You can send messages from one phone number to another. This means that when authenticating with the CLI application, you use your real number as if you were logging into the mobile application.
I wouldn't suggest using it for bot behavior as you have to write an application that wraps the Telegram CLI and parses the log file as it is displayed...since it doesn't implement all the MTproto methods and the outputs for the log file are custom...it can be quite annoying and different than what you would expect.
With Telegram CLI you can send a number to another Telegram user without having them initiate the conversation first (since it functions just like a normal Telegram client) where the Bot API requires the user to add the Bot and start interaction before the Bot knows you are there.
previous answers are almost correct. Two different interfaces for different purposes:
Telegram Bot API allows to develop a Telegram Bot.
Telegram CLI (as this one, as an implementation example: https://github.com/vysheng/tg) are telegram client implementations, running from command line, based on MTproto protocol, as Chris Brand said.
As a bot developer, I'm interested to have a TG CLI interface (2) to automatize dialogs tests, with bash scripts, with a bot made with (1).