I am asking this on stackoverflow because as best I can tell that's the only place Google is providing support for this API, though this really seems to be something that'd require examining my google project to determine the issue.
Anyway, I have repeatedly followed the nest device access quick start guide to the letter, from start to finish with a fresh project, verifying every step reaches the described state. At the end of completing the guide, I can see my project in the Partner Connections list. The SDM API is enabled for the project when I look at the Smart Device Management API page in the developer console, for the correct project.
Manually going through the oauth2 flow, as described in that guide, results in an access token.
However, when I issue a device list call like this (as described in the quick start guide I linked to)
curl -X GET 'https://smartdevicemanagement.googleapis.com/v1/enterprises/<redacted project id>/devices' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <redacted access token>'
the call returns with a 200, but the entire contents of the response are as follows:
{}
When I look at the Partner Connections page, I can see that I have definitely granted access to the devices I want the project to be able to access. See
this screenshot of the partner connections page indicating that I have allowed access to the device I want the API to be able to see.
All authorized callback URLs for oauth2 are https.
I have spent multiple evenings bashing my head against this at this point. What am I doing wrong here?
After my thermostat stopped being listed by the API, I temporarily switched its location to something different, and then I switched it back. For some reason it helped.
You can find it in Nest webservice: Settings -> About -> Where
I hope it will work for you, too.
Tried the location change and several other workarounds suggested everywhere. When I queried the API, I would get only 1 device. I reset the device that wasn't showing up to factory defaults and re-setup everything from scratch. That did the trick. A simple integration reload on Home Assistant had the unavailable device back up and running.
Related
We are using People API to fetch details from Directory . The API is not returning the name for most of the people in the directory. 2 accounts in our GSuite account alone provide the name field, while the others don't. However, other details like emailAddresses and phoneNumbers are available for everyone.
We didn't find any finer grained control for individual fields when using the setting External Directory Sharing → Domain and public data
We tried to change the setting from default to External Directory Sharing → Public data and authenticated user basic profile fields. However, this results in API response showing PERMISSION_DENIED error.
For one of the users in directory, we created Google Currents account. When the account was created and active, the name field became available for this user. After the account was deleted/deactivated, the name field was no longer available.
People API being used:
GET https://people.googleapis.com/v1/people:searchDirectoryPeople?query=a&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_CONTACT&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE&readMask=emailAddresses,names,phoneNumbers,photos
The docs we have referred to so far are as follows:
People API - Search Directory:
https://developers.google.com/people/api/rest/v1/people/searchDirectoryPeople
Let third-party apps access Directory data:
https://support.google.com/a/answer/6343701
A merged view of people information:
https://developers.google.com/people/#a_merged_view_of_people_information
Edit:
cURL command:
curl --location --request GET 'https://people.googleapis.com/v1/people:searchDirectoryPeople?query=s&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_CONTACT&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE&readMask=emailAddresses,names,phoneNumbers,photos' \
--header 'Authorization: Bearer <access-token>'
This is a known bug with the People API.
You can find it here in Google's issue tracker: https://issuetracker.google.com/issues/196235775?pli=1. If this bug is impacting you, I highly suggest you leave a comment letting the team know you're currently facing the issue and leave a +1 by clicking the "+1" button on the top right.
In the comment section of this question, it was suggested that this behavior is to be expected and is related to privacy. It's safe to say that's not the case as 1. the issue was accepted as a bug by the Google team, and 2. all other information is successfully returned from the API aside from this field.
Additional information on the resolution
Back in August of 2022, the Google team explained the fix was being held up by a bigger effort:
Hello there - apologize for the delay, we did identify the root cause,
however the fix is blocked on another bigger effort. We recently
started making progress on the blocking issue, and will provide an ETA
as soon as we figure out some of the unknowns for the solution.
However, recently (January 17th, 2023), the bug was assigned to someone at Google. This may suggest that the bigger effort was completed and that the team is now unblocked.
Potential workaround
Hopefully the bug is fixed soon. But in case we're waiting for a while, these workarounds may help.
Email is reliably returned for all directory users. The OP doesn't mention the exact context in which he or she is using the API, but for some applications you might be able to get away with using email (e.g. if you're just trying to identify the Directory user to the end user).
Additionally, if user email addresses in your directory follow a uniform formatting, you should be able to parse those to get the name. This is the workaround I'm currently using. E.g.
john.smith#example.com -> John Smith
jsmith#example.com -> J. Smith
jsmith3#example.com -> J. Smith (if you're at a large organization, you may have to remove some numbers)
Meta Sidenote
Yes, it's valid to post that something is a known bug as an answer. Check out this link if you have questions: https://meta.stackoverflow.com/a/369622/1101602.
I am a beginner trying out api for fun.
The problem is, lets say, I want to write a simple windows program with golang to let my friends read and edit one of the sheets saved on my google drive. How can I do this without having them download a credential file?
What I want it to do is simply redirect them to the Oauth Page right away, and if their email address is one recognized by the app it will grant them access to that google sheet.
What i think you need is to integrate your go app with Oauth protocol.
More specifically, with the Google provider.
This is mainly 3 steps:
add the oauth client to your application
something like this: https://github.com/golang/oauth2
See their docs on how to do it.
go to google dev documentation and see how to integrate google auth flow into the client: https://developers.google.com/identity/protocols/OAuth2
I'm not sure if google has something more specific for google drive integration and/or go-lang client in particular. Please do some searching.
make the glue code on your go app so that the user can interact with this (the login button (or command, if it is terminal based), error messages, logout, etc)
More questions will appear when you start to do this, however it is a great example to learn Oauth as well.
General guidelines:
https all the queries or oauth is basically useless
oatuh has many auth-flows and you must choose which one(s) you support. use whatever google documentation recommends for m2m scenario (machine 2 machine)
log errors so that your friends can send you a log file for you to debug issues
maybe set some feature flag so that you can simply disable this feature to run/test localhost ? maybe useful? you decide.
I created a Google application in the developers console, turned on "YouTube Data API v3", generated the server API key, and authorized my home and work IPs.
My website lists all videos from a Youtube channel, using the V3 API. It uses the official PHP library, passing it the server API key.
It all worked well yesterday from home, and today morning from work. Then, it suddently stoped working at 11am (GMT+1), with no action from my part, with this error:
[Google_Service_Exception] Error calling GET
https://www.googleapis.com/youtube/v3/channels?part=contentDetails&forUsername=xxxxxxxxxx&key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
(403) Access Not Configured. The API is not enabled for your project,
or there is a per-IP or per-Referer restriction configured on your
APIkey and the request does not match these restrictions. Please use
the Google Developers Console to update your configuration.
Note: i used less than 10 requests, out of the 50 millions allowed by day, i have a static public IP address, this part of the code was untouched.
What can i look for in order to fix that, please? I really don't know where to head for from now... Thank you.
Oooook...
Do all you have to with the API activations before you generate any keys!
Unactivating or reactivating API (like "Youtube Data") silently destroys your key validity. At least for the server one.
So the solution is, when you get the same error as me:
destroy your server key (delete it completely, do not only regenerate)
deactivate then reactivate all APIs you need
create a new server key
thank Google for the so clear error messages (optional)
Additionnaly when I opened the requested URL in browser I found that the API call returned
{"domain": "usageLimits"}
I tried the above solutions without success.
Creating a new project from scratch solved the issue
Thanks #Danra, you helped, but I add this answer because your comment is default hidden.
This solved for me....
i first followed #Ninj answer...still no change.
Then, After adding my domain urls to 'allowed referers' list,
i regenerated the key alone
it then worked like a charm !
i guess google parses allowed urls from the key string itself, not from updated settings
I got frustrated and created a new project with a new key and it worked like a charm.
Solution 1:
Create new project and enable Youtube Data v3 api and create credential.
Solution 2:
Check limit Quota in Youtube Data v3 -> Quota (in left pane) &
Increase the limits per day or request for Higher Quota
I also tried everything, but could only solve this when I created a new project, gave access to the APIs I needed, and added a new key.
I also got a "Bad Request" error and this solved it.
I also tried everything, but could only solve this when I created a new project, gave access to the APIs I needed, and added a new key.
I am trying to use the Admin SDK Directory api to look up user profiles. I am able to do this successfully all day (with in quota) with 99% of the time. Though there are certain times where it just fails no matter what.
Yes I have set the service account user, I have the proper scopes, I have admin api turned on.
It even fails in the google api explorer. See screen shots
The call:
https://www.dropbox.com/s/9v9m6s5zf76oix7/call.png?dl=0
The response:
https://www.dropbox.com/s/te6k3x5xjkr467j/response.png?dl=0
Sorry for the links, images keep showing as broken
After contacting google they supplied an answer. There is a setting for the contacts app that enables and disables this.
Admin console >> Google Apps >> Settings for Contacts >> Advanced settings
Contact sharing: Enable contact sharing
Make sure that is enabled and it works.
Here is a screen shot: https://www.dropbox.com/s/8jmzz7zw0xq4ux4/answer.png?dl=0
Honestly, it just seems like some sort of transient error on the Google side. Being that it's working ~99% of the time for you, means you're not doing anything wrong. I would consider this more true b/c you're also using a Google Tool rather than your own so you know it's not the code. When it's failing for you, does it also then fail with the API explorer? What about with the OAuth Playground?
If this is reproducible consistently (same times, after X amount of requests, etc.), it would be worth reporting the the Google for Work Support team (assuming you have the ability to contact support) as it sounds like a bug and they would be able to help with break/fix for API issues.
I'm trying to use the garb gem to access data from the Google analytics API and find that http requests using garb work just fine from a Linode account, but are refused from home (Comcast). Is Google rejecting some kinds of http requests from certain ISPs, or am I just doing something wrong? Simple example is below:
require 'garb'
Garb::Session.login('XXXXXX#gmail.com', 'XXXXXX')
#profile = Garb::Profile.all.first
#report = Garb::Report.new(#profile)
#report.metrics :visits
puts #report.results
This give => [#<OpenStruct visits="21">] on my Linode, but the exact same thing run from my home ISP gives:
Garb::DataRequest::ClientError: "<errorsxmlns=.........
Which is raised here in garb:
def send_request
response = if #session.single_user?
single_user_request
elsif #session.oauth_user?
oauth_user_request
end
raise ClientError, response.body.inspect unless response.kind_of?(Net::HTTPSuccess)
response
end
The initial session login works just fine from both IPs. The error is only thrown when results are requested. Is there anything I can do to fix this? I haven't (yet) verified that I get exactly the same behavior going through clientlogin/data requests by hand. I'm pretty convinced it is not a gem issue, but an IP-related one--perhaps something to do with Google web services quota policies--but I'm willing to entertain all possible solutions.
Thanks,
Orion
You've probably made too many calls to google in a short space of time. I haven't seen it happen with Garb, but I've seen it happen when using an API to scrape search results pages. Google notices and flags your IP. Try browsing to google.com and running a normal google search from the ip that's blocked, you'll probably be required to enter a captcha. They probably block API calls from that IP at this stage, you'll get cleared eventually after a few days I think.
Jeremy's probably right.
Google Analytics API has multiple quotas you need to worry about. See here their list here. I've hit the 10 queries per second per IP address quota and/or the 10 concurrent requests per profile before. I also saw 4 concurrent requests per IP address somewhere.
You should post the full error message Garb gives you next time, since those have actually helped me figure out what caused it in the past.
Also, these quotas are for projects sending registered API keys along with their requests. If you're not, the quotas are much lower. I hit the quota for an unregistered project before. Registering your project is fairly easy, and you just add the following line
Garb::Session.api_key = 'API_KEY'
to your code (I'm using Sija's fork) before the Garb::Session.login line.
Another thing, once you register your project, go to Quotas page on the API console and click the "Set per-user limits" and up that from the default 1.0 to the max 10.0 requests/second/user. If you click "Request more" they give some tips for optimizing your calls/timing as to not hit the limit.