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!
Related
As you may know the BLPAPI core developer guide (https://data.bloomberglp.com/professional/sites/10/2017/03/BLPAPI-Core-Developer-Guide.pdf) is not very intuitive and I was not able find a way to connect and authenticate without using the Bloomberg Anywhere Application.
I'm currently looking to develop an application that will run automatically on its own everyday at a specific time and would like to have this application to authenticate itself with Bloomberg and connect to the API.
Many thanks.
Justin, authenticating against the BLP API requires one of a few options to be in place. If you're only considering something around the Bloomberg (Professional) Terminal then you need to have a valid 'token' in place. When you light up a Bloomberg Terminal it creates a token and makes a BLP API 'delivery point' available on localhost:8194. When you log out of the Terminal the token remain valid and then delivery point remains intact. The token gets invalidated in two circumstances, either timeout (not even sure it will last overnight), and, the Bloomberg user logging in somewhere else (including on the Bloomberg phone app).
I should also say, that your application use case is constrained by licensing, in that you can only write display applications (as defined by exchange rules).
What some Bloomberg customers resort to if they have challenges around 24/7 applications, and, only have Bloomberg Terminals, is that they buy something called a Server API (SAPI). It allows a client/server pattern to be developed whereby the server portion can login in with its own credentials (application name), and, the client portion authenticates with the Terminal token/user. So, you could write the server component collecting data 24/7 but only delivers the analytics/results, etc when the Bloomberg Terminal users logs in.
If you're looking for something a little more systematic/autonomous then as a customer you should look at the Bloomberg Enterprise products such as B-PIPE, where the above need not apply, and you have a much more liberal accommodation of patterns.
As with all things finance, the devil is in the detail.. and depending on whether you're looking at exchange traded data or OTC, various rules and fees will apply.
Good luck
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.
We are extending our analytic coverage to include actions on our Desktop apps for Windows and Mac OSX.
The Google Measurement Protocol is simple enough to use:
https://developers.google.com/analytics/devguides/collection/protocol/v1/
Is there a way that we can extract the existing Google client-id, that is, the id generated by Google and generally stored in a cookie on the computer that uniquely and anonymously identifies the client?
For clarity - you would typically use Javascript to extract it in a web-page as follows;
https://developers.google.com/analytics/devguides/collection/analyticsjs/cookies-user-id?hl=en#getting_the_client_id_from_the_cookie
How do you do the same using a language such as Swift or Objective-C on OS X, or MFC/C++ on Windows.
The client id is generated by the Javascript tracking code (or the SDK respectively). So if you use the measurement protocol there is no pre-existing client id that you could extract.
The good news is that you can generate your own. Google Analytics isn't critical w/r/t what it accepts as client id, any string will do - however to serve it's intended purpose it must be unique, so a UUID is recommended.
The best way to do this would be to use the User ID feature of Google Analytics. This feature lets you send your own ID instead of using the randomly generated Client ID (that is stored in a cookie).
So if the user visits your website and identifies themselves (e.g. logs in), then you would sent their "customer ID" using the User ID feature. Then, if that user goes on to install your desktop application and also identifies themselves (by logging in again), then you would use the measurement protocol to send the same "customer ID". You would do this by using the &uid measurement protocol parameter. Google Analytics will then identify this as the same user an you will basically get x-device behaviour in GA. This will allow you to figure out that campaign A drove a website visit as well as an eventual desktop app download.
Let's say I need to implement a callback service on a website.
I'm curious if it's possible to develop it using Twilio.
For example, if a website visitor provides his mobile phone number from one side, from another side I have a manager using his web CRM application. Is it possible to:
Make a call (using WebRTC?) to a manager
When the manager replies the incoming call, call to the website visitor (on his mobile phone)
Connect both sides together
I know there are lots of ready-to-use callback services, I'm just curious how it works under the hood.
Twilio developer evangelist here.
This is a feature we call Click to Call. Here's how it would work with Twilio:
The visitor provides his number through a form on the site
Generate a call to the manager using the Twilio REST API
When the call connects to the manager, dial the visitor.
This is achieved using TwiML
Whent the call connects, Twilio makes an HTTP request to a URL you provide in step 2
That URL needs to respond with TwiML, which is a subset of XML to tell Twilio what to do with the call
In this case the TwiML would be to <Dial> the visitors number
When the visitor answers the two are connected
This is a high level view of it, we also have a tutorial walking you through Click to Call with Twilio (this is the Python version, but there are others available too) which I recommend you take a look at.
Let me know if this helps at all.
I'm having trouble deciding on / understanding which method of authentication would be best in the following situation:
I have 3 separate "clients". A website, mobile app and browser extension.
Users information and data is stored in a database.
The 3 clients will access the data via an API.
What I am trying to get my head around is how users of the system would login via one of the three clients and authenticate with the API so they can then proceed to get and post data to the API.
I do not require 3rd party applications to access the API. Users can only access it by logging into the clients I provide. For this reason am I right in thinking that OAuth1/2 would be over kill?
I have attached an image which details how I envision the system.
An additional question:
Where is it in the system the authentication comes in? Would I authenticate within the API? So the user uses a form on one of the three clients to send a password. The API then returns a "what" if they provide valid credentials?