views:

30

answers:

1

I'm working on an API wrapper for Viddler, which will eventually be made public, and I'm trying to figure out the best way to deal with authentication/API keys, specifically with usage within Rails applications in mind.

The easiest way to write the wrapper would be to just have the code create a new client each time, and the developer could store the API key in a constant for future use:

@client = Viddler::Client.new(VIDDLER_API_KEY)

The problem with this is, it's kind of clunky to have to keep creating client objects and passing in the API key. This gets even more complicated when you throw user authentication into the mix.

I'm thinking some sort of solution where I all the the API key to be set in the environment file and then the authentication would be done in a before_filter.

Viddler::Client.api_key = 'abc123'
Viddler::Client.authenticate! 'username', 'password'

Viddler::Client would then store this in a class variable, and you could call Viddler::Client.new without any parameters and make authenticated calls. One thing I'd be concerned about is that this means the developer would have to be sure to clear out the authentication before or after each request, since the class variables would persist between requests.

Any thoughts?

+1  A: 

Storing the API key globally would for sure be pretty useful and certainly is the way to go for that kind of information. User authentication on the other hand I think shouldn't be stored globally, never ever, especially for a high level API, because telling your users to "ensure to add an after_filter :reset_viddler_auth" might lead to some unexpected security risks.

# in a config/initializer/*.rb file or something
Viddler::Client.api_key = "abc123"

# in the controller/action/model/wherever
@client = Viddler::Client.new # anonymous
@client.authenticate!("username", "password") # authenticate anon client

@client_auth = Viddler::Client.new("username", "password") # authenticated client

Guess like that you've best of both worlds :) Maybe even provide a way to create a new client with another API key like,

@client_other = Viddler::Client.new("username", "password", :api_key => "xyz890")

So... just my 2 cents.

PS: not sure how up-to-date it is, but there's already a ruby viddler wrapper, just FYI, http://viddler.rubyforge.org/rdoc/

lwe
Thanks for your response! One thing I should have mentioned in the original question is that I'm also going to be building a model based wrapper as well, so you could do this sort of thing: `Viddler::Video.find_by_username('kyleslat')`. This makes a call to the `viddler.videos.getByUser` call, which *can* be authenticated or not. Either I need to have some sort of global session (`Viddler::Client.session` or something, which has the issues you mentioned), or I pass along the client/session somehow, like `Viddler::Video.find_by_username('kyleslat', @client)`.
Kyle Slattery
And about the other wrapper--I'm actually an employee at Viddler, and the existing wrapper is fairly out of date, so we've decided to build an official one ourselves.
Kyle Slattery
mhh, so you wan't to make it like the AR APIs which is certainly nice... of course you could add a global session object (like the connection in AR), but to be honest - unexperienced users might use your API wrong (i.e. not clear the session information or similar). how about `Viddler::Video.find_by_username('kyleslat', @session)`, or `Viddler::Session.authorized('user', 'pass') do .... end`, like transactions so to speak, also take a look at other Ruby APIs how they tackle the problem.PS: Looking forward to playing around with your API :)
lwe
PS: don't store the session object globally - ever :) wasn't clear enough on that point before.Take a look at the Twitter API, or octopi. To keep the AR-style how about: `@client.videos.find_by_username()`, but calls should really always be scoped to the session.
lwe
Ooh, I really like the `@client.videos.find_by_username()` idea! I think I'll go with that. Unfortunately, I probably won't be able to release the client for a couple months, since it's using the newest version of the API, which we're still testing. I'll definitely try to remember to come back and post a comment when it's released, though :)
Kyle Slattery
would be great :)
lwe