How to restrict my endpoint api discovery - google-cloud-endpoints

I have an endpoint api at project-id.appspot.com. It is possible for anyone to see all methods (but not to run them) via google api explorer. How to disbable it? I don't want to tell publically what my api is.

The discovery document is used by the JS API client library, and as such was not designed to be disabled. There's currently no support for that.

Related

Send conversion event to Google Ads from NodeJs backend (AWS)

I have a website hosted in AWS with a NodeJS backend.
I have Google Ads conversion events being sent from the frontend using gtag.js, but I noticed missing events and a lot of duplication (even if I use transaction IDs with my events)
I has similar issues with Facebook Pixel and was able to resolve the problem by sending simple vanilla http calls from the backend.
Is it possible to do the same with Google Ads? I have not been able to find any documentation for server side APIs for Javascript.
This documentation here seems promising, but no Javascript SDK exists. That's is why I would like to know what vanilla http calls to make.
I have seen documentation about GTM server side, but it seems I need to host a GTM container (server?) which I would prefer not to have to. Unless I misunderstood what hosting a GTM container means in the context of a AWS cloud solution.
In addition to the native, gRPC-based Ads API there's also a REST alternative which can be used if there's no native client library, such as for NodeJS.
The endpoint relevant for your use case is customers.uploadClickConversions, which allows you to register a conversion given a specific click ID.
Keep in mind that you'll need to apply for API access in order to be able to use the Ads API (aside from accessing test accounts).

Is it possible to virtualize the API LAYER and don't write code?

I was surfing on internet for solutions and tools related to the API Layer and I find a company (maybe a startup) that is developing an ecosystem that allow to "virtualize the API Layer" (at the moment only in .net Core). It seems they allow to don't code the Api layer, don't write documentation of endpoints, don't writeE2E test (automatically inferred), change behaviour of endpoints at runtime and reuse the entire stack in another project. Do you think is it really possible something like this and useful in the world of API development? thanks
If I understand the question, your wondering about setting up an API layer with just the endpoints, but the endpoints have empty logic in them, right?
If so, then yes its possible to do this with a variety of tools. One tool I use is Postman, which allows you to setup a "skeleton" API you can call for design/testing purposes.
It allows standing up a mock server that hosts your skeleton API, in which any consumer can hook into.

Implementing 3D Secure using CyberSource REST API

I'm adding a support of CyberSource to our system and just got new requirement about 3D Secure support.
I've already implemented some flows using CyberSource REST API:
Payments
Card tokenisation via Flexible token
I'm a little bit confused, because I can't find any information about implementation of Payer Authentication in conjunction with the REST integration. All I found is the documentation for Simple Order API and SCMP API.
Am I missing something? Am I supposed to use any of the aforementioned docs or there is some separate document for REST API? Or I should use different integration method instead of REST?
Update 6-14-18: The payer authentication (3-D Secure) is now available with the REST API.
The payer authentication services are not available through the REST API at this time. I know they will be, but don't know when.
The only other option is using the SOAP API (SOAP Toolkit) or pre-built client (Simple Order API). SCMP is a legacy API and should not be used.

Make api explorer private

Is it possible to either turn off the api explorer completely or limit the access to it?
I noticed some logs in my app that come from failed requests executed from a browser. My api is only consumed by an Android app so the only place where they can come from is the api explorer. Also the api access is limited to 1 web and 1 android client id.
Unfortunately no. The API explorer works by using the Discovery Service associated with your API, which is not actually part of your backend, so you can't specify auth or visibility for those URIs.
The list method from the Discovery service is used to generate the list on the APIs Explorer app using your app as base:
discovery.apis.list:
your-app-id.appspot.com/_ah/api/discovery/v1/apis
When someone clicks one of the APIs from the list, the full discovery document is retrieved for that apiName and apiVersion using the getRest method from the Discovery service:
discovery.apis.getRest:
your-app-id.appspot.com/_ah/api/discovery/v1/apis/{apiName}/{apiVersion}/rest
If you are looking for ways to prevent the executing of the API, check out Cloud Endpoints: Control who can execute API through API Explorer
endpoints makes auth easy and you can get the current user. You should use auth to ensure people don't mess with your private apis - otherwise people could trace what kind of post or get requests you're sending anyway - auth is always a good idea rather than trying to keep your apis secret.
If you're building a secret product and you don't want your competitor to find out, you could perhaps use some obfuscation method on the backend and on your client which makes the apis unreadable.
Also a user messing with your apis shouldn't break your database - or if it does - it should only break it for the user that was being foolish. Having logic in your client for how apis are used so that the backend doesn't break is a bad idea - the backend apis should take care of themselves and not worry about how or why they are used and who by for what purpose.

Adobe Drive CMIS connector and Authentication

We have undertaken a project to make our DAM CMIS compliant and thus get connected with Adobe Drive using it's inbuilt CMIS connector. We will be following RESTful AtomPub binding of CMIS for this.
CMIS spec doesn't talk a lot about the authentication and seems like it is outside the scope of CMIS. I wanted to know how Adobe Drive client gets authenticated with any CMS/DAM using its CMIS connector. What is the mode of authentication used - is it HTTP basic, digest authentication or something custom. So I am not sure what would Adobe Drive send to get authenticated and what would it expect in the response. How do we pass back the session token that we will create.
Any pointers wrt this are appreciated.
Thanks!
http basic
Take a look at http://help.adobe.com/en_US/creativesuite/cs/adobedrive/CMIS_Connector_Tech_Note.pdf
Pages 6-7 show what you'd get in a valid connection response.

Resources