Omniauth, Devise, Open ID, CanCan - Quand et quand utiliser une solution pour une application API Rails

Question

Je suis donc en train de développer une application Rails qui sert principalement d'API que je veux verrouiller sous un bon système d'autorisation. J'ai créé des applications Rails qui rendent HTML et pour cela j'ai utilisé Devise et CanCan. Cette fois je veux servir JSON à mes clients. J'ai essentiellement les exigences suivantes:

1. Besoin d'un système d'autorisation des thats robuste
2. Un utilisateur doit être en mesure de se connecter avec des applications existantes telles que Facebook, Twitter, lié et google
3. Il devrait y avoir plein pile autorisation disponible

maintenant, c'est ma 1ère application que l'écriture Im qui sert API donc je commencé à rechercher et à ce jour Ive a trouvé les solutions suivantes que les gens ont utilisé:

1. J'ai vu des gens utiliser avec CanCan
Devise
2. J'ai vu des gens parler de l'utilisation oauth2 http://railscasts.com/episodes/353-oauth-with-doorkeeper?autoplay=true
3. J'ai entendu ... « Utiliser Doorkeeper »
4. J'ai entendu utiliser. .. "Utiliser omniauth"

Donc, fondamentalement, mon premier jour de recherche m'a tout simplement confondu plus. Quand je les utilise et pour mes besoins, quelle combinaison utiliserais-je! Im luttant pour donner un sens à la soupe de l'alphabet, quelqu'un peut-il m'aider à comprendre cela

Answer 1

Devise est un moteur d'authentification pour les applications Rails de tous types. Devise permet l'authentification contre le nom d'utilisateur/mot de passe, l'authentification par jeton (bon pour les API) et un fournisseur oauth (tel que Google, Facebook et autres). Cela vous permet évidemment de refuser l'accès à l'API sauf si l'utilisateur est connecté via l'un des services que vous proposez. CanCan est un système d'autorisation qui fonctionnera au-dessus de Devise pour permettre aux utilisateurs d'accéder à certaines parties de votre système en fonction de leur rôle dans le système. CanCan a une méthode DSL très pratique qui prévoit des méthodes can et cannot pour autoriser ou refuser l'accès aux vues ou aux actions du contrôleur. Doorkeeper est un joyau fournisseur oauth si vous vouliez rouler votre propre solution oauth au-dessus de votre API. Ce serait le cas si vous vouliez que votre application agisse de la même manière que Google ou FAcebook en fournissant un point de terminaison oauth sur lequel les utilisateurs pourraient s'authentifier. D'après ce que vous avez dit plus haut, je ne pense pas que ce soit le cas. Compte tenu des exigences que vous avez énoncées ci-dessus, je crois que Devise et CanCan seraient la voie que je choisirais. Cela permettrait à l'utilisateur de s'authentifier d'abord par nom d'utilisateur/mot de passe, ou par un fournisseur oauth, puis d'autoriser l'authentification par jeton pour accéder à votre API. Vous pouvez ensuite verrouiller l'accès à des actions spécifiques via CanCan.