I am using the google-api-php-client client to connect to Google Drive using a Service Account. Most of the time it works, but every so often (say if I sit here an refresh the page over and over it's every 5th to 10th time), I receive a Google_Service_Exception with the message unauthorized_client: Client is unauthorized to retrieve access tokens using this method. The error only occurs if the $this->drive_service->files->listFiles() code is present. It does not occur if I use the Service Account directly rather than using setSubject() to impersonate another user.
$this->client = new Google_Client();
$this->client->useApplicationDefaultCredentials();
$this->client->addScope("https://www.googleapis.com/auth/drive");
$this->client->setSubject('xxxx');
$this->drive_service = new Google_Service_Drive($this->client);
$files = $this->drive_service->files->listFiles();
Any thoughts?
Update Feb 21, 2017: The error is no longer intermittent, it happens every time, so I can no longer connect at all to a regular account through a service account.
Update March 10, 2017: It seems as though this is a user misunderstanding. The service account must be given "domain-wide authority" in order to impersonate users of that domain - something I have not done. I had simply authorized a client to access the users account as described here.
I don't know why your error happens periodically but my understanding is that to impersonate an user, you must grant the service account access.
I've seen this error intermittently when the account that's being impersonated is newly created. By the looks of it, adding a 10 second delay before trying to create the service eliminates the problem.
Related
I'm trying to get some data from a user (searchconsole):
the user first grants permission on a website.
Then, the idea is to use that permission and retrieve the data with a python program that'll run on a different server.
What is the easiest/safest way to achieve that?
Should I use the same token for both servers?
or is there a solution using the service account impersonation? (I'm stuck on that one)
use the permission on the web server to add the service account as a searchconsole user?
I tried to move the token from one server to another manually, and it works, but it seems suboptimal to use the same token for both servers.
I also read the doc and all examples I could find, but didn't find my case even though it seems basic.
Should I use the same token for both servers?
Im not 100% sure what you mean by token, you can and probably should just store the refresh token from the user and then you can access their data when ever you need to. This is really how Oauth2 is supposed to work and maybe you could find a way of storing it in a database that both your fount end and backend can access.
or is there a solution using the service account impersonation? (I'm stuck on that one)
Service accounts should really only be used if you the developer control the account you are trying to connect to. or if you are a google workspace admin and want to control the data of everyone on your domain. impersonation can only be configured via google workspace and can only be configured to control users on the same domain. So standard google gmail users would be out.
In the case of the webmaster tools api im not sure by checking the documentation that this api even supports service accounts
use the permission on the web server to add the service account as a searchconsole user?
I did just check my personal web master tools account and it appears that i have at some point in the past added a service account as a user on my account.
For a service account to have access to an account it must be pre authorized. This is done as you can see by adding a user to your account. I cant remember how long ago I tested this from what i remember it did not work as the user needed to accept the authorization and there was no way to do that with a service account.
Using Exchange 2016 on premises, I'm trying to logon to another users mailbox from my admin account using the RDOSession.LogonExchangeMailbox method. The admin account has impersonation access to all other mailboxes so should have rights to do this. After running the logon method the RDOSession object shows ExchangeConnectionMode as olCachedConnectedFull, but the RDOSession.CurrentUser.name shows as UNKNOWN. If I try to access the inbox using GetDefaultFolder I get a MAPI_E_LOGON_FAILED message. Can you suggest what I might be doing wrong, or haven't done to allow this ?
LogonExchangeMailbox always uses the identity of the current user to connect to the mailbox in the RPC mode (no longer supported by Exchange 2016). To open another mailbox, you can call RDOSession.GetSharedMailBox / GetSharedMailBoxEx.
You can also use LogonHostedExchangeMailbox - it takes explicit credentials instead of connecting as the current local user.
I am using this googleapis nodejs client for calendar, and everything works perfect except that if I remove access from google account security settings,
calendar is still connected. Is there any method to check for removed access from google account? How to handle those cases?
When a user runs your application the first time they are presented with a consent form. Which asks them to grant permission for your application to access their Google calendar data. From this point on when ever your application runs the user may have to login again but they will not have to grant your application permission. If you have a refresh token you will be able to use that when ever you like to request a new access token. the access token will be valid for one hour.
Now if you request a new access Token as stated its valid for one hour. This is true even if the user goes to Google Account security for their account and removes the consent for an application access their data.
Your still going to be able to access their data while any access tokens you have currently are valid. If the user tries to use your application again they will have to consent permission. If you try to use the refresh token it will no longer work.
Access tokens work for one hour they are not reauthorized during that time its assumed that they are valid. (This may in fact depend upon the scope and API in question and how googles policy server works.)
access token are designed to be self contained permission systems. As long as you have an access token for the correct scope most apis assume that you have access. However in the event this method is accessing critical data then they may have a policy server setup. This server could be doing an extra check on an access token to ensure that the user still has access even though they have a valid access token. However doing this can be very time consuming and resource heavy as reevaluating every call to ensure that the user still has access. It kind of defeats the purpose of having access tokens that are valid for an hour in the first place.
I received this error when trying to authorize my app with my own account:
Your project is trying to access scopes that need to go through the verification process.
{invalid=https://www.googleapis.com/auth/contacts}
If you need to use one of these scopes, submit a verification request. Learn More
When I use a different account, the error message is different:
This app hasn’t been verified to access:
{invalid=https://www.googleapis.com/auth/contacts}
Are you the developer? If this project needs these scopes, sign in to an account with access to edit your project and try again.
If not, contact the developer for help.
As per the announcement on May 11, 2017, publicly available applications with access to certain user data must pass review. If you see an access error for your app, submit a request using our OAuth Developer Verification form.
For personal-use apps and those you are testing, join the Google group Risky Access Permissions By Unreviewed Apps, which allows you to approve data access for personal and testing accounts. See the Google API Services User Data Policy for more information.
UPDATE: Corrected broken link to form.
I have two applications which access my users' calendars via a service account. Until today everything was working fine and out of a sudden one of the app cannot get a grant token. I read that this may be due to the same service account being used simultaneously (which was the case for a year but never mind) so I decided to
create a second service account
and authorize it to access the calendars
I created the service account in the Google Developers Console -> API Manager -> Credentials.
The console now looks like this:
Service account client 1 is the original service account which was working for both apps and now works for one of them only. The ga... account is the newly created one.
In order to get the ClientID I went (on the same page) to "Manage service accounts" and I get this:
The newly created account does not offer the possibility to check its ClientID. Why?
The ClientID is also available in the JSON file downloaded upon creation. I extracted it from there and tried to authorize the access in my GApps Security console:
As you can see it was refused.
What part did I miss when creating this second account?
Found it:
and after checking the checkbox below both accounts look the same, the ClientID is available and it can be authorized in the GApps console.