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.
Related
For a while now I've been using dropbopx-sdk-js in a Meteor application without any trouble.
My Meteor app simply uses Dropbox to fetch images to be used in product cards. These files are synced now and then and that's it. By synced what I mean is they are scanned, shared links created or obtained, and some info is then saved in Mongo (name, extension, path, public link)
End users do not remove nor add files, nor are the files related to an end user specific account.
To achieve this, I created (in the far past) an App in the Dropbox App Console, generated a permanent token, and used that token in my Meteor app to handle all the syncing.
Now I've tried to replicate that very same thing in a new similar project, but found that the permanent tokens have been recently deprecated and are no longer an option.
Now, checking Dropbox's Authentication Types it seems to me like "App Authentication"
"This type only uses the app's own app key and secret, and doesn't
identify a specific user or team".
is what I'm after. I can safely provide app key and secret in the server exclusively, as the client will never need those. The question is how do I achieve such kind of authentication? Or for that matter, how do I achieve an equivalent of the long-lived token for my app, ultimately meaning that end users don't actually need to know Dropbox is behind the scenes in any way (and they surely don't need dropbox accounts to use this app nor should be prompted with any Dropbox authentication page)
In the js-sdk examples repo, I only found this example using app key and secret. Yet afterwards it goes through the oauth process in the browser anyways. If I don't do the oauth part, I get an error
"error": {
"name": "DropboxResponseError",
"status": 409,
"headers": {},
"error": {
"error_summary": "path/unsupported_content_type/...",
"error": {
".tag": "path",
"path": {
".tag": "unsupported_content_type"
}
}
}
}
as a result of calling
dbx.filesListFolders({ path: '', recursive: true }):
If I replace the initialization of the dbx object with a generated token everything works out. However eventually the token expires and I'm back in square one.
Any ideas what may I be missing?
The short answer is:
You need to obtain a refresh-token. You can then use this token for as long as you want. But in order to get it is necessary to go through at least one oauth flow in the browser. Then capturing the generated refresh-token in the backend. Then store it and use it to initialize the API. So it's kind of "hacky" (IMO).
For example, you can use the mentioned example code, and log/store the obtained refresh token in this line (as per Greg's accepted answer in the forum). Then use that value as a constant to immediately call the setRefreshToken method (as done in that very same line) upon initialization.
The long answer is:
ClientId + Client secret are not enough to programmatically generate a refresh token.
Going through the oauth flow at least once is mandatory to obtain a refresh token
If you want to hide such flow from your clients, you'll need to do what the short answer says.
The intended flow of usage according to Dropbox is: each user access his own files. Having several users accessing a single folder is not officially supported.
The longer answer is:
Check out the conversation we had in the dropbox forum
I suggested to replace the "Generate Access Token" button in the console for a "Generate Refresh Token" button instead. At least it made sense to me according to what we discussed. Maybe if it gets some likes... ;).
We keep playing this cat and mouse game with Robinhood.com. I have a trading app which used to trade stocks with Robinhood, but they keep changing the unsupported unofficial API to make it difficult for traders to use. I know that many people are doing the same thing and I want to reach out to them to see if there is a new answer. The latest problem is when I try to get a Bearer token using the URL https://api.robinhood.com/oauth2/token/ the API returns the following JSON: {"detail":"This version of Robinhood is no longer supported. Please update your app or use Robinhood for Web to log in to your account."}. This started happening on 4/26/2019.
Has anyone found a work around for this, yet, or have they finally beaten us into submission?
A more complete solution (not need browser):
Use requests.session.
Obtain the login page by making a GET request to "https://robinhood.com/login".
At this point the session's cookies will contain 'device_id'.
Obtain this device_id and use it in making the oauth2 token request to "https://api.robinhood.com/oauth2/token/" also add in the data request "challenge_type" (either "sms" or "email").
This request will fail with a 400 error code. Robinhood will send an SMS message or Email with a temporary (5 minute) code.
Also at this point use the 400 response's body to get "id" from "challenge" inside of the JSON object.
Confirm the challenge by making a POST request to "https://api.robinhood.com/challenge/CHALLENGEID/respond/" where CHALLENGEID is the same id mentioned in the first failed /oauth2/token/ POST request.
Make the same POST request to "https://api.robinhood.com/oauth2/token/" and include in the header "X-ROBINHOOD-CHALLENGE-RESPONSE-ID" with the value CHALLENGEID.
You can reuse a device_id with user/pass after this even after logging out.
Be cautious with storing device_id as it is the result of user/pass login and successful SMS/email 2FA.
Just got it working. At the risk of them seeing this post and changing it more, here we go:
First, you're going to want to log into your RH account in a web browser
View Source on the page, and look for clientId - it should be a big hex number separated by dashes
Add that number to your POST requests to /oauth2/token under the field device_token
There's probably another way to retrieve the device token, and I'm not even sure it's unique, but that way should work.
Good to be back here after a very long time.
Not sure if anyone is still looking for answers to this, but I have a very simple solution.
At Robinhood's login screen, enter your username/email and your password, press F12 on your keyboard to bring up the console panel and switch to the "Network" tab then wait for the page to load completely. (During this time you will see a list of items being loaded rapidly depending on the connection speed.)
At this time you can keep clearing the list by clicking on the button highlighted in the below image.
Click on button highlighted repeatedly until the list is empty
Now, log into your Robinhood account. At this point your console should display a list similar to the one shown below.
Look for the name "token/", most likely it will be the second one you get all the information you need. And this information will be under the Headers then Request Payload
I was able to find this with past knowledge and experience of web scraping for fun. And also, I needed to know this as well, since I recently started doing trades via Robinhood.
Hope this help you curious ones out there.
For my Robinhood account I am using Google Authenticator for my 2FA. What I have so far is that I send the original call that I was sending before to https://api.robinhood.com/oauth2/token/. This is giving me a response of:
{"mfa_required":true,"mfa_type":"app"}
I then repeat my oauth token request, but this time providing the value from Google Authenticator (so my GUI has to prompt me to fill it in) with this payload in the request to https://api.robinhood.com/oauth2/token/:
{"grant_type":"password","scope":"internal","client_id":"c82SH0WZOsabOXGP2sxqcj34FxkvfnWRZBKlBjFS","expires_in":86400,"device_token":"***","username":"***","password":"****","mfa_code":"***"}
and then I am getting an access token in reply
So this type of error is being reported on a lot of community boards over the course of the last year with no acceptable answer we could find. We have just started our journey integrating with Google Home and created a Home Automation Action and we are getting a similar error …
{
insertId: "10wvnj2fyb1thy"
logName: "projects/bitdog-home-f69bd/logs/actions.googleapis.com%2Factions"
Show matching entries
Hide matching entries
Add field to summary line
receiveTimestamp: "2018-12-06T13:28:13.939975519Z"
resource: {
labels: {
action_id: "SMART_HOME_SYNC"
project_id: "bitdog-home-f69bd"
version_id: ""
}
type: "assistant_action"
}
severity: "ERROR"
textPayload: "SYNC: Request ID 742344561631232315 failed with code: OPEN_AUTH_FAILURE"
timestamp: "2018-12-06T13:28:13.931998358Z"
}
This shows on Google Home app as "Couldn't update the setting, check your connection"
The OAuth service logs show a successful account linking and a successful refresh_token request. Google does not attempt a SYNC call to the Action handler from what we can tell.
We have other systems using the OAuth server and they are working well and we are little lost on how to proceed to debug this issue. We created a support ticket today but I don't feel confident that we will get meaningful help.
We have also tried using the Google Home app on Android and iOS. We have tried changing the default browser from Chrome to Firefox. Nothing has changed the outcome. We also made sure that our access_token was in JWT format to see if google was sensitive to token size or format and nothing worked. We even made sure that the Google Home app user matched the user logged into the browser.
Help!
I did get it working. It was already working with an Amazon Echo Skill but it seems that Google's implementation (OpenAuth) is a bit more strict. I changed my access_token from a proprietary encrypted token format to a legit signed JWT token. I also removed expires_in from the response and it started working, not sure if it was the access_token JWT token format or removal of expires_in. I'm happy I can move on. If I get a chance, I will test to see which change made it work and comment here again.
Thank you.
To anyone with this problem–
I had to take multiple steps to resolve this issue, which are not clearly outlined in any documentation.
As per Google support:
Please adjust your account linking implementation from implicit to auth code flow then perform test again.
On the documentation for OAuth account linking, it says there are two methods of authentication: implicit and auth code. Apparently, only the auth code flow works for smart home.
I am using the Actions on Google Node.js library. While poking through the documentation, I found that:
[The SYNC request fulfillment] should return a valid response or a Promise that resolves to valid response.
The problem is that I was doing a database operation (which took time), so I couldn't simply return a value when it was ready; I had to return a Promise insead, then fulfill that promise later.
Hopefully this is helpful to anyone stuck on this reoccurring issue! Basically, check your auth flow and make SYNC is returning a valid JS object on time.
I was facing the same issue from last 2 weeks and was wonder when saw it is a 3 steps problem.
Check your SYNC intent is properly parsed
Incorrect Response Structure (Verify here-Smart Home SYNC Data Validator)
Device Response time-out should be less than 5 sec.
You can check Link
My problem started when I connected by Sonoff Bridge.
So I got it working by removing my 'Sonoff Bridge' and connecting it to Google Home. (All mu light are now working). Added the Bridge again to Sonoff and using IFTTT to connect to my Bridge
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
There is currently no easy way to check if an auto-submit URL has been flattred by the authenticated user.
The current way is to
get the thing, which is 1 request
then get the list of all flattred things of the authenticated user, which is another request and a potentially really big response
then iterate over the list and match the thing, which is a performance bottle neck
All this makes it unusable for a mobile client like an iOS device. There needs to be a new call. My proposal is:
GET https://api.flattr.com/rest/v2/flattred?url=auto-submit-url
Response:
{
"message": "found",
"description": "The url has been flattred.",
"location": "https://api.flattr.com/rest/v2/things/:id"
}
We had mistakenly not documented the "flattred" parameter on a thing - it should tell you whether the thing is flattred by the authenticated users.
So do a /lookup on the auto-submit URL and check the "flattred" parameter on the thing it gives you.
We've added it to the documentation now: http://developers.flattr.net/api/resources/things/#get-a-thing