Ich stimme mit meinen zwei Cent als Entwickler von Passport überein .
Vor der Entwicklung von Passport habe ich jeden bewertet und festgestellt, dass es nicht meinen Anforderungen entspricht. Also machte ich mich daran, eine andere Lösung zu implementieren, die dies tun würde. Die wichtigsten Punkte, die ich ansprechen wollte, sind:
Idiomatic Node.js
Everyauth nutzt Versprechen in großem Umfang, anstatt Node's Rückrufe und Schließungen zu verwenden. Versprechen sind ein alternativer Ansatz zur asynchronen Programmierung. Obwohl ich in einigen Situationen auf hoher Ebene nützlich war, war ich mit einer Authentifizierungsbibliothek nicht zufrieden, die diese Auswahl meiner Anwendung aufzwang.
Darüber hinaus finde ich, dass die ordnungsgemäße Verwendung von Rückrufen und Schließungen einen präzisen, gut strukturierten (fast funktionalen) Code liefert. Ein Großteil der Macht von Node selbst beruht auf dieser Tatsache, und Passport folgt diesem Beispiel.
Modular
Passport verwendet ein Strategieentwurfsmuster, um eine klare Trennung der Bedenken zwischen dem Kernmodul und verschiedenen Authentifizierungsmechanismen zu definieren. Dies hat eine Reihe von Vorteilen, einschließlich einer geringeren Gesamtcodegröße und gut definierter und testbarer Schnittstellen.
Vergleichen Sie zur Veranschaulichung den Unterschied zwischen Laufen $ npm install passportund $ npm install everyauth. Mit Passport können Sie Ihre Anwendung nur mit den tatsächlich benötigten Abhängigkeiten erstellen.
Diese modulare Architektur hat sich als anpassungsfähig erwiesen und ermöglicht einer Community, die Unterstützung für eine Vielzahl von Authentifizierungsmechanismen implementiert hat, einschließlich OpenID, OAuth, BrowserID, SAML usw.
Flexibel
Passport ist nur Middleware und verwendet die fn(req, res, next)von Connect und Express festgelegte Konvention.
Dies bedeutet, dass es keine Überraschungen gibt , da Sie definieren, wo Sie Ihre Routen möchten und wann Sie die Authentifizierung verwenden möchten. Es gibt auch keine Abhängigkeiten von einem bestimmten Framework. Menschen verwenden Passport erfolgreich mit anderen Frameworks wie Flatiron
Im Gegensatz dazu kann jedes Modul in jeder Datei Routen in Ihre Anwendung einfügen. Dies kann das Debuggen erschweren, da es nicht offensichtlich ist, wie eine Route versendet wird, und zu einer engen Kopplung mit einem bestimmten Framework führt.
Passport weist auch Fehler auf eine völlig konventionelle Weise auf, neben der von Express definierten Middleware zur Fehlerbehandlung .
Im Gegensatz dazu hat everyauth seine eigenen Konventionen, die nicht gut in den Problembereich passen und zu langjährigen offenen Problemen wie # 36 führen
API-Authentifizierung
Die Krönung jeder Authentifizierungsbibliothek ist ihre Fähigkeit, die API-Authentifizierung so elegant wie die webbasierte Anmeldung zu handhaben.
Ich werde auf diesen Punkt nicht viel näher eingehen. Ich ermutige die Leute jedoch, sich die Geschwisterprojekte von Passport, OAuthorize und OAuth2orize , anzuschauen . Mit diesen Projekten können Sie die "Full-Stack" -Authentifizierung sowohl für HTML- / sitzungsbasierte Webanwendungen als auch für API-Clients implementieren.
Zuverlässig
Schließlich ist die Authentifizierung eine wichtige Komponente einer Anwendung, auf die Sie sich voll und ganz verlassen können. Everyauth hat eine lange Liste von Themen, von denen viele offen bleiben und im Laufe der Zeit wieder auftauchen. Meiner Meinung nach ist dies auf eine geringe Abdeckung durch Unit-Tests zurückzuführen, was darauf hindeutet, dass die internen Schnittstellen in jedem Auto nicht angemessen definiert sind.
Im Gegensatz dazu sind die Schnittstellen und Strategien von Passport klar definiert und werden durch Unit-Tests umfassend abgedeckt. Bei Passport eingereichte Probleme sind in der Regel eher geringfügige Funktionsanforderungen als Fehler im Zusammenhang mit der Authentifizierung.
Obwohl es sich um ein jüngeres Projekt handelt, deutet dieses Qualitätsniveau auf eine ausgereiftere Lösung hin, die in Zukunft einfacher zu warten und vertrauenswürdig ist.