I am setting up a service where users will pay by sending crypto to a particular address but i need some way to verify that the user is the owner of the address they say they sent it from without it being complicated on the users end.
If I assume the user is using Metamask, there are a variety of signature methods Metamask allows you to do to verify the user owns the address. The specific methods vary, but the basic idea is that it asks the user to sign a message with their private key for the address, and then verifies that the signature is valid. One API for this is described here:
https://medium.com/metamask/scaling-web3-with-signtypeddata-91d6efc8b290
Since Metamask supports BSC and it is generally ETH compatible, I would assume the same functions would work for a BSC address. I'm not familiar enough with every BSC wallet (such as the Trust Wallet) to know if they have similar signing features, they may. In any case, the user's wallet would need to have a feature that allows for this kind of signing for this type of verification to be done--it may not be possible if you are interacting with a user that just has a mobile light wallet with limited features for only sending/receiving.
Related
Many dapps such as opensea requests for sinature request as user's authentication.
Is this primarily for off-chain database access and gaining access token or cookie?
If my dapp does not use off-chain DB, can I skip it?
I just have a simple buy token flow and wondering if this is necessary because i've seen most of the dapps are utilising signature request.
It is not going to hurt you. You are just proving that you have access to the private keys. what happens is the server retrieves an account address from the signature and checks if the retrieved account is the same as the one sent to the server. The signature request adds trustability to the website.
In db example, if the user information is stored and retrieved by the account address, you can see the user information and have access to the private routes.
Or let's say a user uploads an unsafe image to the website and sends an arbitrary address to the server. Now website will ban this sent address not the user's address.
I need to call an API that requires the user's wallet address. However, I can only get wallet's accounts by web3.eth.getAccounts() but not the wallet address.
I am using WalletConnect and was able to create web3 instance.
Thanks!
You need to use requestAccounts and ask the permission from the user to access their wallet addresses.
Due to privacy reasons, the website cannot do this by default.
Also, you need to set up your Web3 properly with the wallet in the order it to work. Because your question did not contain any example code or repeatable example, it is not possible to tell if you are doing it properly.
What i am trying to do:
Building a small app that allows a user to purchase a service for a set amount of tokens. For example, 100 tokens for service A, 500 tokens for service B. This will be for a custom token on the harmony blockchain.
What i know:
I already know how to connect to metamask and get the users address. Signer and provider are available to me.
What confuses me:
Examples and documentation all refer to a private_key and creating a wallet, i don't need to do that, i need to use the users existing wallet.
What i need to do:
Prompt a transaction in the user wallet (harmony one or metamask) for a set amount of tokens.
Check if the user has required balance (seems trivial knowing i can read their balance).
Make the transaction. Also seems ok after reading the docs.
Get a receipt, then call a callback/my code. Again, seems ok after reading the docs.
All pretty straight forward, but again - every document i read always refers to setting a private key - surely i don't need to do this?
A transaction always needs to be signed by a private key generating the sender address. Otherwise it's rejected by the network.
Examples and documentation all refer to a private_key and creating a wallet, i don't need to do that, i need to use the users existing wallet.
every document i read always refers to setting a private key - surely i don't need to do this?
A backend approach is to import the private key to the app and use it to sign the transaction.
However, there's also a frontend approach: Send a request to a wallet browser extension to sign the transaction and broadcast it to the network. The wallet extension then pops up a window and lets the user chose whether they want to sign the transaction (with their private key, not shared with the app) and broadcast it - or not.
You can find an example of such request in the MetaMask docs page.
An advantage of this approach is that your app doesn't need to ask for the user's private key. A disadvantage is that if the user haven't installed a browser wallet compatible with your app, they can't send the transaction (or at least not so easily).
Note: I'm not familiar with the Harmony wallet, but I'm assuming it works in a similar way as MetaMask - because Harmony is an EVM-compatible network, and MetaMask only supports EVM-compatible networks.
I've read now alot about oauth 2.0 and its use cases (flows).
Now i got these two scenarios:
User logs into our client and with his id and pw, the client is then doing the api calls.
Foreign system with no user data wants to access servers web api.
If i am not wrong i would suggest using for 2. the "Client Credentials flow"
and for 1. I would use "Implicit authorization grant flow".
I have the information about the chosen flows, from http://tutorials.jenkov.com/oauth2/authorization.html
So am i right about this decision or is there a better alternative i have not seen?
Yes you are,
In general when a client (be it your own web client or third party client) wants to access user's data, then they must pass access token which they have obtained during authorization by using any one of the flow (authorization_code or implicit)
And when third party system wants to access data which is not user related or least not sensitive , then you just need some way to identify which client is making the request, its useful for validation, rate limiting etc.
So Client Credentials flow works in your case.
I want to develop a REST API. REST guidelines specify that the state mustn't be stored on the server side.
But the REST methods I want to implement imply user connection management. In order to respect the statelessness, do I need to give the user credentials in each REST method request ? I find that quite inefficient... Isn't there an other more effective way ??
Statelessness is one of the main constrains of a REST architecture, as can be read in the original publication:
5.1.3 Stateless
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
So for the credentials you mentioned, you should provide them in each call separately (i.e. Basic Auth + SSL). Of course, this is were "the real world" comes in, and applications start to differ. You might also use OAuth, fixed tokens, etc. but remember that you're then weakening the "RESTfulness" of your API.
Authenticating on every request does not necessarily require passing the username and password on every request. Some systems will take the user name and password, verify it and then create some kind of security token that can be passed on every request instead.
The idea is that the token should be quicker to authenticate than doing a full username password check. Obviously depending on how sophisticated the token generation and verification is you may be opening other security holes but you have to decide how critical that is.