I have sent/deposited Ether to my smart contract using ReactJS as front-end and web3 as interface using the below code.
await this.state.Bank.methods.desposit().send({value:amountInEther.toString(),from:this.state.account})
and while trying to receive ether from the smart contract using frontend Reactjs i have used this code
(React code) await this.state.Bid.methods.withDraw(this.state.account).call()
dbank.sol(solidity below code):
function withDraw(address payable receiver)public{
receiver.transfer(accounts[receiver]);
accounts[receiver]=0;
}
when i tried this it didn't work but when I changed the react code from call to send with address it worked
await this.state.Bid.methods.withDraw().send({from:this.state.account})
But WHY? and also when i use this metamask is taking some gas fees to run this. Don't you think smart contract has to give the ether to us and it should pay the Gas fee.
We are paying Gas fee while sending the ether to the contarct Is okay acceptable but why should we pay the gas fee to receive our ether from the contract?
About your first question, because the web3 library was made that way,just that simple, there are other libraries that have different ways of handle that, but what does {from: this.state.account} is pass the information necessary to the library to sign the transaction and send it
About your second question, to the ethereum network currently (and probably never) does not exist a way to distinguish a "withdraw" from a transaction, because there are exactly the same, remember that you are calling a contract function that will modify the state of the blockchain, that call will become a transaction and the transaction has to pass the hole process, minting, verification and all of that, so as any transaction you have to pay gas
Related
I am getting error while saving.
I want to save ABI section and proceed further
The issue here is that you're attempting to register a testnet contract on goerli in our production system. You should be getting a more meaningful error and I'll look into that now, but if you set this up in our https://staging.crossmint.io/console system you should be good to go!
This is your contract address on goerli testnet
0x537210CEe33CE059Ab225662e775b54cFEF5C4Ab
Everything else looks great in your function signature. The main thing our dev console expects to be able to self register a contract is that it accepts an address argument and mints to that instead of msg.sender.
Actually, it looks like you started with my evm-starter contract! Awesome :-)
I added a WebSocket API through AWS API Gateway on my React app.
I originally added it to build a chat messaging section, however, I soon realized how useful it could be for other things in the app that might need real-time updates.
I had an idea, and that is to store the socket in a React context so it's accessible from all the components of the app and that should work fine, without re-establishing a connection every time a component mounts.
Now, the question is, is there a better way to do what I'm trying to do? Hence, create a socket connection that I can then take advantage of for multiple functions? Say for instance, "is online" status.
The alternative is to create yet another socket API but is that really necessary?
Keep in mind I'm using a serverless framework (API) with lambda functions on AWS.
This is going to depend on the applications planned scale, keeping in mind that as the app usage grows you may want to refine the endpoint architecture and code.
Remember that an auth endpoint/api for example may only need to be accessed a few times over a chat interaction endpoint/api. For scalability (and cost per endpoint call too) id be looking at keeping them separate.
I would like to send a transaction to the binance smart chain (BSC)that will buy an NFT for a crypto integrated game.
I've looked at their contract to figure out what the transaction should look like.
Does the data in the image below give me all the information I need to send my own transaction?
If so, can you provide a pattern or toolset that I should use to encode and send my transaction?
Here is the address of a transaction that I would like to emulate.
https://bscscan.com/tx/0x0430f9964ae70d8993eb45a4e0d89e72594ad109467d6ab8d39fea9115f0e1a3
I make a web service and I'm going to use a React. A data for the service will be fetch from my API.
But there is a simple way to find out which endpoints I'm using, and what data I'm sending. This knowledge gives a lot options to make bots for my service.
Is there any option to prevent this?
I know, I can require a signing all requests, but it's also easy to get to know.
This cannot be done. Whatever is done in client-side JavaScript, can be reverse-engineered and simulated.
Efforts should be focused on preventing API from being abused, i.e. throttling or blacklisting clients based on their activity or available information (user agent, suspicious request, generated traffic). If the use of API allows captcha, suspicious clients can be asked for proving their humaneness.
There are half-measures that can be applied to client side application and make it less advantageous for abuse (and also for development).
Prevent unauthorized access to unminified/unobfuscated JS AND source maps. There may be a need to authorize them on per user basis. This will make debugging and bug reporting more difficult
Hard-code parts that are involved in request signing to browser APIs, e.g.:
apiKey = hash(NOT_SO_SECRET_KEY + document.querySelector('.varyingBlock').innerHTML)
This requires bots to emulate browser environment and makes their work much less efficient. This also affects the design of the application in negative way. Obviously, there will be additional difficulties with SSR and it won't translate to native platforms easily.
here two basic preventive measures that you can use.
Captcha
Use a captcha service like recaptcha. so that user can use your website only after passing the captcha test. Its highly difficult for bots to pass the captchas.
Rate Limit Api usage.
Add rate limiting to your api. so that a logged in user can only make 100 requests in 10 minutes, the numbers will depend on you use case
I'm integrating a web payment using angularjs.
My main goal are
to let the user be able to topup or pay via paypal
upon successful redirect him back to my site
If the transaction is successful i will then update our db records.
Glad to say that after 2days I'm done with the first 2 steps. Then I've read about using PDT (Payment Data Transfer) and I used this to get the transaction details of the payer but I had read many post saying using PDT isn't reliable enough that I also must use IPN (Instant Payment Notification). So I google about it and almost all sample/tutorial about IPN are made from using server side scripting. So is it possible to perform an IPN listener using javascript alone?
No, not on the client-side. You can use server-side Javascript (nodejs) to do this. The purpose of IPN is to let your server know that a payment is completed. The IPN request comes directly from paypal behind the scenes to a URL you give it. There's no way for a client to receive this signal instead, and if it could then there'd be a big security flaw because anyone could forge it.
However, you could update your backend using IPN, then use something like socket.io (websockets) or long-polling (plain old ajax) to let your client know that payment was successful. With long-polling, you'd basically be asking your back-end every second or two whether or not payment was succesful. With sockets, you have a more direct communication. I like socket.io because it falls back to long polling (or flash) if real web sockets aren't available.