Grin: Send API route fails unexpectedly (issue_send_tx)

[gavinmcdermott]

Calling the issue_send_tx endpoint with a valid body fails unexpectedly.

The url:

http://localhost:13420/v1/wallet/owner/issue_send_tx

The error:

Generic error: Invalid request body }
Sep 13 17:31:44.603 ERRO Request Error: Error { inner:

The rust controller expects:

api.issue_send_tx(
  args.amount,
  args.minimum_confirmations,
  &args.dest,
  args.max_outputs,
  args.num_change_outputs,
  args.selection_strategy_is_use_all,
)

the browser/client sends this in the body:

{
  amount: 1,
  minimum_confirmations: 0,
  dest: 'http://127.0.0.1:13415',
  max_outputs: 500,
  selection_strategy_is_use_all: true,
  num_change_outputs: 1
}

Notes:

I reproduced the error on both the client I'm working on, and the grin-web-wallet.

Thanks for your help on this.

[quentinlesceller]

It's to be expected, no ?
Also currently the SendTxArgs are the following: https://github.com/mimblewimble/grin/blob/dd1cef2148babfc4d60478cbb35bd1505453aad5/wallet/src/libwallet/types.rs#L639-L657 (missing the method field). And normally on the web wallet https://github.com/mimblewimble/grin-web-wallet/pull/5 should handle that change.

[gavinmcdermott]

Thanks for the note—and I suppose the error is to be expected with that property missing (though clearer error messages would be helpful at some point).

However, I am still receiving the same error with the updated body. This happens both from the client (also reproduced with Postman).

From the client:

{
    this.amount = 1
    this.minimum_confirmations = 0
    this.method = 'http'
    this.dest = 'http://127.0.0.1:13415'
    this.max_outputs = 500
    this.num_change_outputs = 1
    this.selection_strategy_is_use_all = true
    this.fluff = false
}

Postman:

Error:

Sep 14 09:59:37.574 ERRO Request Error: Error { inner:
Generic error: Invalid request body }

[quentinlesceller]

Looks like your call is missing something.
Try this

curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"amount":1,"minimum_confirmations":1,"method":"http","dest":"http://127.0.0.1:13415","max_outputs":500,"num_change_outputs":1,"selection_strategy_is_use_all":true,"fluff": true}' \
  http://127.0.0.1:13420/v1/wallet/owner/issue_send_tx

I agree that we should make the error clearer if possible.

[gavinmcdermott]

Thanks for the note @quentinlesceller, the setup you show does work using curl. But there is an unexpected behavior that arises that when using a JS client library like axios or fetch.

When directly setting the (_capitalized_) Content-Type header property, the Grin daemon returns the error Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

In order to have a POST request to to issue_send_tx successfully return, I end up needing to set the (_lowercase_) content-type property:

...
headers: {
  'content-type': 'text/plain'
},
...

Note that setting the (_lowercase_) content-type to application/json yields the same error I mentioned above above.

Also: @hashmap - thanks for working to improve the state of error messages. They are pretty opaque to clients currently—much appreciated!

[quentinlesceller]

Could it be because the endpoint is not CORS enabled ?

[gavinmcdermott]

Not certain, but it is the likely culprit. I'll poke around to better understand and follow up.

Also, regarding sending to yourself when using an http endpoint, I'd like to confirm that it is the expected behavior that transactions (sent to yourself using http) are automatically received, finalized, and broadcasted to the network.

Is it the expected behavior that a user manually needs to receive and finalize a tx that has been sent to themselves?

[quentinlesceller]

Regarding CORS, I believe most endpoints are not CORS enabled. See https://github.com/mimblewimble/grin/blob/274df3b8bb0484ddabb317160e962e3953d335d8/wallet/src/libwallet/controller.rs#L535-L536 for example, will open issue for that.

[hashmap]

@gavinmcdermott do you run a web client loaded from a different origin and make request to the wallet api?

[kibagateaux]

I'm facing the same issues as @gavinmcdermott when calling the /issue_send_tx route receiving the CORS preflight Content-Type error. I tried on two different browsers since I was using Brave and thought that might have been the issue but the error also occurs when using Chrome. Finding this thread, Gavin's fix of adding the header in front-end call didn't work for me.

Running on
Grin Version: v0.4.1
Browser: Chrome + Brave
Origin : localhost:3000
Grin API: http://localhost:13420/v1/wallet/owner/issue_send_tx

The Fix

I adjusted headers in grin/wallet/src/libwallet/controller.rs using wildcard and strictly allowing only Content-Type on response and create_ok_response, ran cargo build, restarted the wallet, and then the transaction could go through with no API errors (at least related to this issue).

Also note that the Grin API expects an unwrapped object with the transaction data. Originally I was calling it withaxios.post(send_tx_url, {headers: {...}, data: tx}) and had to correct it to axios.post(send_tx_url, tx) which could be why changing my headers on the front end didn't work at first.

[gavinmcdermott]

Question for @quentinlesceller:

The issue has evolved with the latest code.

I'm now making a CORS GET request to http://localhost:13420/v1/wallet/owner/retrieve_summary_info. As a result, Chrome automatically makes a pre-flight OPTIONS request. This returns a 401 Unauthorized (as it should) because of the missing Authorization header.

But we can't configure the browser's pre-flight behavior, and the Authorization header isn't an approved header for this call anyway. Are you comfortable removing the Authorization header requirement for the OPTIONS pre-flight request?

---

As an interim stopgap solution: @kibagateaux - were you able to get the authorization header working on the pre-flight OPTIONS request? If so, please share :)

[quentinlesceller]

@gavinmcdermott I think you're right and we should accept OPTIONS requests without requiring authentication. Let me see how we can fix that.

[gavinmcdermott]

Thanks @quentinlesceller—great to hear. Can you give a heads up as to when you think this patch will be added (currently is a blocker)?

[kibagateaux]

I will be working on my wallet again this weekend. I'll update you @gavinmcdermott if I run into the issue again and if I find a more permanent fix.

[quentinlesceller]

@gavinmcdermott I started to take a look. However it does not seems to be a trivial change. I'll give it another try this week.

[gavinmcdermott]

Thanks @quentinlesceller—much needed.