Constrain token payment by auth entries #31
Conversation
…ctId mismatch, and sub invocations to token payment simulation
|
Preview is available here: |
|
Preview is available here: |
aristidesstaffieri
changed the title
|
Preview is available here: |
1 similar comment
|
Preview is available here: |
src/helper/error.ts
Outdated
| export const ERROR = { | ||
| ACCOUNT_NOT_SOURCE: | ||
| "Transfer contains authorization entry for a different account", | ||
| FOREIGN_CONTRACT_AUTH: |
There was a problem hiding this comment.
did we mean to use this error in this pull request or are you planning to use it in a follow-up change?
There was a problem hiding this comment.
Actually I'll remove that one, @sisuresh pointed how that check was already covered.
There was a problem hiding this comment.
removed in 3272c3c
src/route/index.ts
Outdated
|
|
||
| const built = preparedTransaction.build(); | ||
| const sorobanOp = built | ||
| .operations[0] as Operation.InvokeHostFunction; |
There was a problem hiding this comment.
should we inspect all operations or is only looking at the first one always sufficient?
There was a problem hiding this comment.
In the case of a tx with an InvokeHostFunction, there can only be 1 operation. We could check for the operation type here but only the InvokeHostFunction type has auth. I'll add an explicit check for the op type though, that seems a bit more clear.
There was a problem hiding this comment.
Added an explicit check for op type in 3272c3c
…or from mercury, removes unused token sim error
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
Adds checks during token simulation to attempt to constrain simulation to a typical transfer implementation.