OpenBazaar-Server
OpenBazaar-Server copied to clipboard
POST contracts fails
For some users, when saving a listing the POST to contracts returns
{ "reason": "", "success": false }
Client issue https://github.com/OpenBazaar/OpenBazaar-Client/issues/1249
No update? :(
I removed hyphens/dashes from the title and it saved! Please look into this. Also it didnt work with a "®" in the title. So it looks like it doesn't like some formatting. Surely a "-" should be allowed though.
We're actively working on this, along with other issues.
The issue with dashes seems to have been resolved, but special characters like ® still result in
{ "reason": "", "success": false }
I'm going to need to go line by line through the contract and sanitize it at some point.
I'm also getting this error when trying to add new moderators for my store. "data could not be saved" "vendor_offer"
I also have this problem, using accented/special chars only on the title, on the other fields (including tags) it worked fine.
To solve this we need to give all endpoints returning JSON the same treatment as was given here: https://github.com/OpenBazaar/OpenBazaar-Server/pull/358
Essentially, sanitization needs to be done prior to JSON serialization, since sanitizing an already serialized string sometimes produces malformed JSON.
It is on my to-do list to take care of this in the near future.
I am having this same issue, when trying to post a contract it simply returns:
{
"reason": "",
"success": false
}
How to debug this? The debug.log does not show anything related to the API request?
@bitcoincoltd are you using any special characters in the title, description, or other freeform text fields of your listing?
Until we have the sanitization corrected, which we're working on now, special characters can't be saved.
Here's the really basic example that I'm POSTing (no special characters).
expiration_date=&metadata_category=physical%20good&title=TestProduct&description=This%20is%20a%20test%20proudct%20do%20not%20buy%20it¤cy_code=USD&price=9.99&nsfw=&process_time=1-2%20business%20days
If I remove any more fields it will start to give a reason (ie remove the expiration_date and it will give reason: expiration_date)...but if I add any more fields the reason will still be empty.
I have recreated @bitcoincoltd's example POST in OBarc in testnet:
https://github.com/inertia186/obarc/commit/0f3a71ffced4f792a2e0307502c7ccdd4e759d2e
Is it possible for someone to give me some POST data that does work with the API, ie some sample data that successfully creates a product over CURL, so that I can compare it to my failing data and see what I'm doing wrong.
yes please, that would be a great help. I have tried a lot of different combinations and havent found a set of values that will be accepted by the API.
@hoffmabc has given a working CURL request on reddit; which I can confirm does work:
curl -H "Cookie: TWISTED_SESSION=9722f2ed04cfabba15fdf9d8ef42f50f" -X POST -d "expiration_date=&metadata_category=hysical%20good&title=AWESOME&description=Test%20Description¤cy_code=BTC&price=0.0015&process_time=1&nsfw=false&terms_conditions=&returns=&shipping_currency_code=BTC&shipping_domestic=0&shipping_international=0&category=&condition=New&sku=&images=5f4cd3e4304a5da50992ac077cf319543da89625&free_shipping=true&moderators=[]&keywords=['test']&contract_id=&ships_to=UNITED_STATES&shipping_origin=UNITED_STATES" http://localhost:18469/api/v1/contracts
Ok, found my problem...fields with a true/false bool I had them empty for false, when it needed to string 'false'
Example (this):
nsfw=false&free_shipping=false
And NOT this:
nsfw=&free_shipping=
I noticed a discrepancy to the documentation (https://gist.github.com/drwasho/bd4b28a5a07c5a952e2f). In the documentation the parameter "shipping_regions" is described, but in the succesfull query the parameter name is "ships_to".
A glance on the source code in restapi.py line 556 seems to confirm that "ships_to" is the correct name:
shipping_regions=request.args["ships_to"] if "ships_to" in request.args else None
@drwasho : could you change the documentation there?
Just to clarify, the sanitization fixes fixed the malformed json issue. The fact that it's choking on special characters is a different issue and I don't think it's related to sanitization, since the contract POST doesn't do any sanitization (it just returns an id on success).