doc(zh): translate eip-107

EIPS/zh/eip-107.md

@@ -1,76 +1,74 @@
 ---
 eip: 107
-title: safe "eth_sendTransaction" authorization via html popup
+title: 通过 `html` 弹出窗口安全的 `eth_sendTransaction` 授权
 author: Ronan Sandford (@wighawag)
 created: 2016-06-05
-status: Stagnant
-type: Standards Track
-category: Interface
+status: 停滞
+type: 标准追踪
+category: 接口
 ---
 
-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.
+该 `EIP` 草案描述了一种授权方法的详细信息，如果由启用了 `rpc` 的以太坊节点提供，则该方法将允许常规网站发送交易（通过 `eth_sendTransaction` ）而无需启用 `CORS`。相反，将要求用户通过 `html` 弹出窗口确认交易。
 
-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.
+`dapp` 想要执行的每个只读 `rpc` 调用都从节点域重定向到一个不可见的 `iframe`，并且对于 `dapp` 希望执行的每个交易，都会向用户显示一个 `html` 弹出窗口，以允许他/她取消或确认交易.这允许 `dapp` 连接到节点的 `rpc api` 而无需被授予任何类型的权限。这允许用户在他们的帐户解锁时安全地与在日常网络浏览器中运行的 `dapp` 进行交互。如果账户没有解锁，并且节点允许通过 `rpc` 的“个人” `api`，`html` 页面也允许用户输入他们的密码来解锁交易范围内的账户。
 
-Motivation
+动力
 ==========
-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 workarounds 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.
+目前，如果用户使用她/他的日常浏览器导航到在网站上运行的 `dapp`，出于安全原因，`dapp` 默认无法访问 `rpc api`。 用户必须为网站域启用 `CORS` 才能使 `dapp` 工作。 不幸的是，如果用户这样做，`dapp` 将能够从任何未锁定的帐户发送交易，而无需任何用户同意。 换句话说，不仅用户需要更改节点的默认设置，而且用户还被迫信任 `dapp` 才能使用它。 这当然是不可接受的，并迫使现有的 `dapp` 依赖于使用以下变通方法：
+- 如果交易是普通的以太币转账，则要求用户将其输入到专用的可信钱包中，例如 `Mist`
+- 对于更复杂的情况，要求用户通过节点命令行界面手动输入交易。
 
+该提案旨在提供一种安全且用户友好的替代方案。
 
-This proposal aims to provide a safe and user friendly alternative.
+以下是该 html 弹出窗口的提供实现的一些屏幕截图：
 
-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:
+当帐户已经解锁时，对于 dapp 尝试进行的每笔交易，用户都会看到以下弹出窗口：
 
 ![](../../assets/eip-107/authorization.png)
 
-Account locked and no "personal" api exposed via rpc:
+帐户被锁定并且没有通过 `rpc` 暴露“个人” `api` :
 -----------------
-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:
+当账户被锁定，并且节点不提供通过其 `rpc` 接口进行账户解锁的访问权限时，将出现以下弹出窗口。 这并不理想，因为这需要用户知道如何解锁帐户：
 
 ![](../../assets/eip-107/authorization-locked.png)
 
-Account locked but node exposing the "personal" api via rpc :
+帐户已锁定，但节点通过 `rpc` 公开“个人” `api` :
 -----------------
-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:
+更好的选择是询问用户密码，但这只有在节点允许通过 `rpc` 访问“个人” `api` 时才有可能。 在这种情况下，将向用户显示以下对话框，以便他/她可以通过提供解锁帐户所需的密码来接受交易：
 
 ![](../../assets/eip-107/authorization-password.png)
 
 
-Specification
+规格
 =============
-In order for the mechanism to work, the node needs to serve an html file via http at the url \<node url\>/authorization.html
+为了使该机制起作用，节点需要通过 `http` 在 `url` \<node url\>/authorization.html 处提供 `html` 文件
 
-This file will then be used by the dapp in 2 different modes (invisible iframe and popup window).
+该文件将被 `dapp` 以两种不同的模式（不可见的 `iframe` 和弹出窗口）使用。
 
-The invisible iframe will be embedded 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.
+不可见的 `iframe` 将嵌入到 `dapp` 中，以允许 `dapp` 发送其只读 `rpc` 调用，而无需为 `dapp` 的网站域启用 `CORS`。这是通过向 `iframe`（通过 `javascript window.postMessage`）发送消息来完成的，`iframe` 依次执行 `rpc` 调用。这是有效的，因为 `iframe` 和节点共享相同的域/端口。
 
-In the iframe mode, 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.
+在 `iframe` 模式下，`html` 文件的 `javascript` 代码将确保无法进行需要解锁密钥的调用。这是为了防止 `dapps` 嵌入不可见的 `iframe` 并诱使用户点击确认按钮。如果 `dapp` 需要一个 `eth_sendTransaction` 调用，`dapp` 将改为使用相同的 `url` 打开一个新窗口。
 
-In this popup window mode, the html file's javascript code will allow `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 transferred 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.
+在这种弹出窗口模式下，`html` 文件的 `javascript` 代码将允许调用 `eth_sendTransaction`（但不是 `eth_sign` ，因为无法以安全的方式向用户显示交易的有意义的内容以进行签名）被调用。但不是直接向节点发送呼叫，而是会出现一个确认对话框，显示发送方和接收方地址，以及转移的金额以及潜在的 `gas` 成本。在用户批准后，将发送请求并将结果返回给 `dapp`。如果用户取消请求，将返回错误。
 
-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.
+`html` 页面还会检查“个人” `api` 的可用性，如果是，则会在必要时要求用户解锁帐户。 解锁是临时的（`3` 秒），因此如果在此短时间结束之前尝试交易，将再次询问密码。
 
-In both iframe mode and window mode, the communication with the dapp is achieved using `window.postMessage`. 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 :
+在 `iframe` 模式和 `window` 模式下，与 `dapp` 的通信都是使用 `window.postMessage` 来实现的。 `iframe/window` 发送的第一条消息是包含字符串 `ready` 的消息，让 `dapp` 知道它现在接受消息。 然后 `dapp` 可以通过使用以下对象发送消息来开始执行 `rpc` 调用:
 ```
 {
-  id:<a an id>, //so responses can be match as there is no guarantee of the order of the response
-  payload:<json rpc object> //this is the exact object that usually send to the node
-}
+  id:<a an id>, //因此响应可以匹配，因为无法保证响应的顺序
+  payload:<json rpc object> //这是通常发送到节点的确切对象
 ```
 
-For `eth_sendTransaction` the "gas", "gasPrice" and "from" field need to be set in the rpc parameter so that the window can display the correct value. If not all of these are passed in, the window will return an error.
+对于 `eth_sendTransaction`，需要在 `rpc` 参数中设置 `gas`、`gasPrice` 和 `from` 字段，以便窗口可以显示正确的值。 如果不是所有这些都传入，则窗口将返回错误。
 
-Upon receiving such message, the iframe will perform the actual rpc call to the node but only if such a call is a read only call (not requiring an unlocked key). If it is not it will return a error. The window on the other will only accept `eth_sendTransaction` calls but will display a dialog so the user can accept or cancel the request.
+收到此类消息后，`iframe` 将执行对节点的实际 `rpc` 调用，但前提是此类调用是只读调用（不需要解锁密钥）。 如果不是，它将返回一个错误。 另一个窗口只接受 `eth_sendTransaction` 调用，但会显示一个对话框，以便用户可以接受或取消请求。
 
-In all the cases, the iframe/window will send a message back to the dapp using the following object:
+在所有情况下，`iframe/window` 将使用以下对象将消息发送回 `dapp`：
 ```
 {
   id:<id matching the request>,
@@ -79,27 +77,27 @@ In all the cases, the iframe/window will send a message back to the dapp using t
 }
 ```
 
-the error object cannot be a javascript Error object due to postMessage limitation. Instead it is
+由于 `postMessage` 限制，错误对象不能是 `javascript` 错误对象。 相反，它是
 ```
 {
   message:<a string describing the error>,
-  type:<a string defining the type of error> //type="cancel" means the user cancel the transaction
+  type:<a string defining the type of error> //`type="cancel"` 表示用户取消交易
 }
 ```
 
 
-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.
+该提案的设计因其简单性和安全性而被选中。以前的想法是使用类似 `oauth` 的协议，以便用户接受或拒绝交易请求。这将需要在节点中进行更深入的代码更改，一些 `geth` 贡献者认为这种更改不适合 `geth` 代码库，因为它需要 `dapp` 感知代码。当前的设计有一个非常简单的实现（自包含的 `html` 文件，可以跨节点的实现共享），其安全性由浏览器的跨域策略保证。
 
-The use of iframe/ window was required to have both security and user friendliness. The invisible 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).
+使用 `iframe/window` 需要同时具有安全性和用户友好性。不可见的 `iframe` 允许 `dapp` 在不需要用户输入的情况下执行只读调用，并且窗口确保在调用之前得到用户的批准。虽然我们可以在没有窗口模式的情况下通过使用原生浏览器的 `window.confirm` 对话框进行 `iframe` 确认来实现它，但这会阻止使用当前设计允许的更优雅的确认弹出窗口。也恰好是 `window.confirm` 在某些浏览器中不安全，因为它把焦点放在接受选项上并且可以自动触发 (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 needs to be served at the url \<node url\>/authorization.html
+为了实现这种设计，需要在 `url` \<node url\>/authorization.html 提供以下 `html` 文件或等效的文件
 
-That's it.
+那就是全部了。
 
 
 ```