.png%3Falt%3Dmedia%26token%3Dbf80c0b6-de2e-4b97-b1fd-3feb71323e31)
.png%3Falt%3Dmedia%26token%3Dbf80c0b6-de2e-4b97-b1fd-3feb71323e31)
Sign in request
Guide
A sign in request is the way a dApp can identify a user. Let's explain it with the following example:
When a user wants to log in or register in your dApp, the dApp has to know how to identify a user to know which operations to perform. To do so, it uses the CKBull Signer API with the dApp credentials to generate a new and unique sign in request that needs to be signed by the user who requested it.
Here's a workflow on how a sign in request is generated and signed by a user and how it affects all the entities in the system:
Sign in request workflow
In the lifetime of a sign in request, it may contain multiple states depending on the actions performed by a user. The next flow shows the complete life cycle of a sign in request and its states.
.png?alt=media)
Sign in request life cycle
To identify who signed the transaction via CKBull Wallet, a payload containing the address and network of the signer is passed when the user signs the request. For a detailed explanation, read the API docs. A sign in request has the following appearance in CKBull Wallet, showing the dApp's name, description and logo.
.PNG?alt=media)
Sign in request in CKBull Wallet
Having explained sign in requests, we can now introduce the second key concept of the platform, transaction requests.