OpenSource/python-telegram-bot
OpenSource/python-telegram-bot
1
0
Fork 0
mirror of https://github.com/python-telegram-bot/python-telegram-bot.git synced 2024-11-22 15:17:00 +01:00
Code Issues Projects Releases Packages Wiki Activity

Updated Arbitrary callback_data (markdown)

Bibo-Joshi 2021-06-06 17:06:35 +02:00
parent d9260f6bc4
commit 7051b3922a
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
Arbitrary-callback_data.md

@ -6,7 +6,7 @@ With PTB you are able, to pass *any* object as `callback_data`. This is achieved
This means two things for you: This means two things for you:
1. If you don't use persistence, buttons won't work after restarting your bot, as the stored updates are lost. More precisely, the `callback_data` you will receive is an instance of `telegram.ext.utils.callbackdatacache.InvalidCallbackData`. If you don't need persistence otherwise, you can set `store_callback_data` to `True` and all the others to `False`. 1. If you don't use persistence, buttons won't work after restarting your bot, as the stored updates are lost. More precisely, the `callback_data` you will receive is an instance of `telegram.ext.InvalidCallbackData`. If you don't need persistence otherwise, you can set `store_callback_data` to `True` and all the others to `False`.
2. If you have a number of keyboards that need to stay valid for a very long time, you might need to do some tweaking manually (see below) 2. If you have a number of keyboards that need to stay valid for a very long time, you might need to do some tweaking manually (see below)
3. When using the `CallbackQueryHandler`, the `pattern` argument can now be either 3. When using the `CallbackQueryHandler`, the `pattern` argument can now be either
@ -31,7 +31,7 @@ Callback updates are not sent by Telegram, but by the client. This means that th
Most of the time, this is not really a problem, since `callback_data` often just is `Yes`, `No`, etc. However, if the callback data is something like `delete message_id 123`, the malicious user could delete any message sent by the bot. Most of the time, this is not really a problem, since `callback_data` often just is `Yes`, `No`, etc. However, if the callback data is something like `delete message_id 123`, the malicious user could delete any message sent by the bot.
When using `arbitrary_callback_data` as described above, PTB replaces the outgoing `callback_data` with a [UUID](https://docs.python.org/3/library/uuid.html), i.e., a random unique identifier. This makes the `callback_data` safe: If a malicious client alters the scent `CallbackQuery`, the invalid UUID can't be resolved. In this case `CallbackQuery.data` will be an instance of `telegram.ext.utils.callbackdatacache.InvalidCallbackData`. Note that this is also the case, when the UUID *was* valid, but the data has already been dropped from cache - PTB can't distinguish between the two cases. When using `arbitrary_callback_data` as described above, PTB replaces the outgoing `callback_data` with a [UUID](https://docs.python.org/3/library/uuid.html), i.e., a random unique identifier. This makes the `callback_data` safe: If a malicious client alters the scent `CallbackQuery`, the invalid UUID can't be resolved. In this case `CallbackQuery.data` will be an instance of `telegram.ext.InvalidCallbackData`. Note that this is also the case, when the UUID *was* valid, but the data has already been dropped from cache - PTB can't distinguish between the two cases.
## Manually handling updates ## Manually handling updates