I was looking at the Google Fonts Developer API, where you can programatically query the Google Fonts catalog and get some JSON results. You have to get a an API key through Google to use it.
I want to create an extension/plugin for a text editor where you can query the Google Fonts catalog using this API. I would plan on distributing this plugin for anyone to use.
However, in order for it work, I obviously have to sign up for an API key and include that in the code for the plugin so it gets distributed also.
I know that API keys like this as not secret passwords or anything like that, but should they be distributed like this? If one was to build something like this, this seems like the only way to do it.
What happens if someday my own Google account is compromised? What if I need to refresh the API key for some random reason, etc? Then all those users of the plugin would be out of luck since the plugin is using an old key.
What is the best approach to this type of problem? I was planning on having the API key to be "editable" in the plugin so that one could use their own key if they wished, but I don't want that to be a requirement because it just creates a higher barrier to entry.
Related
Currently working on a python project, and am trying to get it usable enough to the point where I could share it with other people on platforms like reddit or github. However, I can't go sharing around the API. Is there any way to include the API key but hide it somehow so it is simultaneously usable and still hidden from any users who download my repository?
There is not a way to have an API key be shared so it's both usable and private. If you can't share the API, then you'll just have to keep it to yourself.
I've been looking through several ready-made vue components for autocompleting search using Google api. For instance this one and that one. And it seems to me that all of them let the user have an access directly to their Google Places API key (at least I can see it just in a page source of their demo sites).
Is it a right approach? How to deal with the fact that someone can take this key and quickly exceed the quota? Sorry for the naive question.
seems the best solution for the frontend only is to restrict your API key, which can be easily spoofed. Alongside other solutions that Google suggests are [link]:
Restrict your API keys
Independent API key per app
Delete API keys no longer needed
Exercise caution when regenerating keys
Monitor API key usage for anomalies
unless you could manage to implement a backend API version of it and query your backend API instead of Google API and then you could practice some solutions like rate limit on your backend API.
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.
I made a styled map in Google Maps and I needed an API key to make it work. I did it, and it workes fine if the API key is not restricted. If I restrict it on a particular IP or domain, it doesn't work, but this is not the problem I want to discuss here. I was wondering, why not leaving my key unrestricted? So i searched online and they said that a key shouldn't be unrestricted for security reasons, so they suggest to
store them in environment variables or in files outside of your application's source tree
I asked myself then, even if I put my API key in an external file, get it with php or whatever, wouldn't it be shown in the html's source code anyway? I mean, in the how-to page they say to write this code
<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap">
that's fine, but whatever is my way to set the YOUR_API_KEY, whether getting it from an external file or not, it will be shown on my html's source code anyway.
So,
does anyone know what they mean when they say to put the API key on an external file?
If i find a way to put it on an external file, can I leave it unrestricted? If so, what could happen (speeching from a security point of view)?
Leaving an API completely unrestricted is awful practice and should be avoided in almost every situation. All someone with malicious intent needs to do is find your API key and suddenly they have access to almost everything function that the API key gives you access to. Always restrict keys to the bare minimum.
Since you're going to be embedding the map into an iframe, that script is going to be run client side meaning there isn't much when it comes to hiding the API key but if you restrict a key to simply view maps (and any other functions that will be needed on the users side) there won't be any need to hide it and you can leave it in there as the docs show you.
The document you read on best practices for security with API's applies more to applications of the Google API where it is handling sensitive data or the key has access to functions that could seriously compromise the security of your application if accessed. This doesn't apply in the scenario you described with maps.
I'm currently upgrading one of my websites from the old system to HTML5 and I have some problems with the Google Maps JavaScript API v3. To fetch data from their API, you must have an key - of course - but it's here I have the problem.
The problem is that even if I have an correct key that I have added on their Google APIs Console I'm getting "Permission Denied" all the time, followed by an alert window that say that I don't have an real API key or it's not approved to Google Maps JavaScript API v3.
I have turned on "Google Maps API v3" in "Services" on Google APIs Console and payed the "bill" but that didn't help at all as proved. I'm using this URL to their API: http://maps.googleapis.com/maps/api/js?key={MY_KEY}&sensor=false and I have readed their documentions very carefully and I'm currently out of ideas.
Do you know what's wrong here? Have I missed something or what?
In the absence of a link to check...
You can have more than one Project (dropdown, top left in the Console), and each key is tied to a project. Maps v3 must be enabled for the right project.
The seqence should be:
Choose project from the dropdown (or create one)
Choose the services required by that project
Choose collaborators if any
Set up the access keys for that project. You can have more than one key per project and specify the domains the keys can be used on.
Set up billing if you need it.
The menu on the left is set out in a logical order.