Can I check an API key against some regular expression, for example if I want to use it to on an input form?
(I work at Asana)
No, we do not guarantee the format of an API key. Also, for security reasons, we discourage writing apps that solicit API keys from users. In the future we plan to improve our supported authentication mechanisms to make it easier for users to securely authenticate with apps written by developers.
Related
I know this isn't exactly a how-to question, but Linked-In Support directed me to StackOverflow when I asked them this question, and I cannot find the answer anywhere after googling/searching the forums:
Per the LinkedIn APIs Terms of Use (https://developer.linkedin.com/documents/linkedin-apis-terms-use), section E.1, second bullet point:
Don’t try to exceed or circumvent your limitations on calls and use.
This includes creating multiple Applications for identical, or largely
similar, usage (e.g., having one Application per customer). If we
believe that you have exceeded or circumvented our limitations, or if
you have tried to, we may temporarily suspend or permanently block
your access to the APIs, disable your developer account, or both.
It sounds like I'm not allowed to create multiple instances of an application. However, the nature of my software is that each of my clients gets a subdomain and runs an instance of my app on a server particular to that client. Each client thus needs their own OAuth redirect_uri, and the only solution that I can think of is to create an application for each of my clients (which are organizations and not individual users).
Does this practice violate the TOS, and if so, what's a viable alternative?
If this practice is allowed, what is the maximum number of applications (and API keys) I can create?
Thanks in advance.
Register a single client/app but add multiple RedirectURI's for that instance, one for each customer/domain. This is allowed per LinkedIn documentation by adding multiple URLs in the OAuth 2.0 Redirect URLs text area, separated by a comma:
OAuth 2.0 Redirect URLs: Comma separated list of absolute URLs allowed
for OAuth 2.0 redirections.
<context> I got frustrated yesterday and posted a flame question which was quickly (and appropriately) closed and deleted by my fellow SO cohorts. Yahoo! turned off its standard PlaceFinder API endpoint and replaced it with a paid service. That's not the part that frustrated me though, it was mostly the fact that they changed their access model to require OAuth. One of the closers of my question commented something to the effect of:
you didn't keep an eye on deprecations of API's you depend on, OAuth
is better for users, suck it up.
While I could argue the facts of my API-watching by again blaming Yahoo for having broken links when they first announced the API deprecation back in October / November of last year, I think it would be more productive to try and turn this into an intelligent question. </context>
I have used OAuth. I like OAuth. Not only does it let you authenticate users and simplify sign ons to your application, it lets you ask for authorization to access that user's data from other apps. But PlaceFinder data is not private user data. It is for known place names and global identifiers (WOE ID's) that can be shared by everyone.
This morning I gave Yahoo! BOSS GEO my credit card information and started spiking up an OAuth API consumer to test it out. I started with DotNetOpenAuth, which I have used in the past. I read through Yahoo!'s OAuth guide and created a DotNetOpenAuth.OAuth.ServiceProviderDescription instance with all of Yahoo!'s OAuth 6.1, 6.2, and 6.3 endpoint URL's. I then went about trying to figure out how to use DotNetOpenAuth.OAuth.WebConsumer to hit the PlaceFinder API and start giving money to Yahoo!.
But it didn't work. I had to overcome a lot of cognitive dissonance, and in the end, either a limitation of the popular and widely-used DotNetOpenAuth library itself or a possible misuse of OAuth. When I finally realized that the BOSS documentation was separate from the BOSS GEO documentation, and found a C# code sample that worked to consume Yahoo!'s PlaceFinder API, I discovered where all of that dissonance was coming from.
Yahoo!'s PlaceFinder API, while it uses OAuth, does not require an Access Token to get at the API's endpoints or data. When you send a PlaceFinder request, you send all of your app's information (consumer key and secret), along with the timestamp, nonce, and signature to the PlaceFinder endpoint itself. When I used OAuth in the past, these elements were sent to the 6.1 endpoint to obtain a request token. You could then use that to authenticate / authorize the user (6.2) and obtain an Access Token (6.3) to make further requests.
Here's the limitation in DotNetOpenAuth that I can't overcome so far, so if I'm being ignorant and doing it wrong here please tell me. In the sample C# code on Yahoo!'s site, they are not using DotNetOpenAuth. Instead they have an OAuthBase class that you can use to generate a nonce, timestamp, and signature. But they send empty strings for the access token and secret. I tried doing this with DotNetOpenAuth, but it won't let you construct any requests with a null or empty access token.
So the question: Is this an inappropriate use of the OAuth standard? If not, is there a limitation in the DotNetOpenAuth library that makes it impossible to send unauthorized requests to endpoints other than for a RequestToken (6.1)? If the answer to both of these is no, how could you use DotNetOpenAuth to request PlaceFinder data without having to send an access token or secret?
This is a great question. I think oAuth provides BOSS developers with two benefits
Since you sign up for BOSS once and can then use that key for multiple services, the BOSS team wanted to have the flexibility to offer more services that needed tokens in the future. Starting with oAuth right from the get go allowed that flexibility.
The team wanted to ensure that keys are not sniffed out during network communication. Since requests are signed and actual keys are not passed, we can ensure that no sniffing happens.
Regarding your question on DotNetOpenAuth, I recommend asking on the BOSS Y! group (http://tech.groups.yahoo.com/group/ysearchboss/) since we have a number of folks who have written in C#, VB.Net who can advise you. In fact it is well known that the VB.Net oAuth library (http://oauth.googlecode.com/svn/code/vbnet/oAuth.vb) has some issues with it.
There's two types of oAth that yahoo uses. One requires a key, one doesn't. You probably want the one that doesn't for general API use. Just add the secure protocol http:// -> https:// and then place /public/ in an appropriate spot of the old url like
https://somePartOfURL/public/otherPartOfURL
My question is not about FourSquare API and its functions, but about more simpler details that are not well explained on Foursquare API explanations. Thank you very much in advance if someone wants to help me with this doubts:
Foursquare API is a framework you can use to build applications for mobile devices, above of IOS and Android, so i can imagine that they have API for IOS (Objective-C) and Android (Java), right?
From API Doc: "Be sure to note that although API requests are against api.foursquare.com, OAuth token and authorization requests are against foursquare.com.". Does it mean that if i want to use FourSquare app, the users has to have an account on FourSquare?
From API Doc: "For example, if you write an iPhone application, every user who logs in with their foursquare account will be able to make up to 500 users/* requests and up to 500 venues/* requests, etc." I dont understand this sentence. Does it mean that for example, if you use an API method request like "checkins.add()", this method create two methods? one against api.foursquare.com to monitor the API limit requests, and another to your Web Application Server?
So as a question related to the third one, where do you have to store your database? is it stored on Foursquare cloud database because you are loggin there, or you have to create your own Web Service application with its own SQL database?
From API Doc: "All requests are simple GET or POST requests that return JSON or JSONP respones", so i can imagine that the Web Application Service should understand JSON. Well, my main question is, can i use Ruby on Rails to build the Web Application Service and Web Page frontend? I am seeing that there are some wrapps for RoR designed from third companies, but are not official and doesnt cover all the 2.0 API, just the ones they needed for their services.
If i want to create an app using FourSquare API, what do you advice me to use as a programming language/framework for the Web Service Application? the WSA that has to process the JSON requests and later store them on the database, interaction with users on the WebPage, etc.
i am so sorry if my questions are so simple, but i dont have any other place of this level of expertise.
thank you very very much in advance.
The API is REST/JSON based, which means that any language that can do an HTTP request and parse a string can be used. There are Java and iOS libraries available. But you could use just about anything - curl with bash would be a bit extreme but if that floats your boat...
For some of the APIs (search a venue, for example) you do not necessarily need a FourSquar OAuth user token. For others (like checkin) a FourSquare token is required. For any API calls that require a userid, your users will have to be FourSquare users and "trust" your application with their FourSquare data.
Only requests to FourSquare is counted. So if you do a single call to checkins.add() it counts as one call for the user that is doing the checkin. I wouldn't worry about the limits. As long as you're usage of the API is sensible they will not be a problem. And if they do become a problem and you're doing something extraordinarily cool, the folks at FourSquare might be sympathetic.
You have to create your own web server with your own database to store some information. The OAuth token is one. You probably want to cache venue information here for short periods as well.
Yes, your webapp will need to be able to understand JSON. Ruby has excellent JSON support - look for the json gem.
It is really difficult to suggest a language or framework without knowing what it is that you're trying to do. I wouldn't choose a framework based on the fact that you want to use FourSquare (anything will do) but rather on your experience and the unique features of your application. You mentioned RoR before - that would definitely work.
We are currently using an outdated screen scraper gem to import contacts from gmail/yahoo/etc. I want to update this to use the new OAuth based APIs so users don't have to enter their credentials on our site. I'm really intrigued by the work Plaxo is doing with Portable Contacts which Google also supports. It feels like that is a good direction for read-only access, and it is still backed by OAuth.
Are there any compelling reasons to just go with the standard OAuth API for these providers instead of going the Portable Contacts route? I'd like to know if there are strong reasons to avoid it. I'll still be using straight OAuth for the ones that don't support PC so it's not a question of development time, more one of support and confidence in the new approach.
The idea is that each OAuth implementation will be slightly different where as each Portable Contacts implementation will be the same. It's kind of like a REST API (OAuth) vs. a SOAP API (Portable Contacts --but with the same overhead as OAuth).
So you should theoretically be able to make one Portable Contacts Reader and hook it to any provider who supports it with no additional work.
In reality for now, you'll probably need to work with both Portable Contacts and OAuth-non-portable endpoints. (With most OAuth-non-portable providers hopefully moving towards Portable Contacts).
OAuth Core doesn't define either discovery (leading users to the OAuth URL which will let them authorize the resource to the consumer) or representation (informing the consumer about what authorization the token will provide). Without a spec such as Portable Contacts, these need to agreed upon ad-hoc by the consumer and provider (with discovery probably being simplified to a well-known URL). So Portable Contacts is just answering those questions once for each provider which uses them. You'll need to work out the ad-hoc answers if you want to support providers which don't, but you'll be using the same OAuth Core implementation for all of them anyway.
Portable Contacts itself builds on the OAuth Discovery spec, which seems to be expired without a replacement, unfortunately.
I'm getting started on building a REST API for a project I'm working on, and it led me to do a little research as to the best way to build an API using RoR. I find out pretty quickly that by default, models are open to the world and can be called via URL by simply putting a ".xml" at the end of the URL and passing appropriate parameters.
So then the next question came. How do I secure my app to prevent unauthorized changes? In doing some research I found a couple articles talking about attr_accessible and attr_protected and how they can be used. The particular URL I found talking about these was posted back in May of '07 (here).
As with all things ruby, I'm sure that things have evolved since then. So my question is, is this still the best way to secure a REST API within RoR?
If not what do you suggest in either a "new project" or an "existing project"scenario?
There are several schemes for authenticating API requests, and they're different than normal authentication provided by plugins like restful_authentication or acts_as_authenticated. Most importantly, clients will not be maintaining sessions, so there's no concept of a login.
HTTP Authentication
You can use basic HTTP authentication. For this, API clients will use a regular username and password and just put it in the URL like so:
http://myusername:mypass#www.someapp.com/
I believe that restful_authentication supports this out of the box, so you can ignore whether or not someone is using your app via the API or via a browser.
One downside here is that you're asking users to put their username and password in the clear in every request. By doing it over SSL, you can make this safe.
I don't think I've ever actually seen an API that uses this, though. It seems like a decently good idea to me, especially since it's supported out of the box by the current authentication schemes, so I don't know what the problem is.
API Key
Another easy way to enable API authentication is to use API keys. It's essentially a username for a remote service. When someone signs up to use your API, you give them an API key. This needs to be passed with each request.
One downside here is that if anyone gets someone else's API key, they can make requests as that user. I think that by making all your API requests use HTTPS (SSL), you can offset this risk somewhat.
Another downside is that users use the same authentication credentials (the API key) everywhere they go. If they want to revoke access to an API client their only option is to change their API key, which will disable all other clients as well. This can be mitigated by allowing users to generate multiple API keys.
API Key + Secret Key signing
Deprecated(sort of) - see OAuth below
Significantly more complex is signing the request with a secret key. This is what Amazon Web Services (S3, EC2, and such do). Essentially, you give the user 2 keys: their API key (ie. username) and their secret key (ie. password). The API key is transmitted with each request, but the secret key is not. Instead, it is used to sign each request, usually by adding another parameter.
IIRC, Amazon accomplishes this by taking all the parameters to the request, and ordering them by parameter name. Then, this string is hashed, using the user's secret key as the hash key. This new value is appended as a new parameter to the request prior to being sent. On Amazon's side, they do the same thing. They take all parameters (except the signature), order them, and hash using the secret key. If this matches the signature, they know the request is legitimate.
The downside here is complexity. Getting this scheme to work correctly is a pain, both for the API developer and the clients. Expect lots of support calls and angry emails from client developers who can't get things to work.
OAuth
To combat some of the complexity issues with key + secret signing, a standard has emerged called OAuth. At the core OAuth is a flavor of key + secret signing, but much of it is standardized and has been included into libraries for many languages.
In general, it's much easier on both the API producer and consumer to use OAuth rather than creating your own key/signature system.
OAuth also inherently segments access, providing different access credentials for each API consumer. This allows users to selectively revoke access without affecting their other consuming applications.
Specifically for Ruby, there is an OAuth gem that provides support out of the box for both producers and consumers of OAuth. I have used this gem to build an API and also to consume OAuth APIs and was very impressed. If you think your application needs OAuth (as opposed to the simpler API key scheme), then I can easily recommend using the OAuth gem.
How do I secure my app to prevent
unauthorized changes?
attr_accessible and attr_protected are both useful for controlling the ability to perform mass-assignments on an ActiveRecord model. You definitely want to use attr_protected to prevent form injection attacks; see Use attr_protected or we will hack you.
Also, in order to prevent anyone from being able to access the controllers in your Rails app, you're almost certainly going to need some kind of user authentication system and put a before_filter in your controllers to ensure that you have an authorized user making the request before you allow the requested controller action to execute.
See the Ruby on Rails Security Guide (part of the Rails Documentation Project) for tons more helpful info.
I'm facing similar questions as you at the moment because i'm also building out a REST api for a rails application.
I suggest making sure that only attributes that can be user edited are marked with attr_accessible. This will set up a white list of attributes that can be assigned using update_attributes.
What I do is something like this:
class Model < ActiveRecord::Base
attr_accessible nil
end
All my models inherit from that, so that they are forced to define attr_accessible for any fields they want to make mass assignable. Personally, I wish there was a way to enable this behaviour by default (there might be, and I don't know about it).
Just so you know someone can mass assign a property not only using the REST api but also using a regular form post.
Another approach that saves building a lot of the stuff yourself is to use something like http://www.3scale.net/ which handles keys, tokens, quotas etc. for individual developers. It also does analytics and creates a developer portal.
There's a ruby/rails plugin ruby API plugin which will apply to policies to traffic as it arrives - you can use it in conjunction with the oAuth gem. You can also us it by dropping varnish in front of the app and using the varnish lib mod: Varnish API Module.