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.
Related
it looks like if I'd like to enable key restrictions for Android and iOS app the only way is to use Application restrictions with 1 key being used on both platforms?
I'm having 1 Google Maps Key being used on Android and iOS, and what I can find in the GCP -> APIs and services -> Credentials, is the choice between one of those, I can't select both platforms.
Would it be correct? If yes, then it'd be better to create 2 separated keys rather than limiting on the Application restrictions level? My application is React Native with react-native-maps package for Google Maps and it's quite natural to use 1 codebase, also 1 API key.
It's technical also possible to use 2 keys*, but next time when releasing on Web and Desktop, I'll need to use yet another keys. Eventually, ending up with 4, instead of 1, which simplifies key management.
*I'll only need to change the reference to a different variable https://github.com/tamotam-com/tamotam-app/blob/master/ios/TamoTam/AppDelegate.m#L36 and/or https://github.com/tamotam-com/tamotam-app/blob/master/android/app/src/main/AndroidManifest.xml#L20
API security best practices
"API keys are required for apps and projects that use the Google Maps Platform APIs and SDKs. For maximum security and minimal effort, secure your API keys when you create them.
While it is possible to secure API keys after they're created and in use, there can be different constraints based on how the key is used. Updating or replacing keys in mobile apps (Android and iOS) are the most complicated, since the keys won't all be replaced until all customers update their apps. Updating or replacing keys in JavaScript or Web Service apps are much more straightforward, but updating or replacing these keys still may require careful planning and fast work."
It is considered as best practice when you Use seperate API keys for each app
The reason would be because:
"This limits the scope of each key. If an API key is compromised, you can delete or regenerate the impacted key without needing to update your other API keys."
Simplified key management could cost you security. So having 4 keys instead of 1, is still better most especially if your key was compromised.
Hope this helps.
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 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.
I have used google map API but unfortunately I have discovered that they have an usage limits so I want to know that are there anyway o get an google map API without any usage limits, and if it is not how can I get any license?
Google maps api usage and limits
Do I need an API key?
Answer: in the early days of google maps you did not require an API key (it is still possible to not have one due to backwards compatibility) however, today, it is recommended that you generate an API key for google maps V3. Also, have in mind that some features are not available without the API key.
If you want to inform your self more about the API key, here is the official page that will tell you how to get started with it and how to include it to your project,
url: https://developers.google.com/maps/documentation/javascript/tutorial
What are the usage limits?
Answer: If your site gets 25 000 map loads or more every single day, for more than 90 days in a row, the google team will get in touch with you (they are well aware of your google maps usage). If however you don't think your google maps will generate such an amount of traffic then do the following:
Modify your application so that your usage is less than 25 000 map loads per day.
Enroll for automated billing of excess map loads in the Google Developers Console.
Purchase a Google Maps API for Work license.
Here is the official page for the limits,
url: https://developers.google.com/maps/documentation/javascript/usage#quota
To sum it all up:
If you can predict huge traffic on your website (and using the google maps API within your website), then once again, read carefully the docs and see what further steps need to be taken, otherwise you can experiment with google maps as much as you want.
I have a website that revolves around transactions between two users. Each user needs to agree to the same terms. If I want an API so other websites can implement this into their own website, then I want to make sure that the other websites cannot mess with the process by including more fields in between or things that are irrelevant to my application. Is this possible?
If I was to implement such a thing, I would allow other websites to use tokens/URLs/widgets that would link them to my website. So, for example, website X wants to use my service to agree user A and B on the same terms. Their page will have an embedded form/frame which would be generated from my website and user B will also receive an email with link to my website's page (or a page of website X with a form/frame generated from my server).
Consider how different sites use eBay to enable users to pay. You buy everything on the site but when you are paying, either you are taken to ebay page and come back after payment, or the website has a small form/frame that is directly linked to ebay.
But this is my solution, one way of doing it. Hope this helps.
It depends on how your API is implemented. It takes considerably more work, thought, and engineering to build an API that can literally take any kind of data or to build an API that can take additional, named, key/value pairs as fields.
If you have implemented your API in this manner, then it's quite possible that users of this API could use it to extend functionality or build something slightly different by passing in additional data.
However, if your API is built to where specific values must be passed and these fields are required, then it becomes much more difficult for your API to be used in a manner that differs from what you originally intended.
For example, Google has many different API's for different purposes, and each API has a very specific number of required parameters that a developer must use in order to make a successful HTTP request. While the goal of these API's are to allow developers to extend functionality, they do allow access to only very specific pieces of data.
Lastly, you can use authentication to prevent unauthorized access to your API. The specific implementation details depend largely on the platform you're working with as well as how the API will be used. For instance, if users must login to use services provided by your API, then a form of OAuth may suffice. However, if other servers will consume your API, then the authorization will have to take place in the HTTP headers.
For more information on API best practices, see 7 Rules of Thumb When You Build an API, and a slideshow from a Google Engineer titled How to Design a Good API and Why That Matters.