2

I have an API in Google Endpoints, and I've generated the API key needed by the Android App I'm working on to access the API. However I have no idea where to supply the API Key when using generated clients library. Every request made from the app returns a 403, Android app is forbidden. I've read also in SO that it should be given in the header, but the closest that the Google Endpoints API docs mentioned is that an API key should be part of the URL, which however doesn't seem to be case if the request is from an Android client.

When the API key is removed from the API, any query, even curl, is able to retrieve the expected result. Any documentation on how this should be done with code examples will also be very much appreciated.

Edit: I am also wondering if Google itself has placed restrictions on using the android debug.keystore's SHA-1 in Endpoints.

Ps: my earlier question regarding this was unfairly down voted and the only answer received was about country restrictions, which I am sure has nothing to do with this. So maybe this time I'll rephrase my question in another way.

redflour
  • 163
  • 11
  • Aren't api keys in android always provided through manifest? – Alen Zarkovic Dec 06 '17 at 12:55
  • Are they? If they are, please, I'm pleading/begging, kindly point me to an example. – redflour Dec 06 '17 at 13:00
  • Apparently i was wrong/didn't understand the problem precisely, but i found this that might help you out https://rominirani.com/google-cloud-endpoints-tutorial-part-7-8cc471fccbf6 – Alen Zarkovic Dec 06 '17 at 13:12
  • It doesn't seem to touch on using API Keys. It's amazing how something so trivial is hardly documented in the Google Endpoints docs. – redflour Dec 06 '17 at 13:35
  • If you're using a Google generated client library, you should set the key via a `.setKey()` call in the request object. – saiyr Dec 06 '17 at 18:45
  • Indeed it seems so. But with that the backend returns 403 with the message along the lines of 'android app is forbidden to access'. The leads me to assume that Endpoints expects the key to be included in another way. – redflour Dec 07 '17 at 00:12

1 Answers1

2

I've managed to get at least one type of API key to work with a Google Cloud Endpoints API. Here's how:

1) The 'usable' API key was generated by not having any restrictions to it (ie: not Android App, Web, etc). You can select restrictions for a key when creating it in the API credentials page.

2) The 'usable' key was passed to the generated clients library through the service..setKey(...) method.

This somewhat produced what I was going for; allowing calls to the API only by callers that can identify themselves. The reason why it works (complete assumptions and guess work from this point onward) is that the generated client library makes a HTTPS request to the API, and therefore, the authorization checks should then be done by the API (Endpoints framework) in the context of a HTTPS request, rather than in the context of an Android App.

If this is true, than I am very much interested in finding out how does an Android App make a 'correct' call to an API with the generated client library.

Update: Screenshot and code of current setup

In Google Cloud Console -> API & Services -> Credentials enter image description here

Usage of API Key in Java code:

// Call to the generated client library for the API
DataCollection dataCollection =  service.getDataAPIMethod()
                .setX(...)
                .setY(...)
                .setZ(...)
                .setKey("***")
                .execute();
redflour
  • 163
  • 11
  • Could you please include some of your code in the answer. I'm facing some similar problems but your answer would be clearer if i could see what you've done – NNN Feb 22 '18 at 10:40
  • @Nikolaus I've added the screenshot for the setup in Google Cloud Endpoints, and the usage for the client library in the Java code. There really isn't much on the side of codes. More to how the API keys are setup. – redflour Feb 23 '18 at 04:39
  • were you able to add key restrictions on it ? – Aalap Jul 03 '18 at 13:45