Trying to understand the Authentication page in the API Section

[matthewbretherton]

I am having trouble authenticating in ruby and as a result have read the code in the python and the two ruby sections of this site. I am unclear on certain issues and seek resolution of the 8 questions below

In reference to https://github.com/BTCMarkets/API/wiki/Authentication

Apologies for being pedantic but this is often necessary when things are not working

1. Does 'API private key' == 'secret' in this page and also == 'Private (secret) API Key' on the BTC markets web site ( Account->Api tab) ?

2. This page mentions 'Secret key must be encoded to base64' but the review code seems to be Decoding e.g. Base64.decode64(ENV['btcm_access_secret']) in ruby. I also presume that this is before being used to create the signature

3. Does 'public key' == 'your API key' in this site and == 'Public API Key' on the BTC markets web site ( Account->Api tab) ?

4. You supply a worked example the section 'Authentication example' and show a sample signature. Can you please provide the secret key that was used to create this signature ? This would allow the construction of an independent unit test ( i.e. allow test driven development ) This could be any secret . . . not one attached to a BTC account but just one used to create this documented example

5. It is not clear when to base64 code and decode. Reading the three code sets it seems 5a) the secret key as supplied from the BTC web site must be base64 decoded before signing ( ref point 2 above ) 5b) the signature needs to be base64.encoded before dispatch to BTC web site ( only performed in the code . . . not documented in the authentication page )

6. When this page says 'Now we are ready to build a http request with all the headers and parameters required', it is then unclear which of the following bullet points relate to headers and which relate to parameters . . . All the code I have reviewed treats all as headers and none as parameters ( I am presuming parameters are part of the url after the ? )

7. The advice 'The order of post variables is important and must be exact otherwise an invalid HMAC will be created.' is not clear . . . what is meant by exact. After consideration I feel that this is trying to say that the order as contained in the Json payload of the post body must be the same as the order supplied to the signing process. I suspect this means that the same son String is used in both processes but as I don't have any working code I can on postulate this simplification of specification. Please supply a clarification ?

Rgds Matthew B

[matthewbretherton]

In another article Justin wrote

' the order of variables in the POST request body must match exactly the order documented in the sample requests provided on the various wiki pages '

This answers question 7 above and it would be excellent if the wiki page on authentication could be updated to reflect this classification

This may also answer comments through he published code that suggest problems with the api which may just relate to the clarity of specification

Assistance appreciated Justin

[justin-ngin]

Does 'API private key' == 'secret' in this page and also == 'Private (secret) API Key' on the BTC markets web site ( Account->Api tab) ?

Yes

This page mentions 'Secret key must be encoded to base64' but the review code seems to be Decoding e.g. Base64.decode64(ENV['btcm_access_secret']) in ruby. I also presume that this is before being used to create the signature

Apologies, the documentation will be updated. Before the private (secret) key is used anywhere, it should be DECODED in base64.

Does 'public key' == 'your API key' in this site and == 'Public API Key' on the BTC markets web site ( Account->Api tab) ?

Yes

You supply a worked example the section 'Authentication example' and show a sample signature. Can you please provide the secret key that was used to create this signature ? This would allow the construction of an independent unit test ( i.e. allow test driven development ) This could be any secret . . . not one attached to a BTC account but just one used to create this documented example

I will revise that section of the auth page to include a sample secret key, timestamp, and post data and the resulting correct signature for verification of correct authentication process by users.

It is not clear when to base64 code and decode. Reading the three code sets it seems 5a) the secret key as supplied from the BTC web site must be base64 decoded before signing ( ref point 2 above ) 5b) the signature needs to be base64.encoded before dispatch to BTC web site ( only performed in the code . . . not documented in the authentication page )

The secret key is to be decoded before use as a key for the HMAC, and the entire HMAC encoded to base64 before sending. (Will update the documentation for this as well).

When this page says 'Now we are ready to build a http request with all the headers and parameters required', it is then unclear which of the following bullet points relate to headers and which relate to parameters . . . All the code I have reviewed treats all as headers and none as parameters ( I am presuming parameters are part of the url after the ? )

I will address this in the documentation. As of this writing, each of those bullet points is a header.

The advice 'The order of post variables is important and must be exact otherwise an invalid HMAC will be created.' is not clear . . . what is meant by exact. After consideration I feel that this is trying to say that the order as contained in the Json payload of the post body must be the same as the order supplied to the signing process. I suspect this means that the same son String is used in both processes but as I don't have any working code I can on postulate this simplification of specification. Please supply a clarification ?

I believe I addressed this in #117 , but to clarify again: yes the string used to create the signature should be the very same one that is sent as POST data, and the order of the arguments in that string must match exactly the sample requests listed on each wiki page. Because some languages do not follow a set order for HTTP body data variables, we recommend creating a string out of the object first, and using that as both the string for signing as well as the body of the request so that the order remains the same.

Cheers, Justin

[matthewbretherton]

Justin, excellent and informative response

Feel; free to email me at matthew@bretherton.id.au when the wiki page is corrected and I will work through and carefully check the corrected wiki page.

I am still having difficulty authenticating the simple 'get' request for account/balance via the ruby gems and any assistance there would be greatly appreciated

Matthew B

[Ad0be]

Matthew and Justin,

Just wanted to say thank you for the well written questions and the answers, my list of questions and thoughts was similar, and though still no luck getting authentication to work has narrowed down some possibilities.

Cheers,

Kane.