2010-07-13 3 views
2

Je travaille sur un wrapper API pour Viddler, qui sera finalement rendu public, et j'essaie de trouver la meilleure façon de traiter les clés d'authentification/API, en particulier avec l'utilisation dans les applications Rails à l'esprit.Comment gérer l'authentification d'un wrapper API Ruby?

La meilleure façon d'écrire l'emballage serait d'avoir juste le code de créer un nouveau client chaque fois, et le développeur peut stocker la clé API dans une constante pour une utilisation future:

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

Le problème avec c'est, c'est un peu maladroit de devoir continuer à créer des objets client et à passer la clé de l'API. Cela devient encore plus compliqué lorsque vous lancez l'authentification des utilisateurs dans le mixage.

Je pense à une sorte de solution où toute la clé de l'API doit être définie dans le fichier d'environnement, puis l'authentification se fera dans un before_filter.

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

Viddler::Client serait alors le stocker dans une variable de classe, et vous pourriez appeler Viddler::Client.new sans aucun paramètre et faire des appels authentifiés. Une chose qui m'inquiète, c'est que cela signifie que le développeur devra s'assurer d'effacer l'authentification avant ou après chaque requête, puisque les variables de la classe persisteront entre les requêtes.

Des pensées?

Répondre

1

Stocker la clé API globalement serait certainement très utile et c'est certainement la voie à suivre pour ce type d'information. D'autre part, l'authentification des utilisateurs ne devrait pas être stockée globalement, jamais, surtout pour une API de haut niveau, car dire à vos utilisateurs de "s'assurer d'ajouter un after_filter :reset_viddler_auth" pourrait entraîner des risques de sécurité inattendus.

# 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 

Devinez comme vous avez le meilleur des deux mondes :) Peut-être même fournir un moyen de créer un nouveau client avec une autre clé API comme,

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

... Alors que mes 2 cents .

PS: pas sûr de la mise à jour est, mais il y a déjà une enveloppe de viddler rubis, juste FYI, http://viddler.rubyforge.org/rdoc/

+0

Merci pour votre réponse! Une chose que j'aurais dû mentionner dans la question originale est que je vais également construire un wrapper basé sur un modèle, donc vous pourriez faire ce genre de chose: 'Viddler :: Video.find_by_username ('kyleslat')'. Cela appelle l'appel 'viddler.videos.getByUser', qui peut * être * authentifié ou non. Soit j'ai besoin d'avoir une sorte de session globale ('Viddler :: Client.session' ou quelque chose, qui a les problèmes que vous avez mentionnés), ou je passe le client/session en quelque sorte, comme' Viddler :: Video.find_by_username (' kyleslat ', @client) '. –

+0

Et à propos de l'autre emballage - je suis en fait un employé chez Viddler, et l'emballage existant est assez obsolète, nous avons donc décidé d'en créer un nous-mêmes. –

+0

mhh, donc vous ne voulez pas faire comme les API AR, ce qui est certainement sympa ... bien sûr, vous pouvez ajouter un objet session global (comme la connexion en AR), mais pour être honnête, les utilisateurs inexpérimentés peuvent utiliser votre API faux (c'est-à-dire ne pas effacer les informations de session ou similaires). que diriez-vous de 'Viddler :: Video.find_by_username ('kyleslat', @session)', ou 'Viddler :: Session.authorized ('user', 'pass') faire .... end', comme les transactions pour ainsi dire, Jetez également un coup d'oeil à d'autres API Ruby comment ils abordent le problème. PS: Au plaisir de jouer avec votre API :) – lwe

Questions connexes