Restrict API access to my Frontend app using daily random API key - api

I'm creating an API that will be accessed solely by my Vue.js application for displaying data like movie times, video on demand links, etc. No private sensitive info, but I would like to avoid other people and bots using my resources to get free data. I know restricting an API to my own one-page frontend application is almost impossible, as someone can always either:
Get the API key from the page source
Spoof the referrer header to the one that my API is restricted to
So I was thinking to "attenuate the damage", i.e. the amount of bots using my API, by having the backend server generate an API key every day at noon for example. Then when the PHP loads the Vue.js application, it inserts that API key in the Vue.js code, which will use it to query my Python API. If Vue gets an "incorrect API key" error (case when the page was loaded at 11:59 and a request was sent at 12:01), the Vue.js would refresh the page to get the new key.
This way, if someone took the API key from the source, it would expire in less than 24 hours anyways. Of course someone could scrape the page to get the API key every day and still use the API, but I feel this would stop a lot of bots and spammers.
Has anyone ever tried anything like this? Does it sound like a viable solution or there is something better to be done that I couldn't find on StackOverflow?

How about Server-side Rendering from the same location (server, private DNS) as the API server?
You can write fetch(api) within the server function itself.

Related

How to call Google NLP Api from a Google Chrome extension

My aim is to select some text from a web page, start a google chrome extension and give the text to a google cloud api (Natural Language API) in my case.
I want to do some sentimental analysis and then get back the result to mark/ highlight positive sentences in green and negative ones in red.
I am new to this and do not know how to start.
The extension consists of manifest, popup etc. How should I call an API from there that does Natural Language Processing?
Should I create a Google Cloud Application with an API_KEY to call? In that case I would have to upload my credentials right?
Sorry sounds a bit confusing I know but I just don't know how I can bring this 2 things together an would be more than happy about any help
The best way to authenticate your app will depend on the specific needs and use cases of your application. You can see an overview of all the different methods here.
If you are not planning on identifying users nor on using a back end server that handles authenticating (as I assume to be your case), the best option would indeed be to use API keys. They do not identify the user, but are enough for the Natural Language APIs.
To do this you will need to create an API key for the services you want and add the necessary restrictions to make the key as secure as possible. Detailed instructions on how to do this and how to use the key in a url can be found here.
The API call could be made from within the Chrome extension with any JavaScript method capable of performing POST requests. For example using XMLHttpRequest or the Fetch API. You can find an example of the parameters that need to be included in the request here.
You may run into CORS issues when making the request directly from the extension. I recommend reading this answer, where a couple of workarounds for these issues are suggested.

Workaround for SoundCloud and its lack of client ids

my company hosts a lot of audio on SoundCloud. We never had a client id. Now we want to start collecting data but I can't use the SDK without that id which, of course, SoundCloud stopped giving out over a year ago (and has not done anything to offer alternatives). Does anyone have any experience with, or a workaround for, this?
Had roughly the same problem.
You could use your browsers client_id to query the API.
Just navigate to a track page in a Browser, hit F12, open the Networking tab and click play. Look out for requests containing a client_id and copy that.
I did this a while ago (3-4 Months), and they're still working.
Con: You can't access OAuth and private stuff, just public content.

Get client_id/client_secret From Tesla Motors API

I'm making an app to keep track of things like miles driven, Kwh used, etc. But I'm having a hard time figuring out how to get a client_id and client_secret being that the API is unofficial.
Here's the Apiary with the API details:
http://docs.timdorr.apiary.io/#reference/authentication/tokens/get-an-access-token?console=1
Anyone know how to generate them? or is everyone else that makes an app for an unofficial API just making a random string for those?
The apiary web site tells you to use the following values.
"client_id”: "81527cff06843c8634fdc09e8ac0abefb46ac849f38fe1e431c2ef2106796384",
"client_secret": "c7257eb71a564034f9419ee651c7d0e5f7aa6bfbd18bafb5c5c033b093bb2fa3",
Another option would be to use the Smartcar's API! The cliend_id and client_secret appear on your dashboard once you sign up (https://smartcar.com), it is very easy to find them. The API also allows you to do other stuff like locking and unlocking the tesla, finding the location, etc.
You can also check the Odometer API endpoint page to learn more about how you can get the miles driven here (https://smartcar.com/product/odometer/).

Regarding the use of API's

My app is a Personal Assistant who's main job is to redirect the user to something that complies with his/her wishes. I realize, for example that AllRecipies.com has no API. My question is that can I, say open the browser app with the url as
http://allrecipes.com/search/results/?wt=QUERY>&sort=re.
Is this considered as using their API? Not just AllRecipies, but numerous other such services. If I am using this method, then do I have to request API key, etc? I am not retrieving anything. I am simply redirecting the user to their page with the query pre-written. Does this require all the licensing fees, API Key, etc?
Do I have to agree to this fees(If they ask), Request API Key, etc?
With the particular URL in question, it is simply an HTML web server URL, rather than a web API, as such. You can still get data out of it, but you'd have to parse the HTML yourself to extract what you want from the HTML response.
They may have an API that you can use to access data more directly as JSON, XML, etc, but you'll have to look into that yourself. And you will possibly require an API key to access it. But perhaps not, if it's publicly available and they don't care how many calls they get to it by anonymous users.
You may find this resource useful. It contains a lot of open APIs and code snippets to access them: http://www.programmableweb.com/
If you are simply trying to hit a URL or directing a user to this particular URL which you already know and is static meaning you always hit the same url without change in parameters, then this is not considered an API call and will not be requiring any API key.
However, if they have some APIs exposed, you will need to go through their documentation and using this API most likely requires the use of an API key(alhough this might not be true always). Usually, most platforms have a bunch of APIs available for different scenarios and these are called based on user specific parameters and requirements.

How can I protect my API and know what is calling it?

I am building a Web application, and Web API. The Web application will do ajax call to the server and receive JSON results. The same will happen to the Web API.
I am planing to ask developers to use keys to access the Web API so that I can charge for their uses of it.
The problem is the Web API will be use by the Web application to get the content for the web pages. Is there a way to know if it is my Web application using the Web API or someone trying to highjack the API so that they don't have to pay for it?
I am using PHP on my server.
It's difficult to protect completely but there are techniques that help. ApiAxle (disclaimer: my company) gives you the option of using short lived keys. These will be impossible for a leecher to generate without knowing your secret key. Paired with rate limiting you're getting somewhat closer to where you want to be.
Not foolproof but a start.
When trying to secure something on the web, it might be useful to think about how you want to protect the information that you provide by the api before you try to find a technique for protecting the api.
An example:
Say that your api provides the current weather in London and your web application is an open web page that provides this information while also showing some web ads. You don't want someone else to use the api and show the Lonodn weather somewhere else without showing the web ad because that would ruin your sole income from this service.
You could limit access to the api by providing i.e. short time keys or another complicated protocol, but the problem here is that the information you provides, the London weather, is available to anyone on the web page anyway. If someone wants to "steal" your information and provide the London weather on a different web site they can just write a script that loads your web application, reads the information from the web page and display this in their own web application.
If a person is able to access the information, then he can also write a script that reads this information and display the information somewhere else.
Securing information is actually more about limiting who you want to give access and not so much about how they should get access. If you or your clients makes this information freely available on the net in one form or another, then you cannot (technically) prevent someone else from picking it up and redistribute it.