Everyauth vs Passport.js?

sonnant avec mes deux cents, comme le développeur de Passeport .

avant de développer Passeport, j'ai évalué everyauth et déterminé qu'il ne répondait pas à mes exigences. Donc, j'ai commencé à mettre en œuvre une solution différente qui le ferait. Les principaux points que je voulais aborder sont les suivants:

Noeud Idiomatique.js

everyauth fait largement usage de promesses, au lieu de noeuds de approche de l'utilisation des rappels et des fermetures. Les promesses sont une approche alternative à la programmation asynchrone. Bien qu'utile dans certaines situations de haut niveau, je n'étais pas à l'aise avec une bibliothèque d'authentification forçant ce choix sur mon application.

de plus, je trouve qu'une bonne utilisation des callbacks et des fermetures donne un code concis, bien structuré (presque fonctionnel). Une grande partie de la puissance du noeud lui-même vient de ce fait, et Passeport suit.

modulaire

Passport emploie un schéma de conception stratégique pour définir une séparation claire des préoccupations entre le module central et divers mécanismes d'authentification. Cela présente un certain nombre d'avantages, notamment une taille de code globale plus petite et des interfaces bien définies et testables.

pour une illustration de base, comparez la différence entre l'exécution $ npm install passport et $ npm install everyauth . Passeport vous permet d'élaborer votre demande n'utilisez que les dépendances dont vous avez réellement besoin.

cette architecture modulaire s'est révélée adaptable, facilitant la mise en place d'une communauté qui prend en charge une grande variété de mécanismes d'authentification, dont OpenID, OAuth, BrowserID, SAML, etc.

Flexible

Passeport juste middleware , à l'aide de la fn(req, res, next) convention établi par Connecter et Express.

cela signifie qu'il y a no surprises , comme vous définissez où vous voulez vos routes et quand vous voulez utiliser l'authentification. Il n'y a pas non plus de dépendance à un cadre spécifique. Les gens utilisent avec succès passeport avec d'autres cadres tels que Flatiron

en revanche, n'importe quel module dans everyauth peut insérer des routes dans votre application. Cela peut faciliter le débogage difficile, car il est pas évident comment une route sera expédiée et conduit à un couplage serré avec un cadre spécifique.

Passeport également des erreurs d'une manière qui est entièrement conventionnelle, à côté de traitement des erreurs middleware tel que défini par Express.

en revanche, everyauth a ses propres conventions, qui ne correspondent pas bien à l'espace de problème, provoquant des questions ouvertes de longue date tels que #36

authentification API

le couronnement de n'importe quelle bibliothèque d'authentification est sa capacité à traiter l'authentification API aussi élégamment que la signature basée sur le web.

Je n'expliquerai pas grand-chose sur ce point. Cependant, j'encourage les gens à regarder dans les projets des frères et sœurs de passeport, Autoriser et Autoriser . En utilisant ces projets, Vous pouvez implémenter l'authentification "full-stack", les applications Web HTML / session et les clients API.

fiable

Enfin, l'authentification est un élément essentiel d'une application, et que vous voulez être parfaitement à l'aise en s'appuyant sur. everyauth a une longue liste de issues dont beaucoup restent ouverts et resurgissent au fil du temps. À mon avis, cela est dû à une faible couverture des tests unitaires, ce qui suggère que les interfaces internes de everyauth sont n'est pas bien défini.

en revanche, les interfaces de Passport et ses stratégies sont bien définies et largement couvertes par des tests unitaires. Questions déposée à l'encontre de Passeport ont tendance à être la plupart du temps mineur de demandes de fonctionnalités, plutôt que de bugs relatifs à l'authentification.

bien qu'étant un projet plus jeune, ce niveau de qualité suggère une solution plus mûre qui est plus facile à maintenir et la confiance aller de l'avant.