status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Corrected some grammar.

This commit is contained in:
Dan Finlay 2016-05-12 01:34:19 -07:00
parent 9332530eed
commit ed674d282b
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
EIPS/eip-XXX.md
View File

@ -11,55 +11,55 @@ Abstract
========
This draft EIP describes the details of an authorization method that if provided by rpc enabled ethereum nodes would allow regular websites to send transactions (via ```eth_sendTransaction```) without the need to enable CORS. Instead, user would be asked to confirm the transaction via an html popup.
Every read only rpc calls the dapp want to perform are redirected to an invisible iframe from the node's domain and for every transaction that the dapp wish to execute, an html popup is presented to the user to allow him/her to cancel or confirm the transaction. This allow the dapp to connect to the node's rpc api without being granted any kind of privileges. This allow users to safely interact with dapp running in their everyday web browser while their accounts are unlocked. In case the account is not unlocked and the node has allowed the "personal" api via rpc,the html page also allow the user to enter their password to unlock the account for the scope of the transaction.
Every read only rpc call the dapp wants to perform is redirected to an invisible iframe from the node's domain and for every transaction that the dapp wish to execute, an html popup is presented to the user to allow him/her to cancel or confirm the transaction. This allows the dapp to connect to the node's rpc api without being granted any kind of privileges. This allows users to safely interact with dapps running in their everyday web browser while their accounts are unlocked. In case the account is not unlocked, and the node has allowed the "personal" api via rpc,the html page also allow the user to enter their password to unlock the account for the scope of the transaction.
Motivation
==========
Currently, if a user navigate to a dapp running on a website using her/his everyday browser, the dapp will have by default no access to the rpc api for security reason. The user will have to enable CORS for the website's domain in order for the dapp to work. Unfortunately if the user do so, the dapp will be able to send transaction from any unlocked account without the need for any user consent. In other word not only the user need to change its node default setting but the user is also forced to trust the dapp in order to use it. This is of course not acceptable and force existing dapps to rely on the use of workarround like:
- if the transaction is a plain ether transfer the user is asked to enter it in a dedicated trusted wallet like "Mist"
Currently, if a user navigates to a dapp running on a website using her/his everyday browser, the dapp will by default have no access to the rpc api for security reasons. The user will have to enable CORS for the website's domain in order for the dapp to work. Unfortunately if the user does so, the dapp will be able to send transactions from any unlocked account without the need for any user consent. In other words, not only does the user need to change the node's default setting, but the user is also forced to trust the dapp in order to use it. This is of course not acceptable and forces existing dapps to rely on the use of workarrounds like:
- if the transaction is a plain ether transfer, the user is asked to enter it in a dedicated trusted wallet like "Mist"
- For more complex case, the user is asked to enter the transaction manually via the node command line interface.
This proposal aims to provide a safe and user friendly alternative.
Here are some screenshot of the provided implementation of that html popup:
Here are some screenshots of the provided implementation of that html popup:
Account unlocked :
-----------------
When the account is already unlocked, the user is presented with the following popup for every transaction that the dapp attempts to make :
When the account is already unlocked, the user is presented with the following popup for every transaction that the dapp attempts to make:
<img src="./eip-XXX/authorization.png">
Account locked and no "personal" api exposed via rpc:
-----------------
When the account is locked and the node do not provide access to account unlocking via its rpc interface, the following popup will be presented. This is not ideal since this require the user to know how to unlock an account:
When the account is locked, and the node does not provide access to account unlocking via its rpc interface, the following popup will be presented. This is not ideal since this requires the user to know how to unlock an account:
<img src="./eip-XXX/authorization-locked.png">
Account locked but node exposing the "personal" api via rpc :
-----------------
A better option is to ask the user the password but this is only possible if the node allow access to the "personal" api via rpc. In such case the following dialog will be presented to the user so he/she can accept the transaction by providing the password required to unlock the account:
A better option is to ask the user for their password, but this is only possible if the node allows access to the "personal" api via rpc. In such case, the following dialog will be presented to the user so he/she can accept the transaction by providing the password required to unlock the account:
<img src="./eip-XXX/authorization-password.png">
Specification
=============
In order for the mechanism to work, the node need to serve an html file via http at the url \<node url\>/authorization.html
In order for the mechanism to work, the node needs to serve an html file via http at the url \<node url\>/authorization.html
This file will then be used by the dapp in 2 different modes (invisible iframe and popup window).
The invisible iframe will be embeded in the dapp to allow the dapp to send its read-only rpc call without having to enable CORS for the dapp's website domain. This is done by sending message to the iframe (via javascript ```window.postMessage```) which in turn execute the rpc call. This works since the iframe and the node share the same domain/port.
In iframe node the html file's javascript code will ensure that no call requiring an unlocked key can be made. This is to prevent dapp for embedding the visible iframe and tricking the user into clicking the confirm button.
If the dapp requires to make an ```eth_sendTransaction``` call, the dapp will instead open a new window using the same url.
In the iframe node, the html file's javascript code will ensure that no call requiring an unlocked key can be made. This is to prevent dapps from embedding the invisible iframe and tricking the user into clicking the confirm button.
If the dapp requires an ```eth_sendTransaction``` call, the dapp will instead open a new window using the same url.
In this popup window mode, the html file's javascript code will alow ```eth_sendTransaction``` (but not ```eth_sign``` as there is no way to display to the user the meaningfull content of the transaction to sign in a safe way) to be called. But instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses as well the amount being transfered along with the potential gas cost. Upon the user approving, the request will be sent and the result returned to the dapp. An error will be returned in case the user cancel the request.
In this popup window mode, the html file's javascript code will alow ```eth_sendTransaction``` (but not ```eth_sign```, as there is no way to display to the user the meaningful content of the transaction to sign in a safe way) to be called. But instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses, as well as the amount being transfered along with the potential gas cost. Upon the user approving, the request will be sent and the result returned to the dapp. An error will be returned in case the user cancel the request.
The html page also check for the availability of the "personal" api and if so, will ask the user to unlock the account if necessary. The unlocking is temporary (3s) so the password will be asked again if a transaction is attempted before the end of this short time.
The html page also checks for the availability of the "personal" api and if so, will ask the user to unlock the account if necessary. The unlocking is temporary (3s) so the password will be asked again if a transaction is attempted before the end of this short time.
In both iframe mode and window mode, the communication with the dapp is achieved using ```window.postMessage```.
The fist message the iframe/window send is a message containing the string "ready" to let the dapp know that it now accepts messages. Then the dapp can start performing rpc call by sending message using the following object :
The fist message the iframe/window sends is a message containing the string "ready" to let the dapp know that it now accepts messages. Then the dapp can start performing rpc call by sending message using the following object :
```
{
id:<a an id>, //so responses can be match as there is no guarantee of the order of the response
@ -94,14 +94,14 @@ Rationale
The design for that proposal was chosen for its simplicity and security. A previous idea was to use an oauth-like protocol in order for the user to accept or deny a transaction request. It would have required deeper code change in the node and some geth contributors argues that such change did not fit into geth code base as it would have required dapp aware code.
The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guarantess by browsers' cross domain policies.
The use of iframe/ window was required to have both security and user friendliness. The invisble iframe allow the dapp to execute read only calls without the need for user input and the window ensure the user approve before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allow. It also happen to be that the ```window.confirm``` is not safe in some browser as it give focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653).
The use of iframe/ window was required to have both security and user friendliness. The invisble iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653).
Implementations
===============
In order to implement this design, the following html file or an equivalent one need to be served at the url \<node url\>/authorization.html
In order to implement this design, the following html file or an equivalent one needs to be served at the url \<node url\>/authorization.html
That's it
That's it.
```
@ -610,4 +610,4 @@ That's it
</script>
</body>
</html>
```
```