EveryauthとPassport.jsの機能セットは非常に似ているようです。どちらか一方をもう一方よりも使用したいと思わせる2つの間の正と負の比較にはどのようなものがありますか？
回答:
Passportの開発者として、私の2セントを利用しました。
Passportを開発する前に、私はeveryauthを評価し、それが私の要件を満たしていないと判断しました。だから、私はそうする別のソリューションを実装することに着手しました。私が対処したかった主なポイントは次のとおりです。
慣用的なNode.js
everyauthは、コールバックとクロージャーを使用するNodeのアプローチの代わりに、promiseを広範囲に使用します。プロミスは非同期プログラミングの代替アプローチです。いくつかの高レベルの状況では便利ですが、アプリケーションにこの選択を強制する認証ライブラリには満足できませんでした。
さらに、コールバックとクロージャを適切に使用すると、簡潔でよく設計された（ほぼ機能的なスタイル）コードが生成されることがわかります。Node自体の力の多くはこの事実から来ており、Passportも同様です。
基本単位
Passportは、戦略設計パターンを使用して、コアモジュールとさまざまな認証メカニズムの間の懸念の明確な分離を定義します。これには、全体的なコードサイズの縮小、明確に定義されたテスト可能なインターフェイスなど、多くの利点があります。
基本的な説明のため、実行しているとの違いを比較$ npm install passportし、を$ npm install everyauth。Passportでは、実際に必要な依存関係のみを使用してアプリケーションを作成できます。
このモジュール式アーキテクチャは、それ自体が適応可能であることが証明されており、OpenID、OAuth、BrowserID、SAMLなどを含むさまざまな認証メカニズムのサポートを実装したコミュニティを促進しています。
フレキシブル
Passportは単なるミドルウェアであり、fn(req, res, next)Connect and Expressによって確立された規則を使用しています。
これは、ルートをどこに置き、いつ認証を使用するかを定義するので、驚くことではないことを意味します。特定のフレームワークへの依存関係もありません。人々はPassironをFlatironのような他のフレームワークでうまく使っています
対照的に、everyauthのどのモジュールでもルートをアプリケーションに挿入できます。ルートがどのようにディスパッチされるかは明らかではなく、特定のフレームワークとの密結合につながるため、これはデバッグを困難にする可能性があります。
Passportは、Expressで定義されているエラー処理ミドルウェアに次ぐ、完全に従来の方法でエラーを発生させます。
対照的に、everyauthには独自の規則があり、問題の領域にうまく適合しないため、＃36などの長期にわたる未解決の問題が発生します。
API認証
すべての認証ライブラリの最高の成果は、Webベースのサインオンと同じくらいエレガントにAPI認証を処理できることです。
この点については詳しく説明しません。ただし、Passportの兄弟プロジェクトであるOAuthorizeとOAuth2orizeを調べることをお勧めします。これらのプロジェクトを使用すると、HTML /セッションベースのWebアプリとAPIクライアントの両方に「フルスタック」認証を実装できます。
信頼性のある
最後に、認証はアプリケーションの重要なコンポーネントであり、完全に信頼して使いたいものです。everyauthには問題の長いリストがあり、その多くは未解決のままであり、時間の経過とともに表面化します。私の意見では、これはユニットテストカバレッジが低いことが原因であり、それ自体がeveryauthの内部インターフェイスが適切に定義されていないことを示唆しています。
対照的に、Passportのインターフェースとその戦略は明確に定義されており、単体テストで広くカバーされています。 Passportに対して提出された問題は、認証に関連するバグではなく、主にマイナーな機能要求である傾向があります。
より若いプロジェクトであるにもかかわらず、このレベルの品質は、今後の維持と信頼が容易な、より成熟したソリューションを示唆しています。
everyauthからpassportへの変更が終了しました。その理由は以下のとおりです。
移植は驚くほど簡単で、手動テストを含めて数時間しかかかりませんでした。
ですから、パスポートに行くことをお勧めします。
私はEveryauthを最初に試し、それ以来Passportに行きました。それはやや柔軟で、特に私を襲った。（たとえば）プロバイダーごとに異なるロジックが必要な場合。また、カスタム認証戦略の構成が簡単になります（imo）。一方、ビューヘルパーが重要である場合、ビューヘルパーはありません。
以前はEveryauth、より具体的にはmongoose-authを使用していました。私は、everyauthモジュールを分解せずにファイルを適切に分割するのが難しいことに気付きました。私の考えでは、パスポートはログインを作成するためのよりクリーンな方法です。私が非常に役に立ったと思った記事がhttp://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/にあります
これは少し遅れて返答しますが、私はこのスレッドを見つけ、（Everyauthに関するすべての否定的なフィードバックを聞いた後）Passportを使用することを決定しました...それからそれを嫌っていました。これは不透明で、ミドルウェアとしてのみ機能し（たとえば、GraphQLエンドポイントから認証できませんでした）、デバッグが難しい複数のバグにヒットしました（たとえば、2つのExpressセッションを使用するにはどうすればよいですか？）。
だから私は探しに行って、https：//github.com/jed/authomを見つけました。私のニーズでは、これははるかに優れたライブラリです！これは他の2つのライブラリよりも少しレベルが低いので、ユーザーを自分でセッションに入れるなどのことを行う必要があります...しかし、これは1行だけなので、大したことはありません。
さらに重要なことに、その設計により、より多くの制御が可能になり、Passportが意図した方法ではなく、希望する方法で承認を簡単に実装できるようになります。さらに、Passportと比較すると、習得がはるかに簡単で簡単です。