I am trying to fetch product related data from Amazon Product API using this URL mentioned here:
http://docs.aws.amazon.com/AWSECommerceService/latest/DG/ItemLookup.html
Item Lookup URL:
http://webservices.amazon.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=[AWS_Access_Key_ID]&Operation=ItemLookup&ItemId=B00008OE6I&Timestamp=[YYYY-MM-DDThh:mm:ssZ]&Signature=[Request_Signature]
I have entered required details/parameters in URL but I am unable to understand where to get this Signature from or how to generate this signature? Any help would be appreciated.
The easiest and fastest way would be using one of AWS SDKs. You can find the full list here: https://aws.amazon.com/tools/
When you use the SDK you just supply your access key and secret key. The libraries handle preparing the signature.
Well, there's no point in doing this by yourself in Ruby, once it has a SDK, but an explanation about signature process may be useful for some people.
Signature is the way AWS authenticates API requests. It is passed as a query string parameter on your HTTP request and is validated against your own request content and you credentials on server-side.
There are 2 versions of it: 2 and 4, explained here and here. Version 2 is not supported on newer regions (China and Frankfurt).
In version 2, which I'm more familiar with, the signature is generated based on a string with this format:
HTTPVerb + "\n" + ValueOfHostHeaderInLowercase + "\n" + HTTPRequestURI
+ "\n" + CanonicalizedQueryString
The CanonicalizedQueryString is your query string, with parameters sorted (UTF-8 byte order) by paramater names and with parameter values url-encoded.
Then you calculate an HMAC of that string, using your AWS secret key, and SHA256 or SHA1 as the hash algorithm (depending on which one you have specified on query string parameter SignatureMethod), and encode it to base64. The result of all this will be the value of the Signature parameter.
I will try to walk you through a CloudWatch request, generated manually with bash tools.
Let's say you want to list you CloudWatch metrics. The request (without the signature) would be like the following.
http://monitoring.amazonaws.com/?AWSAccessKeyId=AVUKYAMNIIGWALNMA6IG&Action=ListMetrics&SignatureMethod=HmacSHA1&SignatureVersion=2&Timestamp=2015-08-20T22%3A40%3A00.000Z&Version=2010-08-01
So, your string to sign would be:
GET
monitoring.amazonaws.com
/
AWSAccessKeyId=AVUKYAMNIIGWALNMA6IG&Action=ListMetrics&SignatureMethod=HmacSHA1&SignatureVersion=2&Timestamp=2015-08-20T22%3A40%3A00.000Z&Version=2010-08-01
Well, let's put it in a variable and do all the magic (hmac + base64)
#!/bin/bash
# your secret key
key='ry+SyjvXLvi4lYie/QfZYnxYOBQDggf01DTUxFSK'
# using 'read' to assign the signing string
# to a variable for readability reasons
read -r -d '' payload <<EOF
GET
monitoring.amazonaws.com
/
AWSAccessKeyId=AVUKYAMNIIGWALNMA6IG\
&Action=ListMetrics\
&SignatureMethod=HmacSHA1\
&SignatureVersion=2&\
Timestamp=2015-08-20T22%3A40%3A00.000Z\
&Version=2010-08-01
EOF
echo -n "$payload" | openssl dgst -sha256 -hmac $key -binary | openssl enc -base64
Then, after all this, you will end up with something like this:
xrIYF8wO0C8YOQgcdpq6MoJpBWzXEWxuTBAAoqYoGWM=
This is your signature, and finally, you just need to url-encoded it and append it to your request as one more query-string parameter.
&Signature=xrIYF8wO0C8YOQgcdpq6MoJpBWzXEWxuTBAAoqYoGWM%3D
Hopefully, if you did everything correctly (putting the sign string together, generating the hash and encoding it), your request will be accepted and, if you have enough permission, executed.
So, as you can see, it's something not worth to do by yourself. Use the SDK. ;)
Thank You guys for your response. But I have finally figured out my problem and my solution was in this gem:
https://github.com/jugend/amazon-ecs
This is what I was actually looking for and it finally helped me achieve what I was trying to. Posting it over here so people can find a better solution.
Related
i'm facing a problem regarding the shared secret in "clients.conf" file in freeradius server 3.0.25.
I tried to follow the documentation, but with no luck, in particular I'm trying to use the exact example in documentation of the octal representation of the secret "AB":
clients.conf:
secret = "\101\102"
then I run the radtest:
./radtest -x testing password localhost 0 "AB"
in server debug log I find:
"Dropping packet without response because of error: Received packet from 127.0.0.1 with invalid Message-Authenticator! (Shared secret is incorrect.)"
I tried every combination that come in mind: with or without quotes, with the "-t eap-md5" parameter in radtest, ..
Of course if I write 'secret = "AB" ' in clients.conf everything works, but I need octal representation because a client of ours uses special non printable characters in the secret.
Any help is appreciated
Thanks
I was able to make it work by changing the default value of parameter correct_escapes in file radiusd.conf:
correct_escapes = false <-- it was 'true' by default
Still is not clear to me why it doesn't work with correct_escapes set to 'true', maybe it's a bug?
I am trying to follow the guide to generate Oauth authentication tokens for YAHOO DSP API.
Base64 encoding is a way of encoding binary data into text so that it can be easily transmitted across a network without error.
In this step, you will take the client ID and client secret that the YDN console generated for you and encode them using the base64 protocol. You can use an online encoding service like base64encode.org.
No matter which service you use, ensure that no spaces are appended to the CLIENT_ID and CLIENT_SECRET keys and separate the CLIENT_ID and CLIENT_SECRET with a colon, i.e. CLIENT_ID:CLIENT_SECRET.
The generated value will now be referenced as ENCODED(CLIENT_ID:CLIENT_SECRET) in this guide.
An example is given:
CLIENT_ID = dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
CLIENT_SECRET= a7e13ea3740b933496d88755ff341bfb824805a6
AUTHORIZATION = ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Using the recommended website I get the wrong AUTHORIZATION.
I have tried both encoding the whole thing at once ie. encode(CLIENT_ID:CLIENT_SECRET), and each element individually encode(CLIENT_ID):encode(CLIENT_SECRET).
Attempt encoding whole thing:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCTOiBhN2UxM2VhMzc0MGI5MzM0OTZkODg3NTVmZjM0MWJmYjgyNDgwNWE2
Attempt encoding each element:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCT:YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Expected result:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
The difference between 'each element' and the expected result is only a few characters corresponding to the end of client_ID and the colon.
B4oCT: should be BLS06.
Links to full documentation:
https://developer.yahoo.com/dsp/api/docs/authentication/tokens.html
https://developer.yahoo.com/dsp/api/docs/traffic/info/sandbox.html
Update:
The final character of Client_ID is '–' . This is some sort of non-standard character that is interpreted as two dashes i.e.'--' in utf-8 and windows 1258.
One different, TO NOTE is, that when you decrypt the expected output you will get your client id as
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA--
instead of
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
NOTE, there are two "-" at the end.
OAuth client auth token is always generated using Base64 encoding with following format
Base64_Encoding(CLIENT_ID:CLIENT_SECRET)
Most of the usage perform this Base64 encoding with encoding type as "UTF-8".
It looks like, Yahoo requires this token with different encoding. On "https://www.base64encode.org/" if you try to encode your "CLIENT_ID:CLIENT_SECRET" with "Windows-1254" as destination charset, you will receive the expected result. So, it looks like both encoding and decoding here is done keeping "Windows-1254" charset in place.
We are forming android hybrid app via Phonegap. Using the PayTm web integration kit.
Checksum is generated properly. But when the form is submitted for the payment **Invalid Checksum ** issue is returned.
https://developer.paytm.com/docs/api/initiate-transaction-api/?ref=payments
NOTE: Create the signature using the body parameter of the request in
the same sequence as you pass in the request.
example:
body = {"mid":"MID
HERE","websiteName":"WEBSTAGING","orderId":"ORDERIDHERE","txnAmount":{"value":"10.00","currency":"INR"},"userInfo":{"custId":"CUSTOMERID_HERE"},"callbackUrl":"https://securegw-stage.paytm.in/theia/paytmCallback?ORDER_ID=ORDERID",
"requestType":"Payment"}
Create json
json_body = body.to_json
#RUBY ON RAILS https://github.com/paytm/Paytm_Ruby_Checksum
generated_signature = PaytmChecksum.new.generateSignature(json_body, MERCHANT_KEY_HERE)
curl -X POST 'https://securegw-stage.paytm.in/theia/api/v1/initiateTransaction?mid=MID HERE&orderId=ORDERID_HERE' \
--header 'Content-Type: application/json' \
--data '{"body":{"requestType":"Payment","mid":MID_HERE,"websiteName":"WEBSTAGING","orderId":ORDER_ID_HERE,"txnAmount":{"value":"10.00","currency":"INR"},"userInfo":{"custId":CUSTOMER_ID},"callbackUrl":"https://securegw-stage.paytm.in/theia/paytmCallback?ORDER_ID=ORDER_ID_HERE"},"head":{"signature": generated_signature}}'
As you noted that I pass the body parameter in the same sequence that I used while creating signature(checksum) as in the request body parament.
i have faced the same issue for more than 2 days. i integrated PAYTM on ionic 4. my mistake was, my "TXN_AMOUNT" is in whole amount. "TXN_AMOUNT" should be in decimal number. e.g 199.33, 152.56.
On the other hand "READ THE PAYTM INTEGRATION GUIDE" carefully. it's actually quite good.
https://developer.paytm.com/docs
First try to run with postman
You will get postman collection from paytm just you need to paste key mid there
You will get the response
And please check
The parameter body should be same while creating check sum
Space is not allowed in request body even in json request
Kindly pass the same parameters value in the request which is used while generating the checksum. Also refer the paytm checksum docs available on paytm developer portal.
I'm trying to get an Application Only Auth token following the steps of this link:
https://dev.twitter.com/docs/auth/application-only-auth
I'm using Ruby on Rails and Rest Client to make the POST request needed and I'm setting the headers (I think) properly.
The step-by-step says:
URL encode the consumer key and the consumer secret according to RFC
1738. Note that at the time of writing, this will not actually change the consumer key and secret, but this step should still be performed
in case the format of those values changes in the future.
Concatenate the encoded consumer key, a colon character ":", and the
encoded consumer secret into a single string.
Base64 encode the string from the previous step.
And my code is:
require 'rest_client'
key = URI::encode('app_key')
secret = URI::encode('app_secret')
encoded = Base64.encode64("#{key}:#{secret}")
res = RestClient::Resource.new "https://api.twitter.com/oauth2/token/"
response = ''
options = {}
options['Authorization'] = "Basic #{encoded}"
options['Content-Type'] = 'application/x-www-form-urlencoded;charset=UTF-8'
res.post('grant_type=client_credentials', options) do |response, request, result|
response << "#{CGI::escapeHTML(response.inspect)}<br /><br />"
response << "#{CGI::escapeHTML(request.inspect)}<br /><br />"
response << "#{CGI::escapeHTML(result.inspect)}<br />"
end
render :text => txt
And I print out this:
"{\"errors\":[{\"label\":\"authenticity_token_error\",\"code\":99,\"message\":\"Unable to verify your credentials\"}]}"
#<RestClient::Request:0x9ece5d8 #method=:post, #headers={"Authorization"=>"Basic bXlfa2V5Om15X3NlY3JldA==\n", "Content-Type"=>"application/x-www-form-urlencoded;charset=UTF-8"}, #url="https://api.twitter.com/oauth2/token/", #cookies={}, #payload="", #user=nil, #password=nil, #timeout=nil, #open_timeout=nil, #block_response=nil, #raw_response=false, #verify_ssl=false, #ssl_client_cert=nil, #ssl_client_key=nil, #ssl_ca_file=nil, #tf=nil, #max_redirects=10, #processed_headers={"Accept"=>"*/*; q=0.5, application/xml", "Accept-Encoding"=>"gzip, deflate", "Authorization"=>"Basic bXlfa2V5Om15X3NlY3JldA==\n", "Content-Type"=>"application/x-www-form-urlencoded;charset=UTF-8", "Content-Length"=>"29"}, #args={:method=>:post, :url=>"https://api.twitter.com/oauth2/token/", :payload=>"grant_type=client_credentials", :headers=>{"Authorization"=>"Basic bXlfa2V5Om15X3NlY3JldA==\n", "Content-Type"=>"application/x-www-form-urlencoded;charset=UTF-8"}}>
#<Net::HTTPForbidden 403 Forbidden readbody=true>
My key and secret are valid.
Am I missing something?
Thanks!
EDIT:
Updating with the solution I've found.
The problem was on the Base64 convertion and string encoding.
I had to add a forced encoding parameter to the key+secret combination, for UTF-8 convertion:
encoded = Base64.encode64("#{key}:#{secret}".force_encoding('UTF-8'))
The Rails Base64.encode64 inserts a line break every 60 encoded characters.
The workaround was:
For Ruby 1.9+ (strict_ was included in Ruby 1.9)
Base64.strict_encode64(string)
For Ruby 1.9-
Base64.encode64(string).gsub('/\n/') # To remove the line break
Are you trying to implement Authorization with Tweeter (as OAuth Provider). Instead of writing it from the scratch following the API documentation, I would suggest to use OmniAuth. The setup & boilerplate code is fairly easy to use.
Read more about it at http://www.omniauth.org/ & https://github.com/intridea/omniauth/wiki
Let us know, if that helped you or not.
so, I just need to retrieve user basic info(/verify_credentials(twitter), /me(facebook) so Im trying to roll my own code for now
got it on facebook on second try since all I need is a request to graph.facebook.com/me + access_token
but now trying to do it with twitter has been incredibly painful, I just can't figure it out by the docs, so, please, what does a request to twitter api /verify_credentials look like?
what are the params?
twitter api, y u suck?
Facebook uses oAuth 2.0, which is much easier to implement than oAuth 1.0 (which twitter uses).
An example request to verify_credentials API could look like this:
https://api.twitter.com/1/account/verify_credentials.json?oauth_consumer_key=XXX&oauth_nonce=XXX&oauth_signature_method=HMAC-SHA1&oauth_token=XXX&oauth_timestamp=123456789&oauth_version=1.0&oauth_signature=YYY
oauth_consumer_key is self explanatory
oauth_nonce can be pretty much a random string of characters
oauth_signature_method is always HMAC-SHA1
oauth_token is your access token
oauth_timestamp is current UNIX timestamp (in UTC)
oauth_version is always 1.0
oauth_signature is your generated signature (which twitter will verify by reproducing)
You generate the value of the oauth_signature parameter by constructing a signature base string which consists of the following parts.
HTTP method in upper case (in this case GET)
an ampersand &
URL-encoded base URI (everything from https up to and including verify_credentials.json)
an ampersand &
all request parameters in alphabetical order, url encoded. (oauth_signature should NOT be included in this though)
The pseudo code in the section Signing requests in Twitters documentation describes the signing process elegantly:
httpMethod + "&" +
url_encode( base_uri ) + "&" +
sorted_query_params.each { | k, v |
url_encode ( k ) + "%3D" +
url_encode ( v )
}.join("%26")
And then you sign the resulting base string using the consumer secret, and the access token secret. That's all there is too it :)
But before issuing any requests to the API you will of course need to actually get an access token. Once you grasp the oAuth 1.0 flow, and the signing process. You'll be home. Twitter's documentation does a great job at explaining the process, but it is a quite a bit to wrap your head around. Worth it though.