I'm trying to use the Email Settings API from within a google marketplace app. Because I need all the logic to happen offline (in a cron job). I'm using an app engine Service Account, but when I'm trying to actually change the email settings for the users of the domain that installed it I'm getting this error:
You are not authorized to access this API.
Error 403
this is the scope: https://apps-apis.google.com/a/feeds/emailsettings/2.0/
I'm probably missing something, but I couldn't find the right docs to show me the way. How would I go about implementing an app that accesses the email settings even when the admin is offline?
You need to set the prn attribute to address of an admin account.
Examples for the directory API are at:
https://developers.google.com/admin-sdk/directory/v1/guides/delegation#instantiate_an_admin_sdk_directory_service_object
In terms of accessing the Email Settings API, you're really unlikely to get people to give you Service Account access to their domain.
On the other hand, if it's your domain (and thus you can add Service Account access), couple of pointers below:
What is important is that you add the following to the header:
"Authorization" = "Bearer <your_token>"
(note the very specific syntax - "Bearer+<1 space>+", as per https://www.rfc-editor.org/rfc/rfc6750 section 2.1)
"Content-Type" = "application/atom+xml"
(important for POST/PUT/DELETE requests, doesn't matter for GET)
that should get you up and running.
Related
I have followed the documentation for creating a G Suite Service Account. The following works fine to emulate a given user in my domain:
def create_directory_service(user_email):
credentials = ServiceAccountCredentials.from_json_keyfile_name(
SERVICE_ACCOUNT_FILE_PATH,
scopes = SCOPES)
credentials = credentials.create_delegated(user_email)
return build('admin', 'directory_v1', credentials=credentials)
However, I want to be able to just use the service account to access domain information without needing to emulate a particular user. But if I pass in the service account's email address (as given in its key file), I just get HttpError 503: "Service unavailable. Please try again".
I've added the service account's email address as a Service Account Admin, but it still doesn't work. Again, delegation works fine, but not using the service account directly.
Does anyone know what I'm missing?
To use Directory API, you must use delegation to impersonate a user in the domain, that can use Directory API (so usually an admin).
I'm working with the PayPal API and am trying to create an account as shown here.
The request is made to https://svcs.sandbox.paypal.com/AdaptiveAccounts/CreateAccount.
I'm able to send a valid request and get a response indicating success back but the redirect URL that's also returned as part of the response payload (which according to their docs is supposed to take the user to a PayPal sign up/registration page) is directing them to the following:
I've been unable to find anything on Stackoverflow or Google regarding this. Has anyone encountered this before? I'm assuming that even though it's a sandbox environment it should allow me to simulate the workflow somehow. I've tried with both the default sandbox credentials as well as for my own environment.
Looks like the issue was due to the IP address header in the request. The default configuration is:
-H "X-PAYPAL-DEVICE-IPADDRESS: 192.0.2.0"
While testing on localhost, I changed it to:
-H "X-PAYPAL-DEVICE-IPADDRESS: 127.0.0.1"
Also had to ensure that the email address didn't already have an account registered to it - in which case it would lead to a login page instead of the registration page (which is a little poorly designed in my opinion since you can't really test without making new accounts each time).
I am very confused by the BC documentation on their API, because they let you create "Draft Apps" (private apps) and now I see that in their documentation they say "We do not currently provide a means of keeping OAuth apps private.".
My concern here is that they made some changes recently that might have affected a few of my Private Apps that I had running just fine a month ago. If anyone can provide some insight, I would appreciate it greatly!
https://developer.bigcommerce.com/api/guides/oauth-transition
There is nothing wrong with creating oAuth credentials with a "Draft App" for the sole purpose of accessing the API of your store. You do not ever have to publish your app and your app will never be made "public" in that case. You also don't have to bother with the 'Load Callback URL' and filling out the details on your draft app, unless you want to provide yourself an interface in the store.
The "Draft App" function was specifically meant to allow Developers building apps for the BC App Marketplace to test their apps in a store before submission. However, you can use it to make a private application that is only intended for your store - I'm including the process here for others!
Making a Private App with oAuth (or How to Generate oAuth Credentials for a Store)
What you will need
Access to the account listed as the "store owner" of the store where you want to install your app or the ability to get a person with access to complete a couple steps
Ability to setup a local or public URL to receive the 'Auth Callback Request'
Getting started
The first thing you should do is sort out making available a local or public URL that can receive an "Auth Callback" request. This resource must be able to work over an HTTPS connection but the SSL can be self-signed. The 'Auth Callback' request from Bigcommerce is a GET request that will have 3 query parameters on the URL: code, scope, and context.
It is described in greater detail here:
https://developer.bigcommerce.com/api/callback#get-req
Additional info
When building a public app it is important that the service receiving the Auth Callback request be configured to catch the 3 query values and combine them with information you already have. You would then send all of this information in a POST to the BC oAuth Token service to generate your API token for the store. In addition to that you would want to respond to the Auth Callback request with a 200 status and an interface, or instructions, for the user.
In the context of building a private application you don't need to worry about any of that. All you need to do is capture the query values. If you have this already then go ahead and jump down to the section on generating an API token below.
Before Moving On
You should have a URL path that can receive a GET request and captures query parameters. Test it out and make sure it works. Here are a couple example URLs:
https://example.com/auth-callback
https://localhost:8000/auth-service
Registering an App
The key point here is that the registration of the app must be completed by the store owner account of the store where you want to install the app. If you have access to the store owner account credentials then follow the steps at the bottom of this page:
https://developer.bigcommerce.com/api/registration
If you are working with the store owner then you can direct them to complete the steps above. You will need to provide them the Auth Callback URL you created for completing Step 9. The Load Callback URL does have to be filled in but the default example provided can be left in place.
SCOPES
When registering an app you are able to choose the scopes for the app. It is simple to just leave them all open but it is best practice to only enable the scopes you need. Here is a list of the scopes:
https://developer.bigcommerce.com/api/scopes
If you are not sure whether or not you will need a certain scope then leave it enabled because you will have to re-generate your API Token (perform a re-install of the app) if you have to change the scopes on your app.
Before Moving On
You need to have the client_id and client_secret. If someone else registered the app then you will need to ask them for this. There is a View Client ID button that will provide it after registering an app.
Generate the Auth Callback Request
You will need the person with store owner access again for this step. They will need to login to their store and go to the Apps section on the left side column. After that click on Marketplace -> then My Apps (in the top-right) -> then My Draft Apps
You should now see a list containing any "apps" that the store owner has registered. Choose the one relating to the client_id you plan to use. Click to install the app.
The Auth Callback request has now been sent and you are done here. You should expect to see just a blank or grey page as a result unless you are responding to the Auth Callback request with content. Your app is now awaiting authentication.
If using a self-signed certificate
When your Auth Callback URL has a self-signed certificate then you will see a "untrusted cert" error in your browser when you attempt installation of the app. You should choose to trust the certificate and continue.
Before Moving On
You should now have received the code, scope, and context at your Auth Callback URL. If you did not it was likely due to not having SSL/TLS at your server. You can replay the Auth Callback request as many times as needed by Cancelling Installation of the app in the same place where you started it. You can even open up a Dev tool and watch the request happen to see what errors show up in the console. If this is continuing to fail then you should reach out to Bigcommerce support or ask a new question on here!
Generating an API Token to Complete Installation
Follow the steps here:
https://developer.bigcommerce.com/api/callback#post-req
You should have all of the details needed to send a POST request to the BC Auth Token Service at https://login.bigcommerce.com/oauth2/token
Make sure to URL encode your content and you should be good! Here is a site that can URL encode and decode for you: http://meyerweb.com/eric/tools/dencoder/
Just be careful of it encoding & and = signs when those are actually being used as separators between fields or between field/value (respectively).
Before Moving On
You should have received a successful response from the Auth service which will include your API Token. Once you have this you are all set to access the API of the store. You no longer need to have your Auth Callback URL up and available and can take that down.
Also take note of the context to use to create your API path.
Accessing the API
Now that you have your API Token and context you are all set to access the API of a store. Start off with a simple request to the /time endpoint.
Make a GET request and include the following headers (minus the curly braces):
X-Auth-Client: {CLIENT_ID}
X-Auth-Token: {API_TOKEN}
Accept: application/json
Content-Type: application/json
Send your request to a URL path of (minus curly braces):
https://api.bigcommerce.com/{context}/v2/time
If you get back a 200 response then you are all set!
Additional Notes - Ways to Break Credentials
Once you have successfully generated an API Token for a certain app, that app will display in the Control Panel as an icon in the Apps section. The fact the app is there shows it is installed and allowing access. If you uninstall that app then the previously generated API token will stop working.
Changing the scopes on an already installed app will require it to be re-installed to correct the token.
Changing the store owner email on the store will cause the token to stop working. The API Token is specifically tied to the store owner that registered the app.
if you have apps in "My draft apps" and you used basic oauth, you will have to change to Oauth Authentication, but if only have private apps using "legacy api account", you will not need to change.
I am trying to automate the entire process of creating a google apps account through my company's reseller account with google, without any human having to manually enable anything.
Here's a quick scenario of what I am doing.
Create Customer (Domain) with Reseller API
Create Subscription with Reseller API
Create Admin Account for the Sold Domain
I am having trouble automating step 3.
There are 2 different APIs that can accomplish this tast, Provisioning (depricated) and Directory.
I have already successfully created user accounts with the Directory API, but this step requires you to enable API access for that domain, and that can only be done manually by a human - So thats a break in automation flow, and wont work for what I am trying to accomplish.
I was instructed by google tech support to use the Provisioning API, wich is deprecated, because it supposedly allows you to create an admin user without the need to enable the API access manually per domain. When I attempt to do this, I face this error:
Uncaught exception 'Zend_Gdata_App_HttpException' with message 'Expected response code 200, got 403 <HTML> <HEAD> <TITLE>You are not authorized to perform operations on the domain mydomain.com</TITLE>
Here's the code im attempting to run:
// .....
$customerid = "somedomain.com";
$client = Zend_Gdata_ClientLogin::getHttpClient("mylogin#foo.com", "mypassword",Zend_Gdata_Gapps::AUTH_SERVICE_NAME);
$gdata = new Zend_Gdata_Gapps($client, $customerid);
$gdata->createUser('Admin', 'Firstname', 'Lastname', 'somerandompassword', TRUE);
//......
When I consulted google tech support, they told me I needed to enable the provisioning api following the same instruction I posted earlier (enable api access per domain). I have done this on both my reseller domain, and the customer domain Im trying to provision on (just to test, becasue the entire point is to be able to make an admin account WITHOUT enabling it on the customer domain.) - But it still returns this error.
Here's my settings -- as you can see, its enabled.
In google's docs, under "Enabling the Provisioning API", it has some instructions, but they appear to be out of date and dont really reflect sections available in the current google apps admin panel.
Im at a loss. Am I missing something obvious, or is it just not possible to do at this time?
Just for reference, I have found a few other people asking a similar question, but with less detail:
Google Reseller Customer Admin User Creation Admin SDK How
How to create the domain administrator of a Google Apps domain purchased via the reseller API
EDIT: Added image showing settings, and code sample.
try to delete "TRUE" parameter in createUser , it's works for me.
$customerid = "sampledomain.com";
$client = Zend_Gdata_ClientLogin::getHttpClient($email, $password, Zend_Gdata_Gapps::AUTH_SERVICE_NAME);
$gdata = new Zend_Gdata_Gapps($client, $customerid);
var_dump($gdata->createUser('trial', 'Firstname', 'Lastname', 'somerandompassword'));
in Google app console
domain settings ->user settings
check the box "enable API access"
in Google app console --> advanced tools --> Manage third party OAuth Client access
Add the scope :
https://apps-apis.google.com/a/feeds/user
We are trying to use google.picker to have our users upload files to our drive account (i.e., the user is not required to have a Google account to upload).
We're trying to use regular Google accounts as application-owned accounts and got our AUTH_TOKEN using OAuth2 and set it using .setOAuthToken(AUTH_TOKEN) . We followed everything described in the docs.
However, when uploading, we got a Server Rejected error. The call to https://docs.google.com/upload/resumableupload?authuser=undefined returned:
{"errorMessage":{"reason":"REQUEST_REJECTED","additionalInfo":{"uploader_service.GoogleRupioAdditionalInfo":{"completionInfo":{"status":"REJECTED"},"requestRejectedInfo":{"reasonDescription":"agent_rejected"}}},"upload_id":"AEnB2Ur64Gb0JDCk_8mg5EhpdcaqL82wBQHumHjcGvDqYibtksmUzhfhBolsmBFzRuvQPRyi43SYfactJZvIWYrQ6xAqzu3L9g"}}
We know we cannot use service accounts since the picker doesn't support it.
Do we miss something in getting the AUTH_TOKEN? Do we need to something in the console?
Give us a little more code, or check the call to gapi.auth.authorize()
Check that you are using the correct scope to obtain the OAuth token.
Scope should be https://www.googleapis.com/auth/drive
Double-Check the scope declaration:
https://developers.google.com/accounts/docs/OAuth2Login#sendauthrequest
Check the call to gapi.auth.authorize()
window.gapi.auth.authorize(
{
'client_id': clientId,
'scope': scope,
'immediate': false
},
handleAuthResult);
from: https://developers.google.com/picker/docs/#hiworld
Without an actual code sample, it is very difficult to say exactly what is going on. Most likely it is the auth token colection. However, it may also be something as simple as not defining a google User (clientID) which in turn impacts the gapi.auth.authorize() call.
maybe this thread can help you: https://groups.google.com/forum/#!topic/Google-Picker-API/PPd0GEESO78
It is about setting the oauth context
or this one:
https://productforums.google.com/forum/#!msg/drive/GDl4uBkkbxM/jRejcxI-EV8J
It is about the type of file you try to upload with autoconvert on..
Use a Google Apps script on Drive with the function doPost to send data to the server. Then write to file with the Drive API. On publish, you have to set the permissions to "accessible to anyone, even anonomous" if doing cross-domain calls. Make the script run under your user name in Google (for testing), but most likely you would want that function moved onto some application-user account in Gmail.
If you need a level of authentication involved, even if the script is made public, you may authenticate against a CloudSQL hosted database and/or with the Jdbc library to connect to an external resource.
The Scope seems to be the problem.OAuth Token must be obtained using correct scope only:
http://tinyurl.com/ldotq4y
Easily replace scope: 'https://www.googleapis.com/auth/drive.readonly' to scope: 'https://www.googleapis.com/auth/drive' . So that you're allow to make change including upload something to your Google Drive account.