I'm using Google client libraries and trying to make a GET request to Google Play API.
GoogleCredential credential= new GoogleCredential.Builder().setTransport(netHttpTransport)
.setJsonFactory(jacksonFactory)
.setServiceAccountId(CLIENT_ID)
.setServiceAccountScopes(SCOPE)
.setServiceAccountPrivateKeyFromP12File(file)
.build();
credential.refreshToken();
HttpRequestFactory requestFactory =netHttpTransport.createRequestFactory(credential);
GenericUrl url = new GenericUrl(URI);
HttpRequest request = requestFactory.buildGetRequest(url);
HttpResponse response = request.execute();
I get
{
"code" : 401,
"errors" : [ {
"domain" : "androidpublisher",
"message" : "This developer account does not own the application.",
"reason" : "developerDoesNotOwnApplication"
} ],
"message" : "This developer account does not own the application."
}
My app is unpublished, would that cause the problem?
I've got the same problem. It occurs because you authorize user in Google API who does not own the application and try to get data that belong to your app.
In this topic it is well described. http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=2528691&topic=16285&ctx=topic
You should authorize by OAuth2 the owner of application, and then use Google API with obtained token.
The problem is you are using the Service accounts OAuth 2.0 flow to authorize to the android-publisher API. I was doing it the same way. However, Google requires to use the Web server applications flow, which is ridiculous, since a human interaction is needed to allow for the API access.
Fortunately there is a way around it. You just have to obtain the refresh_token, store that and keep using it for future API calls. I wrote about it in more detail on my blog.
We also struggled with this problem as we wanted to validate a purchase on our servers in order to unlock certain features. We tried multiple solutions and frameworks, written by fellow community users and even official implementations but none worked.
Turns out all we had to do was renew our OAuth token (which we just created) and then it all started working.
I suspect that problem is exactly in publishing. You first need to bind your app to your (developer) account and then you will receive CLIENT_ID and other credentials (such as secret key and so on).
Related
I`m using Analytics Reporting API in my project to retrieve amount of users currently surfing my website. Consider following code:
gapi.auth2.init({
'clientId': '<Client_ID>',
'scope': 'https://www.googleapis.com/auth/analytics https://www.googleapis.com/auth/analytics.readonly',
}).then(function(authData) {
/*1*/
return gapi.client.request({
'path': 'https://www.googleapis.com/analytics/v3/data/realtime?ids=<VIEW_ID>&metrics=rt:activeUsers&dimensions=rt:latitude,rt:longitude'
});
But when i set debugger on the line with /*1*/ and want to investigate what`s inside "authData", in the developer console i see following:
>JSON.stringify(gapi.auth2.getAuthInstance().isSignedIn)
>"{"Ab":false,"Aia":{"value":false},"hg":{"hg":[]}}"
And inside authData i have following:
>JSON.stringify(a.currentUser)
>"{"Ab":{"El":null,"Zi":null},"Aia":{"value":{"El":null,"Zi":null}},"hg":{"hg":[]}}"
That indicates abscence of authenticated user, i presume.
Furthermore, http response for authentication request returns following error
>{error: "IMMEDIATE_FAILED", detail: "Not all scopes are approved."}
The question is: what does it mean and where can i approve those scopes by myself or maybe there is somone from Google who should approve scopes for my requests. Thanks.
Well i acidentally stumbled upon this solution. The reason for scopes to seem unapproved is that the application is not accepted inside an google account as capabke of accessing analytics data (and it's crucial as i use oAuth2 clientID bound to that particular account). So the solution is to allow your project to have access to your account. Sadly there is no such statement in api's docs, nor any example was found also.
I wrote a PHP application which tries to create an User in my Google Directory. I don't use the Google Libraries. I succeded making requests to the Android Enterprise API. I can enroll and unenroll Enterprise Service Accounts with my MSA. So I assume my Code for the JWT and Requests work.
I created a Service Account and enabled "Domain Wide Delegation" and added the following permission "https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.group" to my API Client under the "Manage API client access" windows.
My Service Account has the status role "Editor" in the "Permissions for project" windows.
So first my script gets the Bearer token from the Google Server, for that I create a JWT and encrypt it with my private key.
The Token contains the following fields
"iss" => sacname#projectname.iam.gserviceaccount.com
"scope" => "https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.group"
"aud" => "https://www.googleapis.com/oauth2/v4/token",
"exp" => timestamp+3000,
"iat" => timestamp
When I do that request I get a bearer token, but when I use that token to make the insert request I always get the message "Not Authorized to access this resource/api" with an HTTP 403.
When I add the field "sub" to my JWT and specify the email of the Project admin "admin#mydomain.com" I can't even get the bearer token, then I get a 401 error with the following message "Unauthorized client or scope in request."
After that I tried something "easy", I just wanted to get a list of all users in my directory. But the Google Server just reponds with an "bad request" error. I got the same error with the API Explorer which is on API Page. Maybe the API is broken ? At least the API Explorer should work.
https://developers.google.com/admin-sdk/directory/v1/reference/users/list
Do you have some ideas why I can't create users with my service account ?
(I had to insert some spaces in the scopes and urls because I'm not allowed to post more than two links)
Greetings
Philip
Adding the sub claim is the right thing to do, because you must impersonate a super admin to use Directory API. If you get a "Unauthorized client or scope in request" response, that might be because there's a typo in the service account client ID you used to authorize (or the scopes), or that not enough time has passed (it usually propagates within a few minutes, but could take up to 24 hours).
See JWT error codes for more details on possible errors and causes.
Do you have some ideas why I can't create users with my service account?
Yes. Your service account seems to have no authority to create users. Check your Service Account's role in GDC to check if it's Owner, Editor, Viewer,etc. The scope of what they can do depends on that. Watch this Google video for a live demo.
Also, try to read more on Using OAuth 2.0 for Server to Server Applications.
Where I work we use Google Apps for Work. For the last 9 months we've been using the Gmail API (~2,000 requests per day) to pull in new emails for our support email accounts.
This is how we originally set it up:
Go to https://console.developers.google.com/project/
Click on the project (or create a new one)
Click on API's & Auth
Click on Credentials
Click on Create new Client ID
Click on Service account
Download a JWT (json) for the account.
Follow the node.js quickstart guide with an installed/native type token for the same account, and authorize it through the console. The JWT tokens did not work unless we did this step, once for each account.
We did this for each of our individual support email accounts to avoid having to turn on domain wide delegation for any of them in the admin console. We were then able to authenticate with the tokens using the officially supported npm library googleapis, similar to this:
var google = require('googleapis');
var jwtClient = new google.auth.JWT(
token.client_email,
null,
token.private_key,
['https://www.googleapis.com/auth/gmail.readonly'],
'supportemail#mycompany.com'
);
jwtClient.authorize(function(err, tokens) {
if (err) {
return cb(err);
}
var gmail = google.gmail('v1');
var requestOptions = {
auth: jwtClient,
userId: 'me',
id: messageId,
format: 'raw'
};
gmail.users.messages.get(requestOptions, function(err, response) {
if (err) {
return cb(err);
}
// do stuff with the response
});
});
Like I said, we used this for a long time and never had any issues. Yesterday around 10am MST every one of the accounts stopped being able to authenticate at the same time, with jwtClient.authorize() suddenly returning the error [Error: unauthorized_client].
I tried doing the same thing with a new token on a new service account (the web interface to get the token has changed quite a bit in the last 9 months), and it returns the same error.
The version of googleapis that we were using was 0.9.7, but we can't get JWT authentication to work on the newest version either.
We opened a ticket with the Google APIs support team, but the support person we spoke with had never read the Gmail API specs before and was ultimately unable to help us, so he redirected us here in order to get in touch with the API engineering support team.
We have noticed that authentication works if we enable the scope for domain wide delegation in the admin console, but we would prefer not to do that. We don't need to impersonate the accounts and would prefer to use an individual JWT for each account.
It turns out that the auth flow we were using was never supported, and probably was broken due to a bugfix on Google's part.
In the question comments #Brandon Jewett-Hall and #Steve Bazyl recommended that we use the installed app auth flow instead, as it allows for indefinite refreshing of access tokens and is supported.
More information about the different auth flows can be found in the Google API docs.
For a mobile application (Cordova & AngularJS), I use Azure Mobile Services with Web Api.
I am currently experimenting with different OAuth implementations to see which one fits my needs the most.
Tried OAuth from ngCordova, OAuth.io, WAMS server flow and Auth0 with WAMS delegation.
I also came across the option using the "JsonWebToken DelegationHandler for WebAPI". With this approach, I should use the "System.Web.Http.Authorize" attribute. When I debug the JsonWebTokenValidationHandler, everything looks good (IsAuthenticated is true etc.), but at the end, a 401 is being returned.
I guess, WAMS overwrites the user principal. A look at the WAMS log reveals that "The 'Bearer' HTTP authentication scheme is not supported." As soon as there is such an authentication token present it seems to get rejected by Azure Mobile Services.
My first thought was, that I can probably remove a specific message handler but that doesn't seem to be the case. Does anyone have an idea to get this to work with WAMS?
There is another post with a question very similar to this one:
Azure mobile service using aad "The 'Bearer' HTTP authentication scheme is not supported" error
You can pass the application key in the header like so:
HttpClient.DefaultRequestHeaders.Add("X-ZUMO-APPLICATION", "<YOUR APP KEY>";
In that link, Matthew mentions details about how to user authentication and posts links on how to set it up properly which you may find valuable.
I'm trying to invoke any of the Google API using "Service account" authorization access. I have downloaded ".pk2" file and activated "URL Shortener API" in Services tab of Google API console. Whenever I try to invoke any API (URL shortener or Adsense). I've got following exception -
com.google.api.client.auth.oauth2.TokenResponseException: 400 Bad Request
{
"error" : "invalid_grant"
}
at com.google.api.client.auth.oauth2.TokenResponseException.from(TokenResponseException.java:105)
at com.google.api.client.auth.oauth2.TokenRequest.executeUnparsed(TokenRequest.java:303)
at com.google.api.client.auth.oauth2.TokenRequest.execute(TokenRequest.java:323)
at com.google.api.client.googleapis.auth.oauth2.GoogleCredential.executeRefreshToken(GoogleCredential.java:345)
at com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:526)
at com.google.api.client.auth.oauth2.Credential.intercept(Credential.java:287)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:836)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:412)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:345)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:463)
Below is code snippet -
HttpTransport HTTP_TRANSPORT = new NetHttpTransport();
JsonFactory JSON_FACTORY = new JacksonFactory();
File privateKey = new File(ReportAdsense.class.getResource("mykey.p12").toURI());
GoogleCredential credential = new GoogleCredential.Builder().setTransport(HTTP_TRANSPORT)
.setJsonFactory(JSON_FACTORY)
.setServiceAccountId("my_valid_account_id#developer.gserviceaccount.com")
.setServiceAccountScopes(UrlshortenerScopes.URLSHORTENER)
.setServiceAccountPrivateKeyFromP12File(privateKey)
.build();
Urlshortener service = new Urlshortener.Builder(new NetHttpTransport(), JSON_FACTORY, null).setHttpRequestInitializer(credential).build();
UrlHistory history = service.url().list().execute();
First of all "Service account" will not work for Adsense, since it requires user authorization. Hence for Adsense you should use Oauth 2.0. When you are authorized first time using URL https://accounts.google.com/o/oauth2/token, copy-paste and hardcode your refresh token. Than you can use it to get access token, specify client_id, client_secret and your refresh_token to get new access token. Now access token can be used in your application.
Regarding your error, I have faced with similar issue and spent plenty of time to resolve it. First of all, make sure that you are using valid ServiceAccountId - it should point to email which finishes with "developer.gserviceaccount.com". Make sure, that you specified account scopes and activated services in Google Console API.
I fixed this issue by synchronizing system clock in my machine.
There are a lot of topics with similar error without answers. Even more, some people says, that sometimes it works, sometimes it returns invalid grant. It could work on one machine and fail on another. I don't know if it is system clock issue, but I would avoid using Service Account API, since looks like there are bugs and support would not help you