52

Am I correct in thinking that the goodness of Cloud Endpoints comes with the following limitations:

  1. The REST Api cannot be deployed to a custom domain (it'll remain on appspot.com).
  2. The only authentication supported is OAuth against Google accounts.
    1. Corollary: it isn't currently possible to create a user login/session-tracking mechanism that is Google-accounts-agnostic (e.g., with email as username and a password).

Is there any plan to do away with these limitations and if so, what is the ETA?

markvgti
  • 4,321
  • 7
  • 40
  • 62
  • 2
    I would add 2 more. (1) It is in preview mode almost 1.5 years after release and seems to have stagnated, so its status is a bit uncertain, and (2) I've seen people complain that you are forced to make your API public. – Tom Nov 05 '13 at 16:47
  • Good points!! any updates after GA release? – ZiglioUK Nov 12 '13 at 08:51
  • 1
    Please vote up the question --- that may help us get an authoritative response. – markvgti Nov 12 '13 at 09:20
  • Have been struggling all day with Endpoints and got nowhere https://plus.google.com/+EmanueleZiglioli/posts/5bYytiELVkd – ZiglioUK Jan 16 '14 at 11:04
  • Also https://groups.google.com/forum/#!topic/vosao-cms-development/ewHp8abVLBE – ZiglioUK Jan 16 '14 at 11:07

1 Answers1

20

Taking these item by item:

  1. Currently, yes this is still the case. Keep in mind, our initial release is targeted at a same-party use-case, where the domain you're serving from basically doesn't matter (it's not user/developer-facing). If you want to use your API to drive a website, you can use your custom domain to have your user-facing content, and still make requests to your appspot domain using CORS. If you're building a mobile app, no one sees the domain at all.
  2. Built-in support (i.e. using the User object) is limited to Google accounts, but you're free to build your own authentication scheme by checking the OAuth headers (or email/password if you must...)
  3. (From the comments, regarding GA status). Endpoints is now GA.
  4. (From the comments, regarding public APIs). Your APIs must be public, but you can limit the clients that can make requests. If you want to make a secret API, i.e. the existence of the API must itself be protected, that's not currently supported. I'd be curious to hear how popular a request this is, but I suspect it's not a blocker for most people.
Dan Holevoet
  • 9,183
  • 1
  • 33
  • 49
  • 2
    Regarding point 2: do you mean that I should make my App Engine application an OAuth2 provider, and that I could then use that provider instead of Google to authenticate my users (who don't need to have a Google account then)? Could I still use the Google APIs Explorer with my own OAuth2 provider? – Korneel Dec 18 '13 at 08:13
  • 3
    The built-in auth mechanism of the APIs Explorer only works with Google account auth. However, you can provide arbitrary parameters in your requests (e.g. `token=foo`) that can signify whatever you want. In my answer I was referring to being an OAuth _consumer_ for a different provider (e.g. Facebook). You could roll your own, but I wouldn't recommend it. – Dan Holevoet Dec 18 '13 at 21:11
  • 1
    @DanHolevoet is there any documentation on your point (2)? We already have 10^5 registered users using with email/password auth and need to expose an authenticated API to a mobile app. – tx802 Aug 12 '15 at 15:09
  • @DanHolevoet On Point 4. I have a endpoint service which is used by other service. There is no user intervention in between. I want my end point to be accessed by only this service. How can i secure it. When i followed the documentation about web client id, still i am able to access my end point from any client. Any help on this? – Bharathi Mar 31 '16 at 09:55