Everyauth vs Passport.js ?

Question

Everyauth y Passeport.js semblent avoir des caractéristiques très similaires. Quelles sont les comparaisons positives et négatives entre les deux, qui me feraient préférer l'une à l'autre ?

Answer 1

J'ajoute mon grain de sel, en tant que développeur de l'application Passeport .

Avant de développer Passport, j'ai évalué everyauth et déterminé qu'il ne répondait pas à mes exigences. J'ai donc entrepris de mettre en place une solution différente qui le ferait. Les principaux points que je voulais aborder sont :

Idiomatique Node.js

everyauth fait un usage intensif des promesses, au lieu de l'approche de Node qui utilise les callbacks et les closures. Les promesses sont une approche alternative à la programmation asynchrone. Bien qu'utiles dans certaines situations de haut niveau, je n'étais pas à l'aise avec une bibliothèque d'authentification imposant ce choix à mon application.

En outre, je trouve que l'utilisation correcte des callbacks et des closures permet d'obtenir un code concis et bien architecturé (presque de style fonctionnel). Une grande partie de la puissance de Node elle-même vient de ce fait, et Passport suit le mouvement.

Modulaire

Passport utilise un modèle de conception stratégique pour définir une séparation claire des préoccupations entre le module central et les divers mécanismes d'authentification. Cela présente un certain nombre d'avantages, notamment une réduction de la taille globale du code et des interfaces bien définies et testables.

Pour une illustration de base, comparez la différence entre la course à pied $ npm install passport y $ npm install everyauth . Passport vous permet de concevoir votre application en utilisant uniquement les dépendances dont vous avez réellement besoin.

Cette architecture modulaire s'est avérée adaptable, facilitant la tâche d'une communauté qui a mis en œuvre la prise en charge d'une grande variété de mécanismes d'authentification, notamment OpenID, OAuth, BrowserID, SAML, etc.

Flexible

Le passeport est juste un middleware en utilisant le fn(req, res, next) convention établie par Connect et Express.

Cela signifie qu'il y a pas de surprises Vous définissez vous-même l'emplacement de vos routes et le moment où vous souhaitez utiliser l'authentification. Il n'y a pas non plus de dépendance vis-à-vis d'un framework spécifique. Les gens utilisent avec succès Passport avec d'autres frameworks tels que Flatiron

En revanche, tout module d'everyauth peut insérer des routes dans votre application. Cela peut rendre le débogage difficile, car il n'est pas évident de savoir comment une route sera distribuée et cela conduit à un couplage étroit avec un framework spécifique.

Passport commet également des erreurs d'une manière tout à fait conventionnelle, à côté de Traitement des erreurs intergiciel tel que défini par Express.

En revanche, everyauth a ses propres conventions, qui ne correspondent pas bien à l'espace du problème, ce qui entraîne des problèmes ouverts de longue date tels que #36

Authentification API

Le couronnement de toute bibliothèque d'authentification est sa capacité à gérer l'authentification API aussi élégamment que l'ouverture de session sur le Web.

Je ne m'étendrai pas beaucoup sur ce point. Cependant, j'encourage les gens à regarder les projets frères de Passport, OAuthorize y OAuth2orize . Grâce à ces projets, vous pouvez mettre en œuvre une authentification "complète", à la fois pour les applications Web HTML/sessionnelles et les clients API.

Fiable

Enfin, l'authentification est un élément essentiel d'une application, sur lequel vous voulez pouvoir vous reposer en toute confiance. everyauth dispose d'une longue liste de questions dont beaucoup restent ouverts et refont surface au fil du temps. À mon avis, cela est dû à la faible couverture des tests unitaires, qui suggère elle-même que les interfaces internes d'everyauth ne sont pas définies de manière appropriée.

En revanche, les interfaces de Passport et ses stratégies sont bien définies et largement couvertes par des tests unitaires. Questions Les plaintes déposées à l'encontre de Passport sont généralement des demandes de fonctionnalités mineures, plutôt que des bogues liés à l'authentification.

Bien qu'il s'agisse d'un projet plus jeune, ce niveau de qualité suggère une solution plus mature, plus facile à maintenir et plus fiable à l'avenir.

Answer 2

Passeport

• modulaire et transparent
• de bons docteurs
• les contributions de la communauté (en raison de sa modularité)
• fonctionne avec tout le monde et son chien (encore une fois, grâce à sa modularité)

Everyauth

• longue histoire de développement, maturité.
• n'est plus maintenu
• grands docteurs
• fonctionne avec un large éventail de services

Answer 3

Je viens de terminer le passage de everyauth à passport. Les raisons étaient les suivantes.

1. Everyauth n'est pas assez stable. La goutte d'eau qui a fait déborder le vase, c'est que la semaine dernière, j'ai été confronté à un mystérieux problème où l'authentification facebook fonctionnait sur local.host et dans l'environnement de production, mais pas dans mon environnement de test sur heroku, même avec un code et des bases de données identiques et une nouvelle instance d'application heroku. À ce moment-là, je n'avais plus de théories sur la façon d'isoler le problème, et la suppression de everyauth était la prochaine étape logique.
2. La manière dont il prend en charge l'authentification standard par nom d'utilisateur/mot de passe n'est pas facile à intégrer dans une application Web à page unique.
3. Je n'ai pas réussi à faire fonctionner everyauth avec les comptes Google.
4. Le développement actif de everyauth semble sur le déclin.

Le portage a été étonnamment indolore, ne prenant que quelques heures, tests manuels compris.

Donc, évidemment, je recommande d'aller chercher le passeport.

Answer 4

J'ai d'abord essayé Everyauth et je suis depuis passé à Passport. Il m'a semblé un peu plus flexible, surtout si (par exemple) j'ai besoin d'une logique différente pour différents fournisseurs. Il est également plus facile (imo) de configurer des stratégies d'authentification personnalisées. D'un autre côté, il ne dispose pas des aides à la visualisation, si celles-ci sont importantes pour vous.

Answer 5

J'avais l'habitude d'utiliser Everyauth, plus précisément mongoose-auth. Je trouvais difficile de diviser mes fichiers correctement sans démonter le module everyauth. Passport est à mon avis une méthode plus propre pour créer des logins. Il y a un article que j'ai trouvé très utile. http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/