From 7d6ad3a03366f6fc8e63d481ab0ce5861914b006 Mon Sep 17 00:00:00 2001 From: AlexG <39581753+Reveloper@users.noreply.github.com> Date: Wed, 13 Sep 2023 12:59:38 +0400 Subject: [PATCH 1/3] sign-page-update --- docs/develop/dapps/ton-connect/sign.mdx | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/docs/develop/dapps/ton-connect/sign.mdx b/docs/develop/dapps/ton-connect/sign.mdx index 71c048bb08..1417974fcb 100644 --- a/docs/develop/dapps/ton-connect/sign.mdx +++ b/docs/develop/dapps/ton-connect/sign.mdx @@ -45,15 +45,21 @@ type TonProofItemReplySuccess = { ``` -## Check ton_proof with API +## Check ton_proof 1. Retrieve `TonProofItemReply` from user. -2. Try to obtain public key via get_public_key get method on smart contract deployed at `address` -3. If the smart contract has not been deployed (e.g., the user has just created a new wallet locally in the wallet app) or does not support get_public_key method(v3 contracts), follow these steps: -* a. Parse wallet's StateInit `walletStateInit = TonAddressItemReply.walletStateInit` -* b. Retrieve `{public_key, address}` from `walletStateInit` with [TON API](https://tonapi.io/) method POST /v2/tonconnect/stateinit -* Check that `address` extracted from `walletStateInit` or corresponds to wallet's `address` declared by user. -4. Verify timestamp, domain, signature with `public_key` (examples [GO](https://github.com/ton-connect/demo-dapp-backend/blob/master/proof.go), [TS](https://gist.github.com/TrueCarry/cac00bfae051f7028085aa018c2a05c6), [Python](https://github.com/XaBbl4/pytonconnect/blob/main/examples/check_proof.py)) +2. Verify that the domain corresponds to the domain of your application +3. Check if `TonProofItemReply.payload` permitted by original server and still active. +4. Check timestamp +5. Assemble a message according to the message scheme +6. Retrieve public_key either API (a) or (b) implemented logic on back-end +-- 6a. +- i Retrieve {public_key, address} from walletStateInit with TON API method POST /v2/tonconnect/stateinit +- ii Check that address extracted from walletStateInit or corresponds to wallet's address declared by user. +-- 6b. +- i Obtain the wallet's pubkey via the wallet contract's get method +- ii If the contract is not active, then obtaining the key in this manner will be impossible; you will need to parse the `walletStateInit`, which is provided by the frontend and CHECK that `TonAddressItemReply.walletStateInit.hash()` equals to `TonAddressItemReply.address.hash()` means BoC hash. +7. Verify that the signature from the frontend actually signs the assembled message and corresponds to the public key of the address ## How to Check TON Proof on Server Side From ba65fd173f87515239f348d9e32d6b3d250a9b9a Mon Sep 17 00:00:00 2001 From: AlexG <39581753+Reveloper@users.noreply.github.com> Date: Fri, 15 Sep 2023 16:00:57 +0400 Subject: [PATCH 2/3] update_ton_proof --- docs/develop/dapps/ton-connect/sign.mdx | 40 +++++++++---------------- 1 file changed, 14 insertions(+), 26 deletions(-) diff --git a/docs/develop/dapps/ton-connect/sign.mdx b/docs/develop/dapps/ton-connect/sign.mdx index 1417974fcb..3019b20f56 100644 --- a/docs/develop/dapps/ton-connect/sign.mdx +++ b/docs/develop/dapps/ton-connect/sign.mdx @@ -4,8 +4,7 @@ import ThemedImage from '@theme/ThemedImage'; ## Use Cases -Please note that signing is not required for all DApps. It will be useful if you want to verify a user to provide them with their personal information from the back end. This is necessary for authorization on the backend, to prove that the user truly owned the declared address. - +Please note that signing is not required for all DApps. It will be useful if you want to verify a user to provide them with their personal information from the back end. This is necessary for authorization on the backend to make certain that the user truly owned the declared address, as it follows that the user has permission to access his data on the backend. ## How ton_proof Works? @@ -45,32 +44,21 @@ type TonProofItemReplySuccess = { ``` -## Check ton_proof +## Check ton_proof on Server Side -1. Retrieve `TonProofItemReply` from user. -2. Verify that the domain corresponds to the domain of your application +1. Retrieve `TonProofItemReply` from a user. +2. Verify that the received domain corresponds to the domain of your application. 3. Check if `TonProofItemReply.payload` permitted by original server and still active. -4. Check timestamp -5. Assemble a message according to the message scheme -6. Retrieve public_key either API (a) or (b) implemented logic on back-end --- 6a. -- i Retrieve {public_key, address} from walletStateInit with TON API method POST /v2/tonconnect/stateinit -- ii Check that address extracted from walletStateInit or corresponds to wallet's address declared by user. --- 6b. -- i Obtain the wallet's pubkey via the wallet contract's get method -- ii If the contract is not active, then obtaining the key in this manner will be impossible; you will need to parse the `walletStateInit`, which is provided by the frontend and CHECK that `TonAddressItemReply.walletStateInit.hash()` equals to `TonAddressItemReply.address.hash()` means BoC hash. -7. Verify that the signature from the frontend actually signs the assembled message and corresponds to the public key of the address - -## How to Check TON Proof on Server Side - -Obtain from the frontend the following data: wallet address, domain, timestamp, walletStateInit, signature - -* Verify that the domain corresponds to the domain of your application -* Check that this payload was issued recently (you can issue cookies with the payload before authorization, and when checking ton_proof, verify the presence of a cookie for this client) -* Assemble a message according to the scheme from the previous slide -* Obtain the wallet's pubkey via the wallet contract's get method -* If the contract is not active, then obtaining the key in this manner will be impossible; you will need to parse the walletStateInit, which is provided by the frontend -* Verify that the signature from the frontend actually signs the assembled message and corresponds to the public key of the address +4. Check if `timestamp` actual at the moment. +5. Assemble a message according to the [message scheme](/develop/dapps/ton-connect/sign#concept-explanation). +6. Retrieve `public_key` either API (a) or (b) implemented logic on back-end +- 6a: + - Retrieve `{public_key, address}` from the `walletStateInit` with [TON API](https://docs.tonconsole.com/tonapi/api-v2#:~:text=/v2/-,tonconnect,-/stateinit) method `POST /v2/tonconnect/stateinit`. + - Check that the `address` extracted from `walletStateInit` or corresponds to wallet's `address` declared by user. +- 6b: + - Obtain the wallet's `public_key` via the wallet contract's [get method](https://github.com/ton-blockchain/wallet-contract/blob/main/func/wallet-v4-code.fc#L174). + - If the contract is not active, or if it lacks the get_method found in older wallet versions (v1-v3), then obtaining the key in this manner will be impossible. Instead, you will need to parse the walletStateInit provided by the frontend. Ensure that TonAddressItemReply.walletStateInit.hash() is equal to TonAddressItemReply.address.hash(), indicating a BoC hash. +7. Verify that the `signature` from the frontend actually signs the assembled message and corresponds to the `public_key` of the address. ## React Example From 59107b1fc83052f3db066ff23198a3e3675f5bc6 Mon Sep 17 00:00:00 2001 From: AlexG <39581753+Reveloper@users.noreply.github.com> Date: Fri, 15 Sep 2023 16:09:16 +0400 Subject: [PATCH 3/3] ton_proof_update --- docs/develop/dapps/ton-connect/sign.mdx | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/develop/dapps/ton-connect/sign.mdx b/docs/develop/dapps/ton-connect/sign.mdx index 3019b20f56..1ab6a677f9 100644 --- a/docs/develop/dapps/ton-connect/sign.mdx +++ b/docs/develop/dapps/ton-connect/sign.mdx @@ -4,7 +4,10 @@ import ThemedImage from '@theme/ThemedImage'; ## Use Cases -Please note that signing is not required for all DApps. It will be useful if you want to verify a user to provide them with their personal information from the back end. This is necessary for authorization on the backend to make certain that the user truly owned the declared address, as it follows that the user has permission to access his data on the backend. +Please note that the ton_proof verification is not required for all DApps. +This is necessary for authorization on the backend to make certain that the user truly owned the declared address, as it follows that the user has permission to access his data on the backend. + +It will be useful if you want to verify a user to provide them with their personal information from the back end. ## How ton_proof Works?