Add examples to DepositPreauth reference docs & clarify some details

This commit is contained in:
mDuo13
2018-07-30 13:29:35 -07:00
parent 87820b61f6
commit c9977ec30d
8 changed files with 84 additions and 21 deletions

View File

@@ -70,7 +70,7 @@
<td class="depauth-maybe">Cross-currency only</td>
<td class="depauth-ok">OK</td>
<td class="depauth-spacer">&nbsp;</td>
<td class="depauth-no">No Permission</td>
<td class="depauth-maybe">Cross-currency only<sup>1</sup></td>
<td class="depauth-no">No Permission</td>
<td class="depauth-ok">OK</td>
</tr>
@@ -79,7 +79,7 @@
<td class="depauth-maybe">Cross-currency only</td>
<td class="depauth-ok">OK</td>
<td class="depauth-spacer">&nbsp;</td>
<td class="depauth-no">No Permission</td>
<td class="depauth-maybe">Cross-currency only<sup>1</sup></td>
<td class="depauth-maybe">XRP payments up to the minimum reserve</td>
<td class="depauth-ok">OK</td>
</tr>
@@ -88,7 +88,7 @@
<td class="depauth-maybe">Cross-currency only</td>
<td class="depauth-ok">OK</td>
<td class="depauth-spacer">&nbsp;</td>
<td class="depauth-no">No Permission</td>
<td class="depauth-maybe">Cross-currency only<sup>1</sup></td>
<td class="depauth-maybe">Balance changes from rippling</td>
<td class="depauth-ok">OK</td>
</tr>
@@ -97,7 +97,7 @@
<td class="depauth-maybe">Cross-currency only</td>
<td class="depauth-ok">OK</td>
<td class="depauth-spacer">&nbsp;</td>
<td class="depauth-no">No Permission</td>
<td class="depauth-maybe">Cross-currency only<sup>1</sup></td>
<td class="depauth-maybe">Balance changes from executing offers</td>
<td class="depauth-ok">OK</td>
</tr>
@@ -132,6 +132,8 @@
</tr>
</table>
<p class="depauth-subtype"><sup>1</sup>: The DepositPreauth amendment fixes a bug in DepositAuth which causes cross-currency payments to oneself to fail if the account requires deposit authorization. With only DepositAuth enabled, these cases result in "No Permission" instead.</p>
<style type="text/css">
.depauth-txtype {
font-weight: bold;

View File

@@ -46,6 +46,7 @@
"channel_verify",
"connect",
"consensus_info",
"deposit_authorized",
"feature",
"fee",
"fetch_info",

View File

@@ -70,7 +70,7 @@ Accounts with DepositAuth enabled can _preauthorize_ certain senders, to allow p
Preauthorization is currency-agnostic. You cannot preauthorize accounts for specific currencies only.
To preauthorize a particular sender, send a DepositPreauth transaction <!--{# TODO: link when the transaction reference is updated #}--> with the address of another account to preauthorize in the `Authorize` field. To revoke preauthorization, provide the other account's address in the `Unauthorize` field instead. Specify your own address in the `Account` field as usual. You can preauthorize or unauthorize accounts even if you do not currently have DepositAuth enabled; the preauthorization status you set for other accounts is saved, but has no effect unless you enable DepositAuth. An account cannot preauthorize itself.
To preauthorize a particular sender, send a [DepositPreauth transaction][] with the address of another account to preauthorize in the `Authorize` field. To revoke preauthorization, provide the other account's address in the `Unauthorize` field instead. Specify your own address in the `Account` field as usual. You can preauthorize or unauthorize accounts even if you do not currently have DepositAuth enabled; the preauthorization status you set for other accounts is saved, but has no effect unless you enable DepositAuth. An account cannot preauthorize itself.
Preauthorizing another account adds an object to the ledger, which increases the [owner reserve](reserves.html#owner-reserves) of the account providing the authorization. If the account revokes this preauthorization, doing so removes the object and the reserve decreases accordingly.
@@ -82,9 +82,19 @@ After the DepositPreauth transaction has been processed, the authorized account
Preauthorization has no effect on the other ways to send money to an account with DepositAuth enabled. See [Precise Semantics](#precise-semantics) for the exact rules.
### Checking for Authorization
You can use the [deposit_authorized method][] to see if an account is authorized to deposit to another account. This method checks two things:
- Whether the destination account requires Deposit Authorization. (If it does not require authorization, then all source accounts are considered authorized.)
- Whether the source account is preauthorized to send money to the destination.
## See Also
- The [DepositPreauth transaction][] reference.
- The [DepositPreauth ledger object type](depositpreauth-object.html).
- The [deposit_authorized method][] of the [`rippled` API](rippled-api.html).
- The [Authorized Trust Lines](authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
- The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.)
- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](become-an-xrp-ledger-gateway.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.

View File

@@ -103,6 +103,8 @@ Provides users of [deposit authorization](depositauth.html) with a way to preaut
Adds a new transaction type, DepositPreauth for adding or removing preauthorization, and a DepositPreauth ledger object type for tracking preauthorizations from one account to another. Adds a JSON-RPC command, `deposit_authorized`, to query whether an account is authorized to send payments directly to another.
Also changes the behavior of cross-currency Payments from an account to itself when that account requires deposit authorization. Without this amendment, those payments always fail with the code tecNO_PERMISSION. With this amendment, those payments succeed as they would with Deposit Authorization disabled.
## EnforceInvariants
[EnforceInvariants]: #enforceinvariants

View File

@@ -9,7 +9,16 @@ This has no effect on processing of transactions unless the account that provide
## Example {{currentpage.name}} JSON
```json
TODO
{
"LedgerEntryType" : "DepositPreauth",
"Account" : "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"Authorize" : "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"Flags" : 0,
"OwnerNode" : "0000000000000000",
"PreviousTxnID" : "3E8964D5A86B3CD6B9ECB33310D4E073D64C865A5B866200AD2B7E29F8326702",
"PreviousTxnLgrSeq" : 7,
"index" : "4A255038CC3ADCC1A9C91509279B59908251728D0DAADB248FFE297D0F7E068C"
}
```
## {{currentpage.name}} Fields
@@ -21,7 +30,7 @@ A `DepositPreauth` object has the following fields:
| `LedgerEntryType` | String | UInt16 | The value `0x0070`, mapped to the string `DepositPreauth`, indicates that this is a DepositPreauth object. |
| `Account` | String | Account | The account that granted the preauthorization. (The destination of the preauthorized payments.) |
| `Authorize` | String | Account | The account that received the preauthorization. (The sender of the preauthorized payments.) |
| `Flags` | Number | UInt32 | A bit-map of boolean flags. No flags are defined for Checks, so this value is always `0`. |
| `Flags` | Number | UInt32 | A bit-map of boolean flags. No flags are defined for DepositPreauth objects, so this value is always `0`. |
| `OwnerNode` | String | UInt64 | A hint indicating which page of the sender's owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |

View File

@@ -14,8 +14,8 @@ An example of the request format:
{
"id": 1,
"command": "deposit_authorized",
"source_account": "rnUy2SHTrB9DubsPmkJZUXTf5FcNDGrYEA",
"destination_account": "rDg53Haik2475DJx8bjMDSDPj4VX7htaMd",
"source_account": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"destination_account": "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"ledger_index": "validated"
}
```
@@ -27,8 +27,8 @@ An example of the request format:
"method": "deposit_authorized",
"params": [
{
"source_account": "rnUy2SHTrB9DubsPmkJZUXTf5FcNDGrYEA",
"destination_account": "rDg53Haik2475DJx8bjMDSDPj4VX7htaMd",
"source_account": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"destination_account": "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"ledger_index": "validated"
}
]
@@ -39,7 +39,7 @@ An example of the request format:
```bash
#Syntax: deposit_authorized <source_account> <destination_account> [<ledger>]
rippled deposit_authorized rnUy2SHTrB9DubsPmkJZUXTf5FcNDGrYEA rDg53Haik2475DJx8bjMDSDPj4VX7htaMd validated
rippled deposit_authorized rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8 validated
```
<!-- MULTICODE_BLOCK_END -->
@@ -63,26 +63,56 @@ An example of a successful response:
*WebSocket*
```json
TODO
{
"id": 1,
"result": {
"deposit_authorized": true,
"destination_account": "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"ledger_hash": "BD03A10653ED9D77DCA859B7A735BF0580088A8F287FA2C5403E0A19C58EF322",
"ledger_index": 8,
"source_account": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"validated": true
},
"status": "success",
"type": "response"
}
```
*JSON-RPC*
```json
{
"result":
{
"result": {
"deposit_authorized": true,
"destination_account": "rDg53Haik2475DJx8bjMDSDPj4VX7htaMd",
"ledger_hash": "4C99E5F63C0D0B1C2283B4F5DCE2239F80CE92E8B1A6AED1E110C198FC96E659",
"ledger_index": 14380380,
"source_account": "rnUy2SHTrB9DubsPmkJZUXTf5FcNDGrYEA",
"destination_account": "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"ledger_hash": "BD03A10653ED9D77DCA859B7A735BF0580088A8F287FA2C5403E0A19C58EF322",
"ledger_index": 8,
"source_account": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"status": "success",
"validated": true
}
}
```
*Commandline*
```json
Loading: "/etc/rippled.cfg"
2018-Jul-30 20:07:38.771658157 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"deposit_authorized" : true,
"destination_account" : "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"ledger_hash" : "BD03A10653ED9D77DCA859B7A735BF0580088A8F287FA2C5403E0A19C58EF322",
"ledger_index" : 8,
"source_account" : "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"status" : "success",
"validated" : true
}
}
```
<!-- MULTICODE_BLOCK_END -->
The response follows the [standard format][], with a successful result containing the following fields:
@@ -103,7 +133,8 @@ The response follows the [standard format][], with a successful result containin
* Any of the [universal error types][].
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `actNotFound` - An [Address][] specified in the `source_account` or `destination_account` field of the request does not correspond to an account in the ledger.
* `actMalformed` - An [Address][] specified in the `source_account` or `destination_account` field of the request was not properly formatted. (It may contain a typo or be the wrong length, causing a failed checksum.)
* `dstActMissing` - The `destination_account` field of the request does not correspond to an account in the ledger.
* `lgrNotFound` - The ledger specified by the `ledger_hash` or `ledger_index` does not exist, or it does exist but the server does not have it.

View File

@@ -47,6 +47,7 @@ Transactions are the only thing that can modify the shared state of the XRP Ledg
Paths define a way for payments to flow through intermediary steps on their way from sender to receiver. Paths enable cross-currency payments by connecting sender and receiver through order books. Use these methods to work with paths and other books.
* **[`book_offers`](book_offers.html)** - Get info about offers to exchange two currencies.
* **[`deposit_authorized`](deposit_authorized.html)** - Look up whether one account is authorized to send payments directly to another.
* **[`path_find`](path_find.html)** - Find a path for a payment between two accounts and receive updates.
* **[`ripple_path_find`](ripple_path_find.html)** - Find a path for payment between two accounts, once.

View File

@@ -10,7 +10,14 @@ A DepositPreauth transaction gives another account pre-approval to deliver payme
## Example {{currentpage.name}} JSON
```json
TODO
{
"TransactionType" : "DepositPreauth",
"Account" : "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"Authorize" : "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"Fee" : "10",
"Flags" : 2147483648,
"Sequence" : 2
}
```
{% include '_snippets/tx-fields-intro.md' %}