Everyauth vs Passport.js?

Everyauth et Passport.js semblent avoir des ensembles de fonctionnalités très similaires. Quelles sont certaines des comparaisons positives et négatives entre les deux qui me donneraient envie d'utiliser l'une par rapport à l'autre?

Je suis venu avec mes deux cents, en tant que développeur de Passport .

Avant de développer Passport, j'ai évalué chaque auth et déterminé qu'il ne répondait pas à mes exigences. Alors, je me suis mis à mettre en œuvre une solution différente qui le ferait. Les principaux points que je voulais aborder sont:

Node.js idiomatique

everyauth fait un usage intensif des promesses, au lieu de l'approche de Node consistant à utiliser 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 à mon application.

De plus, je trouve que l'utilisation appropriée des rappels et des fermetures donne un code concis et bien structuré (style presque fonctionnel). Une grande partie de la puissance de Node lui-même vient de ce fait, et Passport fait de même.

Modulaire

Passport utilise un modèle de conception de stratégie 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 passportet $ npm install everyauth. Passport vous permet de créer votre application en utilisant uniquement les dépendances dont vous avez réellement besoin.

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

Souple

Passport n'est qu'un middleware , utilisant la fn(req, res, next)convention établie par Connect et Express.

Cela signifie qu'il n'y a pas de surprises , car vous définissez où vous voulez vos itinéraires et quand vous voulez utiliser l'authentification. Il n'y a pas non plus de dépendances sur un framework spécifique. Les gens utilisent avec succès Passport avec d'autres frameworks tels que Flatiron

En revanche, n'importe quel module de 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 conduit à un couplage étroit avec un cadre spécifique.

Passport a également des erreurs d'une manière tout à fait conventionnelle, proche du middleware de gestion des erreurs tel que défini par Express.

En revanche, everyauth a ses propres conventions, qui ne correspondent pas bien à l'espace du problème, provoquant 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 la connexion basée sur le Web.

Je ne développerai pas grand chose sur ce point. Cependant, j'encourage les gens à se pencher sur les projets frères de Passport, OAuthorize et OAuth2orize . À l'aide de ces projets, vous pouvez implémenter l'authentification «full-stack», à la fois pour les applications Web HTML / basées sur une session et les clients API.

Fiable

Enfin, l'authentification est un composant essentiel d'une application et sur lequel vous voulez vous fier pleinement. everyauth a une longue liste de problèmes dont beaucoup restent ouverts et refont surface avec le temps. À mon avis, cela est dû à une faible couverture des tests unitaires, ce qui suggère en soi que les interfaces internes de everyauth ne sont pas correctement définies.

En revanche, les interfaces de Passport et ses stratégies sont bien définies et largement couvertes par des tests unitaires. Les problèmes déposés contre 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 à faire confiance à l'avenir.

Passeport

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

Everyauth

• longue histoire de développement, mature.
• n'est plus entretenu
• grands documents
• fonctionne avec une large gamme de services

Je viens de finir de passer de Everyauth au passeport. Les raisons étaient les suivantes.

1. Everyauth n'est pas assez stable. La dernière goutte a été la semaine dernière, j'ai été mordu par un problème mystérieux où l'authentification Facebook fonctionnait sur local.host et sur 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 stade, je n'avais plus de théories sur la façon d'isoler le problème, donc la suppression de chaqueauth était la prochaine étape logique.
2. La façon dont il prend en charge l'authentification standard à l'aide d'informations d'identification de nom d'utilisateur / mot de passe n'est pas facilement intégrée à une approche d'application Web à page unique.
3. Je n'ai pas été en mesure de faire fonctionner tout le monde avec des comptes Google.
4. Le développement actif de tout le monde semble en déclin.

Le portage était étonnamment indolore, ne prenant que quelques heures, y compris les tests manuels.

Alors évidemment, je recommande d'aller pour le passeport.

J'ai d'abord essayé Everyauth et je suis depuis allé à Passport. Cela m'a semblé un peu plus flexible, en particulier. si (par exemple) j'ai besoin d'une logique différente pour différents fournisseurs. Cela facilite également (imo) la configuration de stratégies d'authentification personnalisées. D'un autre côté, il n'a pas d'aides à la vue, si celles-ci sont importantes pour vous.

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

Cela répond un peu tard, mais j'ai trouvé ce fil et (après avoir entendu tous les commentaires négatifs sur Everyauth) j'ai décidé d'utiliser Passport ... puis je l'ai détesté. Il était opaque, ne fonctionnait que comme middleware (vous ne pouviez pas vous authentifier à partir d'un point de terminaison GraphQL, par exemple), et j'ai rencontré plus d'un bogue difficile à déboguer (par exemple. Comment puis-je avoir deux sessions Express? ).

Alors je suis allé chercher et j'ai trouvé https://github.com/jed/authom . Pour mes besoins, c'est une bien meilleure bibliothèque! C'est un peu plus bas que les deux autres bibliothèques, donc vous devez faire des choses comme mettre l'utilisateur dans la session vous-même ... mais ce n'est qu'une ligne donc ce n'est vraiment pas un gros problème.

Plus important encore, sa conception vous donne beaucoup plus de contrôle, ce qui facilite la mise en œuvre de votre autorisation comme vous le souhaitez et non comme prévu par Passport. De plus, par rapport à Passport, il est beaucoup plus simple et plus facile à apprendre.

Notez la date de ce post, cela indiquera la pertinence de ce post.

D'après mon expérience, Everyauth n'a pas fonctionné immédiatement avec son style de connexion par mot de passe. J'utilise express3 et je déclare mon middleware comme tel app.use(everyauth.middleware(app));et il ne passait toujours pas dans le local everyauth à mon modèle. Le dernier commit git remonte à il y a un an et je pense que de nouveaux paquets ont tout cassé. Maintenant, je vais essayer le passeport.