So I've just been fighting shadows in the Amazon labyrinth. Went to use the Amazon Product Advertising API Scratchpad to test out my Access Key Id and Secret Access Key, as well as entering the Associate Tag which isn't used in critically in the API query, just important if you want credit for the query later.
I kept getting the following error, no matter how many times I went and created a new set of keys or verified them in the download section of the AWS Management Console for the root user - IAM users don't work in the API seemingly.
Error! SignatureDoesNotMatch
HTTP Status 403: Forbidden
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.
Rinse and repeat. Many, many times. Complete and utter frustration....
Lo and behold, I come across this oasis of sanity - Signed Request Helper - which provides a successful result to my query with the same keys as used above.
So, can anyone else confirm problems with the Scratchpad that didn't bear out in other applications, like the Signed Request Helper or their own code? At this point I'm betting that there is a bug in the Amazon Scratchpad. I guess I will go roll something to test in Python but the apparent craziness of the URL construction makes me wary. Seemingly it's soo hard even the Amazon guys got it wrong...
Yes, this reminds me of the dark days I had trying to get the signature just right.
I too had similar troubles when I started playing with the API. Ultimately, I ended up using the master credentials. This link will take you to the right spot after you login. Open the "Access Keys" tab. This is the area I made a new master access key for signing requests. When you get into the users/groups/roles/policies, I had trouble.
But I have a key there and I can use the scratchpad no problem. I have an application running that uses the key, but I just went and tried a query to confirm it's all still good.
Note that in the scratchpad the Associate Tag is irrelevant like you said. To get the error you have, it's for sure the SECRET ACCESS KEY that is incorrect. If you entered the ACCESS KEY ID field incorrectly, you would get this error:
Error! InvalidClientTokenId HTTP Status 403: Forbidden The AWS Access
Key Id you provided does not exist in our records.
For others who may come across this, let me impart my findings. Importantly, I was able to verify the keys with the Signed Request Helper but wasn't able to get the query to work in the Scratchpad. The error received clearly informs me that it is the signature that is wrong:
Error! SignatureDoesNotMatch HTTP Status 403: Forbidden 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.
So one ponders, as instructed, on the Secret Key and the signing method. Since one is using the scratchpad, it must be the key. But the same key works in the signed request helper! What to do.
It turns out that the error was in one of the supplied parameters. If the scratchpad produces a signed url with a faulty parameter, it will result in that error. There is some validation going on, but you can still wind up with a bad parameter. So, if you get the above error, try a simple query with your key to prove that your secret access key is valid, then start investigating your supplied parameter values.
Related
I wanna access to OroPlatform API but unfortunately, I'm still getting message:
{"error":"no_encryption_key","error_description":"The encryption key does not exist.","message":"The encryption key does not exist."}
I have already create oauth_private.key and oauth_public.key in /var forlder. Currenlly in my dashboard I achieved delete the message of contact with the administrator for the key. But still I can request from Posman or another client.
I have tried with all these methods without success:
https://doc.oroinc.com/api/authentication/oauth/#:~:text=Authentication-,OAuth%20Authentication,-Authorization%20Code%20Grant
I'm getting crazy with this issue. Somebody can help me please??
What are the possible reasons that can cause token to become expired (besides having the user un-authorising the app)?
My problem is that I have an app with several thousands of users, all API communication works perfectly but for some users I am getting the invalid or expired token error, my initial though was that they are users who canceled the authentication to the app but I've contacted some of them and they haven't revoked the access.
Any ideas what other issues can cause that error?
Check the integrity of an access token at any time by calling the GET account/verify_credentials while using that access token.
Its mentioned and by research I came to know that:
Your access token will be invalid if a user explicitly rejects your
application from their settings or if a Twitter admin suspends your
application. If your application is suspended there will be a note on
your application page saying that it has been suspended.
Why is my twitter oauth access token invalid / expired ?
Check this post: invalid / expired access tokens.
There is one post in google groups that says:
You don't get a second chance, and this is by design. OAuth requests
have a unique signature; once a particular request is submitted, it
can't be submitted again.
If they enter the pin correctly, all is well, you get an access token.
If they enter the pin wrong, you get 401 Unauthorized - which is
expected.
But if they then try again to enter the pin, even the correct pin
shows as unauthorized.
Check this link for the above reference.
Some suggestions by twitter employee for the same problem:
I guess there are two things I would suggest at this point: 1.) Go to
your application settings and use the "Reset keys" tab to reset your
consumer key and secret, then update those values in the app and
verify that you still see the same behavior. 2.) Try passing
oauth_callback in your request_token call. Honestly I don't think this
will make a difference, but I want to try and be as rigorous as I can
here.
Also check this discussion saying:
You need to use the oauth_token and oauth_token_secret returned from
the oauth/access_token call instead of the one in your app's settings
in dev.twitter.com
I was getting same error then I changed (access_token) to (access_token_key) and it worked for me.
I hope it will help someone.
In addition to the comments everyone else has made, sometimes the twitter api will return a "invalid token" error when the token isn't the problem. I've noticed it the most when I've built a request string that doesn't parse correctly. For example, once I was getting that error when I was passing in screen_name's that had symbols that weren't URI-encodable. I also have gotten it when I passed in empty values like this (where the cursor is empty):
https://api.twitter.com/1/followers.json?cursor=&screen_name=whatevah
Could you give us the specifics of the calls that are returning this error?
Have you confirmed that the tokens worked at one time? In an OAuth system I worked on, there was an error in how tokens were securely stored and retrieved that caused a small percentage of them to become corrupted. If you can confirm that the tokens worked in the past, that's a good first step.
When you retrieve the tokens from storage, are they unchanged? Is it possible for them to get corrupted with the way you're managing them?
Put some logging in place to keep track of when tokens work and fail. Does a token ever start working again after it has failed once? If you fail to use a token for 30 days, does it expire? With a detailed log, you can start identifying the expired tokens and look for patterns in use to point to what might cause them to expire.
Be sure to explore other possibilities as well. How do users revoke tokens in Twitter? Is it easy to accidentally do that? For users with failed tokens, do they have other authorized apps that have stopped working as well?
First of all nice question Ran.
I want to ask you that have you gone through Twitter developers??
Sometimes it becomes ambiguous that which token to use since Twitter provides two pairs of tokens and the library.One of them is a secret key.
You need to select those token which starts with your Twitter ID followed by a hyphen.
Now your question is this error happens with some of yours users. So here is the answer that an app itself finds ambiguous to choose the token.
Though I might not be completely right, but I recommend you to try this solution at least once.
It might be possible these users have not revoked access. But in my experience an access token can also get expired after the user (in test cases: me) changed his/her password.
When the user does that, you can no longer use the REST API of stream API on that user's scope. Please adapt your application to handle with that situation. Revoke the user's session, so when he comes back to your application, he/she can be redirected to Twitter again to start a new OAuth access token process. Or send him/her an e-mail to kindly ask to reconnect. Vimeo/Windows/... are some of the people handling expired tokens with e-mails.
Have fun!
My God's answer is correct but I will share my answer from another question explaining how it could be your computer's clock:
If your OAuth flow was working one day and failing the next, check your computer's clock. I was running a Vagrant box that somehow had its time set to the day before, which caused the Twitter API to return {"code":89,"message":"Invalid or expired token."}. This may also appear as 401 timestamp out of bounds. You can use this command to update your clock in Ubuntu:
sudo ntpdate time.nist.gov
Alternative method if ntpdate isn't available on your system:
sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
if your Access Token=738629462149844993-FcWHjfcucCLGEosyGGQ38qI******iC then don't forget to mention hyphen (-) followed by your USERID.
May be this will be helpful for you.I faced the same problem.
Please find the below piece of code snippet
$code = $tmhOAuth->user_request(array(
'method' => 'POST',
'url' => $tmhOAuth->url('oauth/access_token', ''),
'params' => array(
'oauth_verifier' => trim($params['oauth_verifier']),
)
));
if ($code == 200) {
$oauth_creds = $tmhOAuth->extract_params($tmhOAuth->response['response']);
// echo '<pre>';print_r($oauth_creds);exit;
$tmhOAuth->reconfigure(array_merge($tmhOAuth->config, array(
'token' => $oauth_creds['oauth_token'],
'secret' => $oauth_creds['oauth_token_secret'],
)));
$code = $tmhOAuth->user_request(array(
'url' => $tmhOAuth->url('1.1/account/verify_credentials')
));
}
The error invalid or expired token can be linked with the fact that one is not paying.
Without paying one will only be able to create the dev environment (sandbox).
As I have answered here:
Counts is only available to paid premium accounts, and one needs to pay for premium access.
Use this link to Apply for access.
Try to regenerate the keys again and save them properly.
For me, it happened because after regenerating one of the keys I did not update other keys. Therefore removed and regenerated all 4 keys again (CONSUMER_KEY, CONSUMER_SECRET, ACCESS_KEY, ACCESS_SECRET). And tried to execute it again and it worked this time.
I'm using Python/Twisted to do asynchronous HTTP calls to the Google+ API. Our client app passes over the user's access_token and we do an API call to...
https://www.googleapis.com/plus/v1/people/me/?%s&key=%s&
... where %s and %s are being filled with a valid access_token and (supposedly) valid Simple API Key, respectively.
Everything was working beautifully yesterday. Today I continued to work on the unit tests for this when the API suddenly started returning:
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "keyInvalid",
"message": "Bad Request"
}
],
"code": 400,
"message": "Bad Request"
}
}
usageLimits, keyInvalid... Okay, I get it. I've seemingly hit the usage limits and they have invalidated API keys coming from this account. Except, I haven't...
The "Courtesy Limit" is supposed to be "10,000 requests/day", yet I've only made a couple hundred calls (according to Google's own usage graphs), and I am still seeing "0% used" on the quotas tab.
I would have brought this to Google directly, but they seem to have dropped their Developers Google Group in favor of a Google+ discussion that doesn't actually receive any responses.
Any help or guidance is extremely appreciated. Thanks!
The answer was quite simple! You can't send both the access_token and the key in the same API call. If you use the access_token you're authenticating the API call as the user, if you use your projects Simple API Key you're authenticating as yourself. If you use both, the call fails.
Just so we are clear, you are using your key from your Google API Console page? On there you should see a tab for "API Access" near the top left hand corner of the page. Make sure that the API Key you are using is your Key for browser apps (with referers) Key, otherwise it won't work.
At any rate, an API Call for me looks like this:
https://www.googleapis.com/plus/v1/people/114789529333378876576?key=ENTER_YOUR_KEY_HERE
You should be able to make at least one API Call per day without a valid Key.
This took me quite a long time to figure out, so hope to save some time to someone else :)
Take a look at thi spost, by google staff (in 2012..) https://groups.google.com/forum/#!topic/google-ajax-search-api/HuKhXfsoMQc
Sorry for the delayed response. This error (which we're working on improving the descriptiveness of) also occurs when you have a
restriction on your key (e.g. locked to a specific referer or IP
address). Please confirm that if you've set such a restriction in the
APIs Console, that the referer or IP address that you're making the
requests from. Pay special attention to any wildcards used on the
referer - for instance, if you use *.abc.com, it won't work if your
request comes from "yoururl".
also would have been great if google team fixed this issue! :)
In my case - I just had to wait few minutes because it was short time after updating my API KEY. Whenever you create a new key or update it on YT developer console. YT has up to 15 mins to make all the changes on their side
In my case I had a parameter named Key, so it thought that was an actual key, just renamed the parameter.
I have done a lot of research and I can't work out if this is the best way to achieve what I need.
I have a generic web app and I want to create a generic mobile app to go with it. In order for users to save data/access user specific data/etc they have to log in and the login has to be authenticated over my web app's REST api.
So the api has a private and a public key for the mobile app. The public key tells me where the request is coming from (the mobile app) and the private key is used as a "salt" to hash the query string which can then be rehashed on the web server when the request comes in and compared for validity.
To log in the user enters their username and password which is then sent as query string vars as per the method above. The query is checked for validity at the other end and the username+password pair is checked against the database. If the login is correct a random "auth token" is generated for that user and the public key and sent back to the mobile app for storage locally on the device.
When the next request comes in from the mobile app one of the query string variables is the "auth token" from earlier which is checked for validity (with the app's public key) against the "auth tokens" table in the database. If it is valid then do the request.
My question here is, have I got this right? Is this the best way to achieve what I need? The last step seems really insecure as both the public key and the auth token will be visible if the request is intercepted. Obviously the request will be checked against the hash of the query string and the private key at the other end and this will make sure the request isn't coming from anywhere malicious.
Are there any other steps, or things I've missed which would be useful? For instance I was reading that there should also be a timestamp variable which should be checked against a 5/10min time frame in the request. Any timestamps older than 5/10 mins and the request should be rejected. Is this important?
Thank you.
What you are describing is basically a homebrew version of 2-legged OAuth. There are many implementations out there that you can basically use. Whenever it comes to security related stuff, I go by: If others have already done it, don't reinvent the wheel. OAuath is used by many big sites out there (Twitter, Facebook, GitHub, Google, ...) and they have done a lot of research that went into the OAuth standards. So I'd suggest to use those.
If you are concerned that messages you send may be intercepted, you should use HTTPS... Which is a good idea in general, if you are passing around username and password combinations over the wire.
I’ve a Flickr which I’m using to upload pictures from my phone and all images are public. On my blog I want to retrieve all the images to show and for that I’ve first tried to create an application to get my API key. I’m using the Flickr API flickr.people.getPublicPhotos. This API service is said to not require authentication and putting it all together I end up with this call:
http://api.flickr.com/services/rest/?method=flickr.people.getPublicPhotos&api_key=fc94274cd0335f3c171fe22c8490b7d9&user_id=5545356%40N04&extras=description%2Cdate_upload%2Cdate_taken%2Cowner_name%2Coriginal_format%2Ctags%2C+o_dims%2C+views%2C+media%2C+path_alias%2C+url_sq%2C+url_t%2C+url_s%2C+url_q%2C+url_m%2C+url_n%2C+url_z%2C+url_c%2C+url_l%2C+url_o&per_page=40&format=php_serial&api_sig=0c48e2b6b6d9a03521e5ca86a15cf471
The problem is that every around 10 hours I fails and returns the error message a:3:{s:4:"stat";s:4:"fail";s:4:"code";i:100;s:7:"message";s:31:"Invalid API Key (Key not found)";}
I tried to create the API call when logged in to Flickr and also with not logging in and in both cases I get the error message. It’s like the API key expires or stops working. Have a missed something on Flickr about the API key or what could cause this? It is really frustrating to renew the URL twice at day.
Thank you
Sincere
- Mestika
If I read the docs correctly, the &api_sig query string parameter is constructed using an authentication token, one that eventually expires. Remove that parameter (= do not sign your API request) and I think you'll be OK.
Mestika's comment seems correct. I was getting the same problem when using the API explorer. If you use your accounts API, or go in and create a new app, then use the API given for that, then the key doesn't change every few hours.
The url to request a key is:
http://www.flickr.com/services/apps/create/apply
I got the same problem.
This is how i solved it:
removed the auth_token and the api_sig parameters
replaced the api_key value with an app key
Hope this helps.
i met this issue before. with new api key, only accept https request.
Let's change your url to: https://api.flickr.com/services/rest/?method=flickr.people.getPublicPhotos&api_key.....
I am sure it will be work right know.
thanks