On the 10th of February, Telegram sent the following message to
those with an application registered on https://my.telegram.org.
--
Telegram API Update. Hello [REDACTED]. Thank you for contributing to the
open Telegram ecosystem by developing your app, [REDACTED].
Please note that due to recent updates to Telegram's handling of SMS and
the integration of new SMS providers like Firebase, we are changing the
way login codes are handled in third-party apps based on the Telegram API.
Starting on 18.02.2023, users logging into third-party apps will only be
able to receive login codes via Telegram. It will no longer be possible
to request an SMS to log into your app - just like when logging into
Telegram's own desktop and web clients.
Exactly like with the Telegram Desktop and Web apps, if a user doesn't
have a Telegram account yet, they will need to create one first using
an official mobile Telegram app.
We kindly ask you to update your app's login and signup interfaces to
reflect these changes before they go live on 18.02.2023 at 13:00 UTC.
This change will not significantly affect users since, according to our
research, the vast majority of third-party app users also use official
Telegram apps. In the coming months, we expect to offer new tools for
third-party developers that will help streamline the login process.
Raw API does not monkey-patch the client on the returned messages,
so the get_input_chat call would return None, causing the forward
to fail. Instead, manually resolve the chat using the message's
peer_id.
The resolve call can also be avoided if from_peer is passed (which
may mismatch with where the messages actually belong, but that's not
really a concern).
These will log sensitive information.
They are disabled when running with PYTHONOPTIMIZED.
They can only be enabled by setting a level lower than DEBUG,
which is difficult to do on accident.
Closes#3916.
The new MessageBox system is not designed with "albums come in the
same updates container" in mind (in fact, there was a note about this).
This version was also not intended to be published to PyPi, but it is,
so a workaround must be made for events.Album to remain working.
In essence, AlbumHack will always be used even if it technically did not
need to be used previously. This will cause a small delay for those
updates, but it should not be a major issue.
If saving every minute or new entities fails, it's not fatal.
Other places are not checked because it is more critical for
information to be saved, such as disconnect, where we want to
crash if the session cannot be accessed.
See discussion on https://github.com/LonamiWebs/Telethon/commit/49713b2.
The problem with the automatic approach is that some scripts may do
some "fancier" things with the way they register updates, so it was
prone to failure (a handler could be added but since the last request
was without updates, nothing would be received).
This new approach is a bit more annoying to opt-into but also more
explicit.
* Apply code corrections for the new layer types.
* Support not passing `user` to `get_permissions`.
* `download_profile_photo` now supports `MessageService`.
* `thumb` in send and edit message.
* Document new known errors.
Introduced by 668dcd52ca (this commit
did change a lot more than it should have); the condition for search
was never updated to account for the non-None value.
Closes#1693.
It was added back in bfc408b probably due to a misunderstanding of
https://docs.python.org/3/howto/logging.html#configuring-logging-for-a-library.
The default behaviour of logging WARNING and above is good and
desirable (hiding unhandled exceptions in update handlers by default
was a big, accidental mistake). NullHandler is used to *prevent*
this good default, so it shouldn't be used in the first place.
