personal.unlockAccount(eth.accounts[0],"")
Error: account unlock with HTTP access is forbidden
I run Geth in a Docker container and use
docker exec -it bootstrap geth --datadir=~/.ethereum/devchain attach
to exec the Geth console.
-
2Same problem here, I think it is as a result of some geth update.– Oleg BelousovCommented Apr 9, 2019 at 11:07
Add a comment
|
4 Answers
Yes, this error is about some geth update. See more about it in this merged go-ethereum pull request.
Overall, to bypass this protection, If you want to enable unlocking accounts with unsecure http (security risk), you can use "--allow-insecure-unlock" option when starting geth local server like;
geth --ropsten --syncmode "fast" ***--allow-insecure-unlock*** --cache 1024 --rpc --rpcapi eth,net,web3,personal
-
1Sorry, I am still confused where to append 'allow-insecure-unlock'?– WayneCommented Apr 9, 2019 at 16:54
-
1In your case something like: docker exec -it bootstrap geth --datadir=~/.ethereum/devchain --allow-insecure-unlock attach– artypplCommented Apr 10, 2019 at 9:20
-
2It still shows the
Error: account unlock with HTTP access is forbidden, why?– WayneCommented Apr 10, 2019 at 15:10 -
9try to add "--allow-insecure-unlock" option when you start/run the eth-node.– artypplCommented Apr 11, 2019 at 9:12
-
1added it as the last parameter in commandline and it worked :) Commented Aug 19, 2020 at 5:08
It looks like you have geth open with --rpc, enabling HTTP access. If you unlock the account, anybody who can access that node by HTTP can do anything they like with that account, such as moving all funds to a different address that only they have a key to, or otherwise mess with whatever you're trying to accomplish. There are bots scanning for these sorts of vulnerabilities all over and you might suffer from the security hole even if not specifically targeted. (Example report here).
The best solution is probably not to allow insecure unlocking of accounts, though the dangers are considerably less if a strong firewall prevents external HTTP access on the relevant ports. A better solution would be to think more carefully about why you think you need the account unlocked, and if there are ways to accomplish those goals other than unlocking and leaving the account wide open. Alternatively, you could do the unlock on another node on the same blockchain network which does not enable RPC/HTTP access.
I found a same issue when I tried to deploy a contract on a private chain with remix-ide using we3 provider. It seems that a node with RPC/HTTP access and an unlocked account is needed. Otherwise, An error occurred saying "Not possible to connect to the Web3 provider. Make sure the provider is running and a connection is open (via IPC or RPC)".
In this case, I first had geth open with --unlock, and then enabled RPC with admin.startRPC() function in the console attached. It works!
the latest quorum release inherits upstream behaviour whereby it disallows unlock via HTTP-RPC for security reasons. There is a command line flag --allow-insecure-unlock which can be passed when starting geth which will re-allow this.
This is described in the upstream geth command line options here: https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options
(Note that geth doesn't actually support HTTPS, so that HTTPS_QUORUM_ENDPOINT must actually be using HTTP, or I'm guessing it uses HTTPS to connect to a reverse proxy which then attaches to geth over the HTTP-RPC port.)
