On the specific RPC questions:
--rpcaddr
is the address on which the user's geth rpc server would be listening. By default it's localhost. Localhost is normally only accessible to a process sending messages on the same computer, which is normally what you want. If you set this to a public IP address then anyone can connect to your node, which is very bad if the node controls your money and you've told it to let people spend it by sending it requests over the network.
If it's accepting requests on localhost, any process running locally can connect to it. However, your users trust all the processes running on their local computers, right? Well, maybe not. The first problem is that any other app can steal their money. But hopefully they didn't download any dodgy apps that will try to do this. But the second problem is, their browser is also running apps: Not just your app, but also the JavaScript of any other site the user is visiting.
Browsers try to handle this with a thing called the Same Origin Policy. This means that by default, you can only write JavaScript to access the same domain and the same port that you're using to view a page. Even this is a bit icky, because there are lots of ways that you can send data from browsers and not all of then are blocked, and this whole setup has quite a terrifyingly large attack surface. But people sometimes want to make exceptions to this policy, so there's a thing called Cross-Origin Resource Sharing (CORS), where a browser will ask a server, "other than yourself, are there any other domains+ports out there serving web pages that you want me to allow to talk to you?".
This is what Geth calls --rpccorsdomain
. If you want a browser to talk to geth and the browser is showing a page from a web server on localhost, you at least have to specify localhost plus the port that server is on. If you want to serve people the app from your domain, they have to tell their geth to let pages from your domain spend their money.
All of this is horrible. Yuck. Also, aargh.
IPC or Inter-process Communications generally works on your local computers. In the Ethereum space, IPC normally involves geth
creating a IPC pipe (which is represented by the file $HOME/.ethereum/geth.ipc
) on your computer's local filesystem.
Other processes on the same computer can then use the IPC file to create bi-directional communications with geth
.
RPC or Remote Procedure Calls generally works across different computers. In the Ethereum space, RPC normally refers to the RPC endpoint localhost:8545
or 127.0.0.1:8545
or 192.168.1.123:8545
.
If you use localhost:8545
or 127.0.0.1:8545
for your RPC endpoint, other process ONLY on the local computer can communicate via this RPC endpoint, as localhost
and 127.0.0.1
is only accessible from the local computer.
If you use a non-local IP address like 192.168.1.123
, any other computer on your network can access this RPC endpoint.
If your internet connection forwards traffic from your internet IP address to your computer's IP address 192.168.1.123
then any computer from the internet can access your RPC endpoint by connecting to {your internet IP address}:8545.
As documented in How to reduce the chances of your Ethereum wallet getting hacked?, the user Patrick forwarded his internet IP address traffic for port 8545 to his computer's non-local IP address (e.g. 192.168.1.123 instead of 127.0.0.1). When Patrick unlocked his account to transfer some funds, an attacker from the internet was able to execute geth
JSON-RPC commands to steal Patrick's ethers.
So if you do enable RPC over geth
, enable it using --rpcaddr 127.0.0.1
if you only want it accessible from your local computer. If you enable it using your network IP address (e.g. 192.168.1.123), all computers from your network will be able to access geth
's RPC endpoint. If you then have your internet modem forwarding traffic for port 8545 from the internet to your computer's 192.168.1.123:8545, anyone from the internet will be able to access geth
's RPC endpoint.
So, don't specify the --rpcaddr
parameter and it will default to 127.0.0.1 which is only accessible from your local computer, and if you want to access RPC from other computers on your local network, make sure that your internet connection does not forward internet traffic to your geth
machine.
Responding to additional question
The best way to check if your local machine is listening for communications outside your local computer space is to perform the following:
Iota:backup user$ netstat -an | grep LISTEN
tcp4 0 0 127.0.0.1.8545 *.* LISTEN
tcp46 0 0 *.30303 *.* LISTEN
tcp4 0 0 127.0.0.1.8181 *.* LISTEN
tcp4 0 0 127.0.0.1.6379 *.* LISTEN
In the above table, you can see that the ports 8545 (geth), 8181 (my local web server) and 6379 (Redis NoSQL database) are only accessible from my local machine. Port 30303 however is accessible from outside my local machine. As my ADSL router forwards traffic from port 30303 to my local computer, the world can access my local computer via port 30303.
IPC and RPC are not necessarily the same in terms of accessibility. If you have an IPC connection accessible, programs on your local computer may have access to the program listening on the IPC file. But your web browser will not have access to this file as web browsers generally do not connect via IPC.
If you have a RPC connection accessible from your local machine, your web browser running locally on your machine will have access to your RPC connection. The parameter --rpccorsdomain
is meant to restrict access from your web browser from domains other than what you specified, but any (malicious) program running on your computer can just ignore this request (it is just a polite request and not a restriction) and access your RPC port anyway.
Best Answer
Below steps is what you need to do:
1. Open the SSH console for transaction node by running ETHEREUM-RPC-ENDPOINT Ssh script on powerShell. You can find the script on Azure portal, sthing like
2. Edit the file start-private-blockchain.sh. In order to edit this file, or you use VIM editor (VIM start-private-blockchain.sh) or using some Editors over ssh (Example: WinSPC)
3. Find below lines and update
From
To
The difference is adding
--rpcapi "eth,net,web3,admin,personal"
4. Restart the tx VM using azure portal.
Now you have admin, personal rpcapi enable.
Note: There are some security threats after enabling those rpcapis.
Reference:
https://blogs.msdn.microsoft.com/pkirchner/2017/07/12/getting-started-with-ethereum-tutorials-on-azure/
https://medium.com/@gilangbhagaskara/smart-contract-in-azure-ethereum-consortium-part-i-901951116bfc
https://social.msdn.microsoft.com/Forums/en-US/9fd92236-2354-4788-a86b-b716d232f630/unlock-account-using-code-not-working?forum=azureblockchain&prof=required