C++ Signing message on kucoin API - c++

I'm building a multi-exchange bot in C++ and I'm having one small problem. KuCoin exchange has proven to be frustrating to say the least, one of the headers is a signature header where you encode the string with HMAC sha256 and then encode THAT with base64. However I'm not concerned with the encoding, I can do all that. What is stumping me is the string KuCoins API is expecting, I've scoured their documentation 100 times over and I still can't get it right, here are the instructions
For the header of KC-API-KEY:
Use API-Secret to encrypt the prehash string {timestamp+method+endpoint+body} with sha256 HMAC. The request body is a JSON string and need to be the same with the parameters passed by the API.
After that, use base64-encode to encrypt the result in step 1 again.
I've attempted to craft this string in every way possible, and the documentation provides no examples on what a good string should look like, here are the strings I've crafted BEFORE encoding that DO NOT work.
EXAMPLE 1: 1616096476134POST/api/v1/orders?clientOid=55be5&side=BUY&symbol=BTC-USDT&type=MARKET&funds=0.005000
EXAMPLE 2: 1616099932367POST/api/v1/orders{"clientOid":"55be5","side":"BUY","symbol":"BTC-USDT","type":"MARKET","funds":"0"}
As you can see, in the 2nd example I tried to make the body a JSON string with all the correct parameters, but still, I'm getting a bad signature error returned. Literally all I need is to know what the string is supposed to look like so I can craft it properly. Thanks.

I take the assumption that your code works for a private request without parameters (like getting the balance for instance).
I also struggled a bit for POST requests, but managed to get it right after a few attempts. You need to dump the parameters as a JSON string without spaces, exactly like in your example 2.
Since that time, have you managed to solve it ? I have a code on my application that works if you are interested.
Also, don't forget to add in the headers of the curl request:
Content-Type: application/json

Solved with Kucoin support and pythone example.
The "body" also must be included in POST request.
Was:
reply = netman->post(req, "");
Become:
tradereply = trademan->post(req, data);

Related

Chilkat http post and respond bodystr 32000 char limitation (ChilkatAx-9.5.0-win32)

I have a problem with the response I get from the soap service.
I set the "SetSslClientCertPfx" with invoke method:
certificate name
password
I set the "SetRequestHeader" with invoke method:
Content-Type
text/xml; charset=UTF-8
I set the "SetRequestHeader" with invoke method:
SOAPAction
urloftheaction
Invoke method "PostXml":
Server link
blob with file content
utf-8
I check for errors with "get.LastErrorText"
I get the response with "get.bodyStr"
For the result, I have a char(32000) field. I tried increasing this to 64000 characters but that way I get an empty result. I also tried to replace the char field with the blob. That also didn't work. It's like the method itself is limited to 32000 chars.
I read that for large results I should use "LastStringResult" but it only works for MySQL. Is there a solution to my problem?
I'm assuming the content returned in the body of the HTTP response is XML? (or perhaps JSON?) In either case, the best thing to do is to avoid getting the returned content as a string. Let me explain...
For example, instead of calling response.GetBodyStr(), call response.GetBodyXml(xmlObj) (see https://www.chilkatsoft.com/refdoc/xChilkatHttpResponseRef.html#method4 )
The GetBodyXml method loads the response body into the XML object passed in the argument. Then your application can work with the contents of the XML via the Chilkat XML API, i.e parsing out the various parts as needed.

Web.Contents + Uri.EscapeDatastring = PARSER ERROR. PQ converts "%2F" to "/" but shouldn't

If I send a query to Google Webmaster Tool API (Search Console), it returns an error - 404 status.
Here is a query
https://www.googleapis.com/webmasters/v3/sites/www.kvadroom.ru/urlCrawlErrorsSamples/obyavleniya%2Fprodaetsiya-taunhaus-sinkovskoe%2F201437169.html?platform=web&category=soft404&access_token=ya29.FgJLUjBKLvoQWXEJN6MsHPl4awqXr33uk8wIiCN_z4WWp4175JyrQeQRjmhGfIU6pMbF
(of course token has already expired, but was actual when used. Anyway, it's not a matter of credentials)
As you can see, a part of query string is escaped - it's a requirement of GWT API - https://developers.google.com/webmaster-tools/v3/urlcrawlerrorssamples/get
If I paste query string to browser's adress bar, I get status Ok 200 with JSON response. But if I use the same query in PQ's Web.Contents, PQ parses string incorrectly - it converts (but should not) "%2F" to "/"
It says
Is it a bug or I do something wrong?
Suppose it happens only when escaped string is used in /path/ but not in ?params, i.e. precedes question mark
Update: This is a (unwanted) feature of the URL library we are using: https://msdn.microsoft.com/en-us/library/ee656542(v=vs.110).aspx
We're currently not able to support this scenario.
For anybody frustrated by this, consider starting a topic at https://ideas.powerbi.com
Nice find!
I'm not able to find any workaround to get Power Query to make a request with "%2F" in the path.
Sorry about that. I'll add a bug to our team's backlog.

Issues with raw_post_data decoding in Django

I have stumbled on a strange issue that I can't resolve:
In my Django app there is a method which gets hit by a POST from a java applet, which sends it a JSON object. Django method parses it like so:
req = json.loads(request.raw_post_data)
and based on the results returns a value. I haven't written this code, but yesterday I was sent to investigate an error triggered in this method. It was saying there was "ValueError: Expecting property name: line 1 column 1 (char 1)".
What I discovered is that my raw post data looks like this:
{#012#011"ImmutableMachineFactors": #012#011{#012#011#011"machineName": "lukka",#012#011#011"osName": "MacOS"}}
The type of it was string, however, my attempts to replace these weird characters with spaces or nothing failed. It would just ignore the sub() command. I know that raw_post_data returns a bytestring, but when I tried to convert it to a regular string using:
mystring.decode('utf-8')
it did add the u'' notation, but didn't remove those weird characters. Stranger still, in many cases (on my personal machine), Django would happily convert this kind of data into JSON, it only fails sometimes, which led me to believe that the JSON which triggered the error was malformed, but when I would strip out all the #011 and #012 characters, it parsed perfectly.
My questions are:
1) What are those crazy things? (#011, #012). I tried to google around, but these are very common things to find in a search, so I couldn't find anything relevant.
2) How can I turn this bytestring into a regular string so that I can replace those characters? Or is it the wring way to approach this problem?
Thanks!
Luka
This may be way too late to help, but since QueryDict instances (request.POST or request.DATA) are immutable, it's reasonable to expect that request.raw_post_data is also immutable. You'd have to make a copy before changing it.

How do i generate query url for Amazon SQS

I'm going to write a program can post and read messages from SQS with authentication and I've read the document from here
Link: Query Request Authentication
I have successfully written the process which post a message to specified queue follow by the document. But I always get 403 error when I try to receive message from queue. And I found the signature string rules are different for POST and GET methods.
the signature string is:
GET\n
sqs.us-east-1.amazonaws.com\n
/<My Account Id>/<Queue Name>\n
AWSAccessKeyId=<My Access Key>
&Action=ReceiveMessage
&MaxNumberOfMessages=10
&VisibilityTimeout=600
&AttributeName=All
&Expires=2012-04-01T11%3A29%3A24Z
&SignatureMethod=HmacSHA1
&SignatureVersion=2
&Version=2011-10-01
and the url is
https://sqs.us-east-1.amazonaws.com/<My Account Id>/<Queue Name>?
Action=ReceiveMessage
&MaxNumberOfMessages=10
&VisibilityTimeout=600&AttributeName=All
&Version=2011-10-01
&Expires=2012-04-01T11%3A29%3A24Z
&Signature=<BASE64 encoded HmacSHA1 digist with signature string and my security key>
&SignatureVersion=2
&SignatureMethod=HmacSHA1
&AWSAccessKeyId=<My Access Key>
And I always get the 403 forbidden error:
<ErrorResponse xmlns="http://queue.amazonaws.com/doc/2011-10-01/">
<Error>
<Type>Sender</Type>
<Code>SignatureDoesNotMatch</Code>
<Message>
The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
</Message>
<Detail/>
</Error>
<RequestId>16f6e910-62e6-4259-8c09-0358b84cbe60</RequestId>
</ErrorResponse>
Is there anyone can tell me how can I deal with it? Thanks a lot
The error message tells you that the signature is being calculated wrong. This is really tough to debug. I spent hours on it the first time I tried it. There's an example signed SQS request at http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/MakingRequests_MakingQueryRequestsArticle.html. You should put those parameters in your program, calculate the signature, and try finding bugs into your program creates the same signature.
Specific problems I had, and fixes for them included:
Sorting the query parameters correctly. They must be in ascending order when creating the string to sign. Your example URL does not show them in order. Did you sort them differently when creating the string to sign?
URI encoding properly. Every parameter must be URI encoded in the string to sign. Your sample URL does have URI encoding, so this probably isn't your issue. But make sure you're not double-encoding.
Padding the base64 signature. At least some AWS services insist that the signature be a multiple of four characters long. Two-thirds of the time a base64 encoding will be too short, and need one or two equal signs appended to it. Most base64 encoding libraries do that for you, but not all.
Of course, the easiest thing is to use somebody else's library to make the requests, but what's the fun in that? Good luck debugging this.
It's most likely the parameter order: when assembling the signature version 2 string, at the last step the Amazon documentation specifies:
Add the query string components (the name-value pairs, not including
the initial question mark (?) as UTF-8 characters which are URL
encoded per RFC 3986 (hexadecimal characters must be uppercased) and
sorted using lexicographic byte ordering. Lexicographic byte ordering
is case sensitive.
I've spent two days debugging this same "SignatureDoesNotMatch" issue by checking my HMAC, BASE64 and URL encoding procedures and it was just a problem of parameter order.
The documentation should emphasize this issue more; if you use unordered parameter strings (e.g. the same one in the request URL, like those found in the documentation examples), you're going to get this non-intuitive error from the server.

org.restlet: Posting JSON content against webservice returns HTTP error 411 (length required)

Simplified code example: http://pastebin.com/9ZQxSXi9
Hi
I wanted to experiment with the restlet 2.0 library and the gpodder webservice but somehow i reached a point where I can't see the wood for the trees.
The service in the example requires HTTP authentication and to post some JSON content to a URL.
Nothing that complicated but somehow even though the debug view claims the request object to contain the necessary content the RESTful webservice's response leads me to believe the HTTP header of the request was missing the content.
Any ideas on what's the reason? Thanks in advance.
The problem is that that none of the implementation of WriterRepresentation I've seen (JsonRepresentation, JacksonRepresentation, XStreamRepresentation) set the size of the representation when an object is passed. So if you create a new JacksonRepresentation(map) the size is not calculated.
You have to compute manually the length of the map content and calling Representation.setSize().
Or, as I did, use a
new JsonRepresentation(" a json string... ");
This constructor is able to compute the size, of course, that's the string length, so the proper content-length header is set and everything works smooth.