I am creating an application in which I am getting a Client_secret.json file, and in my application I'm trying to load that json file and get the credentials from it using the following code:
credentials=get_credentials(filename)
http = credentials.authorize(httplib2.Http())
service = discovery.build('admin', 'directory_v1', http=http)
userinfo = {'primaryEmail': primaryEmail,
'name': { 'givenName':user },
'password': password
}
service.users().insert(body = userinfo).execute()
It gives the following error:
httpError 403 when requesting https
//www.googleapis.com/admin/directory/v1/users?alt=json returned
insufficient permission
I'm not sure what I'm doing wrong or am I missing something? I was wondering if the problem is in the json file which I'm creating?
Any help would be appreciated.
Thanks,
Aman
Well, you can start by checking a few things:
If you're using a service account, be sure to enable the "wide domain delegation option" to allow a service account to access user data on behalf of your users and perform operations.
Check if the scope https //www.googleapis.com/admin/directory/v1/users is authorized for your client ID on your google admin console > Security > Advanced settings > Authentication > Manage API client access.
Check if the user that you're using to insert the new user have enough privileges a.k.a super admin privileges.
Check if the Admin SDK API is active on your project.
Keep in mind that just downloading the client_json and activating a API isn't enough to allow these types of operations. For certain APIs like Admin SDK, the user you're gonna use to consume those services need to have specific privileges.
Here's a few helpful links
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority
https://support.google.com/a/answer/162106?hl=en
I would first check to make sure that you have the correct Admin privileges on the account that you are trying to use OAuth credentials on. I would try logging into the account and going to this reference page in the Directory API for Users:insert
https://developers.google.com/admin-sdk/directory/v1/reference/users/insert
On the right hand side you should go to the Try this API section and see if that account has permissions to create new users.
Also another thing I noticed as well, is that you're not setting the required field familyName inside of the name field. familyName is a required property.
Related
I was able to create a project to connect an app to google data, for a specific account (followed Google People API)
But now I would like that each customer log in hisself to his account and manage his data.
I can' t create project in the Google API Console for each customer, my app needs to read auth from each user who will use my app and "auto" create auth to read google contact data of the logged user.
Is possible?
Could you suggest me articles about how to do?
It sounds like you are trying to do exactly what OAuth 2.0 (see the page you linked to) gives you: authenticating users. This differs from using an API key, which is only authorizing your project and has nothing to do with a user's credentials.
OAuth 2.0 combines a Client ID (associated with your Google Developers Console project) and a user's login (specific to the user who is accessing your app/site) to give you an authorization token. This token will let your app act on behalf of that user when calling that API. Just make sure to request the necessary scopes as part of the OAuth 2.0 authorization prompt given to the user.
How to give this prompt varies by environment, but many common options are listed on that link.
Note that you always use the same Client ID, so you only need one Google Developers Console project, but you are given a unique token specific to that user's login when they authorize your app, so this lets you act as any user which grants your app access to their account.
I'm working on a project that consumes Service Now API (Rest). To do so our client has registered us as a user in order to login and make all service calls we need to. This project has an interface where users can login once they have an account on Service Now as well, the username they type to log in has nothing to do with service now by the way, but later they associate theirs service now users to it. They can do some operations through this interface, where all of them are done using the integration user/pass not their service now users theirselves, even because they do not need to share their passwords with us. But it's needed to track the correct user to register on service now and I'm in trouble specifically about commenting on an incident. The endpoint to comment is the following :
http://hostname/api/now/table/incident/{sys_id}
where request body is a json object just as simple as :
{
"comments": "My comment is foo bar"
}
but when this comment is registered on Service Now it is under integration user instead the user which commented. Is there any way I could keep a specific user, considering I already have the user id on Service Now ready to inform it on the request the way it should be.
I tried reading Service Now documentation but had no clue how to solve it, altought I've found something about impersonate
This is happening because you're being proxied through the "Integration User" instead of your own account. As long as this is the case, your comments are going to be attributed to the Integration User.
I can think of two ways to fix this issue.
Ask the client to log you into their system directly as a user.
Implement a special API (Scripted REST API, available in Geneva or later) that allows you to identify the Incident and enter the comment, and then the script forges the comment on your behalf, attributing authorship correctly.
The first solution can be expensive due to possible additional licensing costs.
The second solution will require a willing client to devote 2-3 hours of development time, depending on the programmer.
Firstly, you need an integration user with suffient rights. Our integration user has suffient rights out of the box, but your story could be different. A quick check is to try impersonate as other user using menu.
Login as integration user to ServiceNow instance.
Go to https://{instance}.service-now.com/nav_to.do
Click on username at top right corner. This is a drop down.
There should be at least three menu items: "Profile", "Impersonate User", and "Logout". If you do not have "Impersonate User" in this menu, your integration user miss some permissions. Contact system administrator if you miss this menu item to configure appropriate permissions.
Then you need to find sys_id of user that you want to impersonate. For example:
https://{instance}.service-now.com/api/now/table/sys_user?sysparm_query=user_name={username}&sysparm_fields=sys_id
If you have suffient privileges, you could invoke the folling endpoint with sys id of user that you want to impersonate:
HTTP POST to https://{instance}.service-now.com/api/now/ui/impersonate/{user_sys_id} with body "{}" and content type "application/json". You need to provide HTTP basic authentication to this query as your integration user.
The response code on success is 200. The response body could be ignored. The interesting result of this response is a set of cookies for impersonated user in response headers. These cookies could be used for subsequent REST API calls until they expire. Use some HTTP rest client dependent method to capture them and to provide them to next calls.
For Apache HTTP Client (Java), I'm creating http client context using:
HttpClientContext context = HttpClientContext.create();
context.setCookieStore(new BasicCookieStore());
Pass thing context to impersonation request and to subsequent API calls until I get 401 reply, after that I'm reaquiring cookies. Setting new cookie store is important, as otherwise some default cookies store is used.
Two things to note:
This API looks like internal one, so it could change at any time. If it happens, look for what "Impresonate User" menu item does, and repeat it youselves.
ServiceNow permissions are quite fine-grained, so the target user could lack permissions to perform operation. In some cases, if there is no permission to update the field the operation PATCH on object returns reponse 200, but field is not updated. This introduces a surprising mode of failure when you use impersonation.
I was trying to make Box Enterprise API work using As-User. I have a admin account which i used to try to retrieve the Contents in a sub account.
I first used the admin account to retrieve the User ID of the sub account. And added the User ID as a field "As-User: ########". However, I was returned with a reply of 403.
The error message : "The request requires higher privileges than provided by the access token."
I am using the access token i had used to retrieve the user list. Do I have to get a new access token using the as the new user? or is the admin access token fine?
GET /2.0/folders/0/items HTTP/1.1\r
Host: api.box.com\r
Authorization: Bearer #######################\r
As-User: ########\r
Connection: close\r
\r
The access code is the same access code used to retrieve the user list /user
All the scopes has been checked
Your application must be manually approved by Box for As-User requests. The documentation mentions this but it's easy to miss. To start the approval process send Box a note and include your API Key.
I am unable to add a comment on this, so I would like to add (in case the support staff doesn't give you a head's up) you may have to do this after they enable the As-User header --
Go back to your - Admin Console->Business Settings->Apps
Find the Custom Applications section
Authorize or reauthorize the app you are working with
I had the same problem and found this:
https://support.box.com/hc/ja/community/posts/360049157874-Insufficent-scope-when-trying-to-make-a-call-using-As-User-header
So you should use the scope admin_on_behalf_of.
I was trying to run the sample script of Google Apps Script here:
https://github.com/googlesamples/apps-script-oauth2/blob/master/samples/GoogleServiceAccount.gs
I believe I set PRIVATE_KEY, CLIENT_EMAIL and USER_EMAIL correctly from JSON file downloaded from Google Developer Console. Also I enabled Google Drive API on the project. But still I get an error in the dialog "Error: invalid_client\n no application name".
Is there any code I should add / change to run this sample script correctly?
In case you are using the correct settings (PRIVATE_KEY,CLIENT_EMAIL and a valid USER_EMAIL), the error could also be related to the permission granted to the application from the domain admin.
Since this example uses domain wide delegation of authority to impersonate the account from the USER_EMAIL, first the domain admin has to grant permissions to the application to perform this kind of operations.
To grant this permissions to the app you can do it by going to: your Admin Console -> Security -> Advanced Settings -> Manage API client access
There you will add the service account CLIENT_ID in the field "Client Name" and in the second field you will add your project scopes separated by commas. These scope should match the scopes that the application uses. In this case id Drive scope and any other you may be using.
Click the button "Authorize" and if everything goes well, then you will be able to impersonate users in your domain with that project.
Here is the related documentation. I hope this helps.
We used to have an application connector implementing the Document List Service v3 to upload documents to users account. Now that the service will be discontinued starting as of next Monday and we need to migrate to the Drive API/SDK we have the problem to migrate our current login schema .. we are unable to use the OAuth 2 protocol and we need to authenticate users with their username/password credentials.
DocumentsService myService = new DocumentsService("xxx");
myService.setUserCredentials(username, password);
The reason is that our application scans and processes documents asynchronously from MFD devices (printers) and all processing/storage job is done in a different moment on processing servers, thus the limitation that the processing service cannot ask any consens to the user.
We do the same for other online cloud storage application (e.g. Dropbox) where they allow special 'OAuth 1' schema on request for such 'enterprise' situations.
How can we do this with the new Drive API/SDK? I couldn't find anything about that in the documentation rather than the service account, also looks like not suitable.
What you need to do is request authentication from you user once. The server gives you back a refresh token. Your automated application can then use this refresh token to get a new access token. You only need to ask the user one time for authentication. Then everything can run automated.
A service account wont really work in this instance because its meant for use with an account that you the developer own not a users account