diff --git a/data/web/core.telegram.org/tdlib/getting-started.html b/data/web/core.telegram.org/tdlib/getting-started.html index fb0194f20c..d47aa2c6e0 100644 --- a/data/web/core.telegram.org/tdlib/getting-started.html +++ b/data/web/core.telegram.org/tdlib/getting-started.html @@ -86,7 +86,7 @@
After call to setTdlibParameters
in case of success Application will receive updateAuthorizationState
with new state and just needs to handle that update, nothing should be done explicitly. If setTdlibParameters
fails, then authorization state is not changed and the Application must try to handle the current authorization state again.
The second received authorization state is always authorizationStateWaitEncryptionKey
. When it is received, the database encryption key must be provided through a call to checkDatabaseEncryptionKey
. For most mobile apps, you can provide an empty database encryption key here (more info). If user isn't authorized yet, then some of authorizationStateWaitPhoneNumber
, authorizationStateWaitCode
, authorizationStateWaitRegistration
and authorizationStateWaitPassword
authorization states may be received. After completing these authorization steps, the Application will receive authorizationStateReady
, meaning that authorization was successful and ordinary requests can be sent now.
If user isn't authorized yet, then some of authorizationStateWaitPhoneNumber
, authorizationStateWaitEmailAddress
, authorizationStateWaitEmailCode
, authorizationStateWaitCode
, authorizationStateWaitRegistration
and authorizationStateWaitPassword
authorization states may be received. After completing these authorization steps, the Application will receive authorizationStateReady
, meaning that authorization was successful and ordinary requests can be sent now.
You can find complete examples of user authorization in our Java and C# examples.