I am asking this question after extensively reading Google's recommended approach, but I do have a problem with all these approaches, let me explain the situation.
I use combination of geolocation and geocoding API to know the approximate state location and then display relevant content. The geolocation API needs to be called obviously from the browser to get appropriate geolocation of the user. Google provides HTTP Referrer based restriction for this API. I know someone can easily spoof the referrer and make calls with the same API key. I do not see a huge advantage even though Google recommends this.
On the other hand Google does not allow HTTP Referrer for geocoding API, but it does allow that for the MAPS JavaScript API. But again if you are not using Google maps then using that API is violation of Google's terms. Now google recommends to move the code that uses geocoding web services API to be on the back-end so that your key will be protected. But since ultimately I need to deliver the result to a front-end web application that is publicly accessible and I can only make a browser based Ajax call to first get the geolocation to feed to geocoding, I ultimately need to make an Ajax call to get my geocoding information. Then someone can easily just latch onto my end-point to piggy back on and call the geocoding API as much as they want. So for situations like this I want to know what is the ideal and secured way to deal with. May be there are other APIs that might be an ideal situation for this.
In my case, I am not doing any maps so it's all purely server-side to get latitudes, longitudes and driving distance between two points. This today from Google support which might help and if you're using maps, then the links may provide further insight.
Regarding API restrictions, please note that HTTP referrers will not
work on Geocoding API since HTTP referrers can only be used for client
side services. In other words, Geocoding is a web service API and
should only be used on server-side implementation. IP address
restrictions should be used for web service APIs. However, if you are
using the Geocoding API in a website, IP address restriction would not
work. Please check the suitable restrictions for each API in the
following link:
https://developers.google.com/maps/api-key-best-practices#api_key_table
To make this work, you should create a separate key and use the new
one in your Geocoding API request URL. You may add a restriction to
this key by using an "API restriction", and restrict it to Geocoding
API only. If you don't want to create another key, you may keep using
your current one but make sure to change your implementation and use
the client side Geocoding service from the Maps JavaScript API. In
that case, please refer to this documentation:
https://developers.google.com/maps/documentation/javascript/geocoding
Another suggestion would be to get a static IP address from your ISP,
especially if you are planning to use it on a public website. For
development purposes, a sound solution would be to get three separate
keys: one for the staging and tests, another for server-side requests
and a third one for client-side requests. That way, you are making
sure your API key is protected.
Related
I would like to access the adwords API through a simple single page web application using javascript. I would like to dynamically stop and start some of my adwords campaigns.
I can't seem to find any documentation on the REST endpoints for the API - only documentation for the various libraries.
Is it possible to do this through javascript only?
The current Adwords API is a SOAP-based interface, so there are no REST endpoints to use. It's of course still possible to construct SOAP messages and call operations without using one of the provided libraries.
Having said that, the next evolution of the API (the "Google Ads API") will support both gRPC and JSON REST-based communication, which would probably fit your scenario better. It's not yet ready for production use, however.
Is there a way, I can access Images API from the browser, without actually exposing my API Keys and credentials ? This question applies to any API. How can we expose an API to javascript client side browsers, without exposing secrets ?
It's discussed here: How to protect an API Key when using JavaScript?.
Short answer, make calls from server side as much as possible. In that case, you can whitelist your client through domain/IP/login, etc. From client side alone, you can make it difficult but not impossible for somebody willing to steal your keys.
You can also regenerate keys time-to-time just to be safe and keep track of your usage just to be sure.
I am using google shortener to generate a short URL, the long URL doesn't have any secret data, also the website is fully public.
there is any risk to put my API key in the source code for my app
You probably don't want to do that. If you put the API key in the source code, others will be able to call the Google API as you. From the getting started doc:
"By default, your registered project gets 1,000,000 requests per day for the URL Shortener API (see the Developers console for more details)."
This exposes you to a denial of service - if a malicious entity decides they don't like you, they can grab your source, make 1M short URL requests as you, and you will be unable to make the requests yourself.
Currently, I have been tasked to utilize the Google People API to ask for a user's basic Google information along with their public phone numbers. So far the results have been positive.
The solution my team and I have incorporated the Google People API integration in has the capacity to be utilized across thousands of domains. As a result, my question is simply, How can my team members and I ensure that any our clients that utilize our solution with their own particular domain get our new functionality built with the Google People API?
Keep in mind, our clients have the flexibility to have http/https and any subdomain on their site. Entering each domain possibility for our client base one by one would not be an easy task. I'm seriously hoping there is a solution around the single, explicit origin entries.
Thank you for your time and help.
Warning:
You must remember that if this is source code you are giving your clients that you are not allowed to release your client id and client secret. This includes plugins and scripts.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
So if your clients could view the code of your application and see your client id and secret you should not be giving it to them.
Read more about this issue Can I really not ship open source with Client ID?
Recommendation:
The best solution for you will be to instruct your users now to create there own project on Google Developer Console and create their own JS origins.
You may just have to provide your own wrapper around the target API where you authorize the client request yourself and then do the request from Google using your own credentials.
I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js