I am new to Google Site Search and Google Custom Search and need to implement it on a large number of websites. My concern, however, is that I will be paying $100+ a year, but my API key will be exposed in the JavaScript. What prevents someone from just using my key or otherwise running up query hits and exhausting my quota?
Related
I have a site on Squarespace and I'd like to show some data from other places (E.G. the One Call API from OpenWeatherMap). It is a free API.
As far as I know, there is no way to completely secure API keys on Squarespace (unless you are using some of their listed commerce APIs. If I put the API key in any file on the site, it will be exposed, since Squarespace is frontend by definition, and frontend is not safe for API key storage.
Assuming I am only going to use an API key to a free API plan, what are the risks associated with publishing a free API key such as the OpenWeatherMap API key on a Squarespace file?
Rate limits
Given your example, I would think a risk is that OpenWeatherMap might receive too many requests with your API key and shut down your access.
Typically, free API keys are provided with rate and/or total request limits. If one or more people used your key to make requests of their own, especially using scripts at a high rate or volume, the provider might consider it abuse of their service.
Terms of use
The other thing to consider is that you might have agreed not to share the key, and to make reasonable efforts to keep it private, when you requested the key. If so, posting it where anyone could get it would be a violation of your agreement.
Likely, the only risk for you is getting temporarily or permanently blocked from using the service, but that is probably the practical extent of it.
I've looked briefly through Spotify's API documentation to try and see what exactly can be done with the API. I'm trying to do some data analysis on Spotify data, specifically on user listens / user playlists. However, as far as I can tell, the only way to uncover that information is through OAuth, and each user whose play information I desire would need to explicitly grant permission to my app to use their information. Since I am not building a user-facing app and am interested in doing mass analysis on many users at once, I don't think this would work for my purposes.
My question - is there any way to return multiple users' listening habits through a script that pulls data from Spotify using its API? Or is that possible strictly by way of an application that one user at a time gives authentication to when they load an app that uses this API?
is there any way to return multiple users' listening habits through a script that pulls data from Spotify using its API?
Spotify doesn't expose users' listening habits unless they authorized the app requesting it (I think this is what you meant when you said "through OAuth"). There's pretty big privacy reasons for not exposing users' data to the world.
I want to make a desktop application which will need to use a 3rd party REST API to get information. However, the number of requests is limited by the API Key. If I use one API key for all users, the request quota will be exhausted really fast. Now, is it standard (and legal) to make each user sign up for his/her own API key? How are API keys used in context of open-source projects?
To generate the API key, I want to make a sign up form within the application, where the user puts in his/her information and the application sends those information to the 3rd party website to get an API key. Does that sound right?
In general the use of an API is limited to the requests from one machine and not to the API key most of the time.
Again depending of the type of third party services you are using, but the requests to the service should be established by the client not the server.
For example if you want to know geographic coordinates from a specific place, but obviously you can't ask the user directly for GPS coordinates. So you implement the Google Maps Javascript Library into your app which requests the Google API for the coordinates to the human readable address and returns it to the client. This in turn sends the data to your server.
In this way your server never comes into contact with the third party service.
If you have sensitive data or data which shouldn't be manipulated by the user you have to request from your server directly of course. But take a look into the documentation of the service before hack something together which isn't in the intention of the service provider.
Never ever try to outwit a service provider. They will detect your inappropriate use and block you for all time!
I am using the standard paypal developer API (NVP) to get current inventory levels:
https://api-3t.paypal.com/nvp?METHOD=BMGetInventory&VERSION=95.0&USER=____&PWD=____&SIGNATURE=____&HOSTEDBUTTONID=_____
But, I have a concern... If the api is enabled and the key is compromised somehow, what is the worst case scenario? For example: it looks like it is possible to send payments using the API. Is there a second tier of verification of payments that happens outside the API?
I have spent around 30 minutes researching the topic without any clarity in terms of what kind of financial damage could be done if an api information is compromised.
If your PayPal API credentials are compromised then someone can make API calls on your behalf. This includes sending and/or withdrawing money from your account.
There are some ways to limit the permissions of a PayPal API credential on the pages where you set the credential up, so you might be able to create a key that is somewhat less dangerous. It has changed over time so I can't offer details; google and/or log in to your account and look.
And yes, PayPal has lots of fraud detection that it runs internally on payments, but they have no legal responsibility to figure out that your API has has been stolen and I would strongly recommend not relying on them to save your bacon in such a case.
Protect your keys, especially ones with access to your money.
I've been building an app which allows the user to search through recent (i.e. 6-9 days worth) public tweets on Twitter using the Twitter Search API.
Currently, the site is entirely public - that is, users do not need to sign in to Twitter (or even be Twitter users at all) to use my app.
However, the upcoming changes to the Twitter API have left me confused, particularly the fact it would appear that every request to Twitter's API will need to be authenticated.
My limited understanding of how Twitter's API works is that I need to authenticate my app using OAUTH, which in turn means that, if I want to continue accessing the Twitter Search API, users will need to sign in to my site before they can use the functionality related to the Search API - hence, only Twitter users will be able to use that section of my app.
Am I understanding this correctly, or is the Twitter Search API exempt from the changes? If I authenticate my app, does this mean the rate at which users can search Twitter status updates through my app is increased (or any other advantages over having non-authenticated apps)? Note that I am currently implementing a caching feature to cache related searches.
Thanks!
The changes to the Twitter API would affect your application depending on how your application works. These are the changes that you should be aware of:
All requests used to be anonymous. Now, all requests must be authenticated via OAuth.
With the old rate limits, according to my tests, you where able to make about one request per second per IP address. Now you can make 180 requests per 15 minute block per authenticated user (1 request every 5 seconds on average).
Not related, but still worth mentioning, the data that the new API returns is more similar to the data that the Streaming API returns. It's much more complete.
So, according to these changes, if your application uses some kind of a bot which polls the Search API, stores the results into a database, and then your users search within these stored results; you will have to implement OAuth with your own access token, which you can get by creating an application at dev.twitter.com.
But, if your application connects to the Search API every time that your users interact with it, and you think that you will have to make more than one request every 5 seconds on average, then you will have to ask your users to authenticate in order to get their access tokens for your requests.