Expect full ILP packet & add disallowOverPayment #16
Conversation
before interledgerjs/ilp-connector#195 the connector would strip the ilp packet and only pass on the data field. this change makes the receiver expect and validate the full request packet. it also keeps the old behavior because *.ilpdemo.org has not yet been updated with the latest connector fixes #15
by default the receiver will accept incoming transfers where the amount is greater than requested. this adds an option to require that transfer amounts exactly match the requested amount
| @@ -24,6 +24,7 @@ const BigNumber = require('bignumber.js') | |||
| * @param {ilp-core.Client} [opts.client] [ilp-core](https://github.com/interledger/js-ilp-core) Client, which can optionally be supplied instead of the previous options | |||
| * @param {Buffer} [opts.hmacKey=crypto.randomBytes(32)] 32-byte secret used for generating request conditions | |||
| * @param {Number} [opts.defaultRequestTimeout=30] Default time in seconds that requests will be valid for | |||
| * @param {Boolean} [opts.disallowOverPayment=false] Require that incoming transfer amounts exactly match the requested amount | |||
There was a problem hiding this comment.
I would reverse this: allowOverPayment=false.
I get that overpayment is theoretically good for the recipient, but in practice isn't it just going to mean that some error happened and if you don't decline the payment you're going to have to manually go in an fix it later?
At least in ITP it seems like overpayment would be an indicator of a serious problem and should be rejected. And if somebody truly needs it they can set allowOverPayment.
Also, I think it should be allowOverpayment, see overpayment.
There was a problem hiding this comment.
new commit changes this behavior
add allowOverPayment option to allow incoming transfers where the amount is greater than requested
Current coverage is 99.13% (diff: 100%)@@ master #16 diff @@
==========================================
Files 3 3
Lines 100 116 +16
Methods 9 9
Messages 0 0
Branches 17 23 +6
==========================================
+ Hits 99 115 +16
Misses 1 1
Partials 0 0
|
|
@justmoon note that one result of requiring the incoming amount to exactly match the requested amount is that we'll need to round the amount given by the user to the receiving ledger's precision when creating the request. Otherwise, you could have a request that would be impossible to fulfill. |
|
Alternatively, we could allow transfer amounts that are greater than the requested amount because of rounding |
Good observation. Should be doable since the receiver is guaranteed to have a relationship to their ledger. We probably want to always round up to avoid weird exploits. (I can create money by depositing 0.00499 into a wallet a million times.) LGTM |
The receiver should expect the full ilp packet (request) in the incoming transfer data field.
This also adds an option to require that incoming transfer amounts exactly match the requested amount.