I am creating a Ruby application that needs to access dozens (maybe hundreds) of different Google Analytics accounts, query each account, and then generate a report based on the results. I know I can achieve this using Googles API client ( http://code.google.com/p/google-api-ruby-client/ ) and Oauth, but that would require manually generating a set of keys and credentials for each analytics account which is not really feasible. I'm wondering if there is another way to access google analytics (perhaps using the API Keys?) that bypasses the need to generate credentials manually.
After quite a bit of tinkering, I've finally stumbled upon a solution to my particular problem. As it turns out, I don't need to create a separate Developer account for each Analytics account I want to access. I can simply create a single Developer account, and then add that Developer accounts' email address to the set of users that are able to access the Analytics account. This will allow me to access multiple Analytics accounts using the same Developer account.
Yes, it will still require quite a bit of work adding the Developer email account to hundreds of Google Analytics accounts, but it pales in comparison to creating a separate set of Developer credentials for each Analytics account.
Related
I need to authenticate to an API using OAUTH2, however, it has to be made programmatically, no user typing stuff in a browser is permitted.
This seems like such a simple use case, but I haven't found anything online, the only thing close to it was this post, and the only answer is "yeah, you don't want to use a web browser, but what if you do?"... This doesn't help.
So, please, opening a web browser is not an option, I just want to know if Google provides any way to authenticate purely through code.
Thank you!
In order to achieve your goal, I would like to propose to use the Service account. When the Service account is used, the access token can be retrieved without using the browser.
As the points for using the Service account, please check the following points.
The Service account is not your own Google account.
For example, as one of several situations, if you want to manage a file in your Google Drive using the Service account, please share the file with the Service account. By this, the Service account can access to the file in your Google Drive.
References:
OAuth2ServiceAccount
Several cases using the Service account
Google Drive Access - Service Account or OAuth - To read/write user files
Google service account not being authorized for calendar API
Service Account for google sheets returns not found
I'd like to create programmatically via API a new Account for accessing my Google Cloud Platform.
I'm already doing it for GSUITE (provisioning users via OAUTH), is it possible to do the same also with Google Cloud Platform?
Is it possible to do it for an "non-google" external account maybe with an invitation on the email?
Having already the setup for OAUTH in GSuite, is it possible to use the same token / account to perform also this operations (maybe assigning more scopes)?
Are this API (https://cloud.google.com/iam/docs/granting-changing-revoking-access) the only available?
Updating the IAM policy is indeed the only way to use an API to grant access on a "pure GCP" level.
However, you can give a role in a project to a Google Group (or a few, if you require different access levels), and then simply manage the group using the GSuite Admin SDK.
I need to access a NON-public Google calendar WITHOUT requiring the user to log in or even have a Google account.
I created an Android app that accesses a Google calendar using a service account:
GoogleCredential credential = new GoogleCredential.Builder()
.setTransport(httpTransport)
.setJsonFactory(jsonFactory)
.setServiceAccountId(serviceAccountID)
.setServiceAccountScopes(scopes)
.setServiceAccountPrivateKeyFromP12File(licenseFile)
.build();
com.google.api.services.calendar.Calendar.Builder builder = new com.google.api.services.calendar.Calendar.Builder(httpTransport, jsonFactory, credential);
builder.setApplicationName(appName);
com.google.api.services.calendar.Calendar client = builder.build();
com.google.api.services.calendar.Calendar.Events.List list = client.events().list(calendarID);
list.setMaxAttendees(maxAttendees);
list.setTimeZone(timeZone);
list.setTimeMin(startTime);
list.setTimeMax(endTime);
list.setOrderBy(orderBy);
list.setShowDeleted(showDeleted);
list.setSingleEvents(true);
Events events = list.execute();
This included:
Creating a project in the Google App console
Creating a Service Account
Giving the Service Account access rights to the Google calendar
It works GREAT!
I need to do the same thing in IOS. I have read every question/answer I can find on this topic and have found VERY different answers. Many say that Google hasn't allowed this in the IOS SDK because service accounts are intended to be used by server-based applications. I don't agree since the functionality I need is available in Android. So, now what?
The use case is this:
My IOS app needs to access a Google calendar. That part is not too tough if you are okay with using OAuth. My problems with this approach are:
Requires to user to have a Google account. Many of my users are Apple-Only. I can't require them to get a Google account just to use my app.
I can't make the calendar public. So, I would need to give access to every new user. I guess I could do that with a web-based application but this doesn't fix the problem (refer to previous problem - no Google account).
I really need to be able to query the events in the NON-public Google Calendar WITHOUT the user needing a Google account. The solution IS using a "Service Account" (I think).
I read one question/answer that said this is possible but the solution was never posted. (How to list Google Calendar Events without User Authentication)
HELP!!!!
The official documentation suggests that if you want to handle Calendar API (for example), you'll have to have a Google Apps for Work (source).
If you have a Google Apps domain—if you use Google Apps for Work, for example—an administrator of the Google Apps domain can authorize an application to access user data on behalf of users in the Google Apps domain. For example, an application that uses the Google Calendar API to add events to the calendars of all users in a Google Apps domain would use a service account to access the Google Calendar API on behalf of users.
Once the prerequisite is met, you can try to just call the REST URLs of Calendar API based on your implementation (since there seems to be no iOS support or samples available in the documentation).
We are trying to integrate Google adwords connectivity into our Marketing Analytics Web application, meaning we are creating an app that would allow small businesses to login to their AdWords accounts and manage them based on findings of our app.
The problem is that upon signing up for API Access AdWords is asking us to link 'our' adwords account to the app account as well. This does not make too much sense to us, why do we need to show our adwords account when we ourselves will not be the main users of the app. It almost seems that AdWords assumes only a couple of users will be using the API.
Is my thinking flawed here? Can anyone clarify?
Google does seem to assume that their AdWords API is used primarily for in-house reporting and account management (as well by advertising agencies managing accounts on behalf of their clients).
Even if you are building an app for general, public use, the app's Client ID, Client Secret, and Developer Token are still connected to your company's MCC account.
However, this does not cause a problem. Any AdWords account owner can authorize your app to access their data, without having to be your client.
I'm creating a simple iPhone app. The basic premise is that the app will display some data (That I provide online) on the application. The data changes over time, so the app has to draw the data from online and display it. I don't have a significant programming background so I don't want to use my own server.
Thus, I thought it would be significantly easier to just put the data into some documents on a Google account and then access them programmatically via the Google Drive API. I could then update the data in my Drive account and it would get updated in the application. The key here is that I am ONLY accessing ONE account that I own MYSELF. The users' accounts are not being accessed. Therefore the goal is to never have to log in manually. It should all happen behind the scenes, aka, it should look like a server, not a google doc.
With this in mind, it doesn't make sense to show the Google Accounts sign-in page to my users as the standard OAuth2.0 tutorial shows here:https://developers.google.com/drive/quickstart-ios#step_1_enable_the_drive_api
I should be able to access my own data by somehow hardcoding in my username, password etc. Google agrees here: https://developers.google.com/drive/service-accounts#use_regular_google_accounts_as_application-owned_accounts
The above link mentions a "refresh token" that I'm supposed to save. However, I have no idea how to build and save that token, or even for that matter, where to find it.
I've gone through both the basic tutorial and the Dr. Edit Tutorial for iOS, but they both assume that the application is accessing USER accounts not application-owned accounts.
I'm not asking for someone to write the code for me (though tidbits are nice), but if you can point me to a step-by-step guide or related sample code that would help me get started that would be awesome. I'll even come back and post the code that I use!
EDIT: Since I realized that the Google Drive API wasn't something I could use for what I am trying to do, I eventually found Parse which is an awesome tool that handles all the server backend for me and is free at the basic level.
Google APIs objective-C client library doesn't support service (application-owned) accounts, because they are supposed to be used by a server-side apps, instead of clients -- you shouldn't be distributing your private key as a part of an app.
If you would like to distribute content from a service account, maybe you should write a server leg to do the authentication and pass clients credentials in a secure way for them to talk to the API on the behalf of the service account. Or, use Web publishing to make documents universally accessible without authorization and authentication if privacy is not a concern.