Everyauth vs Passport.js？
Everyauth と Passport.js は非常に類似した機能セットを持っているようです。どちらか一方を使用したいと思う2つの間の正と負の比較のいくつかは何ですか？
パスポート の開発者として、私の2セントに賛成です。
Passportを開発する前に、everyauthを評価し、要件を満たしていないと判断しました。それで、私はそうするであろう別のソリューションを実装することを設定しました。対処したかった主なポイントは次のとおりです。
慣用的なNode.js
everyauthは、コールバックとクロージャーを使用するNodeのアプローチの代わりに、promiseを広範囲に使用します。約束は、非同期プログラミングの代替アプローチです。いくつかの高レベルの状況では役立ちますが、アプリケーションにこの選択を強制する認証ライブラリには不安がありました。
さらに、コールバックとクロージャーを適切に使用すると、簡潔で適切に設計された（ほぼ機能的なスタイルの）コードが得られることがわかりました。 Node自体の力の多くはこの事実に由来しており、Passportも同様です。
モジュラー
Passportは、戦略設計パターンを採用して、コアモジュールとさまざまな認証メカニズムとの間の懸念を明確に分離します。これには、全体的なコードサイズの縮小、明確に定義されたテスト可能なインターフェイスなど、多くの利点があります。
基本的な説明として、_$ npm install passport_と_$ npm install everyauth_の実行の違いを比較してください。 Passportでは、実際に必要な依存関係のみを使用してアプリケーションを作成できます。
このモジュラーアーキテクチャは、適応性があり、OpenID、OAuth、BrowserID、SAMLなどのさまざまな認証メカニズムのサポートを実装したコミュニティを促進します。
フレキシブル
Passportは単なるミドルウェアであり、Connect and Expressによって確立されたfn(req, res, next)規則を使用します。
これは、ルートの場所と認証の使用時期を定義するときに、サプライズがないことを意味します。特定のフレームワークへの依存もありません。人々は Flatiron などの他のフレームワークでPassportを正常に使用しています
対照的に、everyauthのモジュールは、アプリケーションにルートを挿入できます。これによりデバッグが難しくなります。ルートがどのようにディスパッチされるかは明らかではなく、特定のフレームワークとの密結合につながるためです。
また、パスポートは、Expressで定義されている error-handling ミドルウェアに次ぐ、完全に従来的な方法でエラーが発生します。
対照的に、everyauthには独自の規則があり、問題空間にうまく適合せず、 ＃36 などの長年の未解決の問題が発生します。
API認証
認証ライブラリの最高の成果は、Webベースのサインオンと同じくらいエレガントにAPI認証を処理できることです。
この点についてはあまり詳しく説明しません。ただし、Passportの兄弟プロジェクト OAuthorize および OAuth2orize を検討することをお勧めします。これらのプロジェクトを使用して、HTML /セッションベースのWebアプリとAPIクライアントの両方に「フルスタック」認証を実装できます。
信頼性のある
最後に、認証はアプリケーションの重要なコンポーネントであり、完全に安心して使用したいものです。 everyauthには issues の長いリストがあり、その多くは開いたままであり、時間の経過とともに表面化します。私の意見では、これはユニットテストのカバレッジが低いためであり、それ自体がeveryauthの内部インターフェイスが適切に定義されていないことを示唆しています。
対照的に、Passportのインターフェイスとその戦略は、明確に定義されており、ユニットテストで幅広くカバーされています。 問題 Passportに対して提出されたものは、認証に関連するバグではなく、ほとんどがマイナーな機能要求である傾向があります。
より若いプロジェクトであるにもかかわらず、このレベルの品質は、今後の保守と信頼がより容易な、より成熟したソリューションを示唆しています。
パスポート
- モジュール式で透明
- 良いドキュメント
- コミュニティの貢献（モジュール性のおかげ）
- すべての人と犬と一緒に動作します（これもモジュール方式のため）
Everyauth
- 成熟した長い開発履歴。
- もはや維持されていません
- 素晴らしいドキュメント
- 幅広いサービスで動作します
Everyauthからパスポートへの変更が完了しました。その理由は次のとおりです。
- Everyauthは十分に安定していません。最後のストローは先週、face.auth認証がlocal.Hostと本番環境で機能するという不思議な問題に噛まれましたが、同じコードとデータベース、新しいherokuアプリインスタンスでも、herokuのテスト環境では機能しません。その時点で、問題を切り分ける方法についての理論を使い果たしたため、everyauthを削除することが論理的な次のステップでした。
- ユーザー名/パスワード資格情報を使用した標準認証のサポートを提供する方法は、単一ページのWebアプリのアプローチと簡単に統合できません。
- EveryauthをGoogleアカウントで動作させることができませんでした。
- Everyauthの積極的な開発は減少しているようです。
ポートは驚くほど簡単で、手動テストを含めて数時間しかかかりませんでした。
だから明らかに、私はパスポートに行くことをお勧めします。
私は最初にEveryauthを試し、それ以来Passportに行きました。それは、特にやや柔軟性が高いと思いました。 （たとえば）プロバイダーごとに異なるロジックが必要な場合。また、カスタム認証戦略を簡単に構成できます（imo）。一方、ビューヘルパーが重要な場合、ビューヘルパーはありません。
これは少し遅れて答えますが、私はこのスレッドを見つけ、（Everyauthについてのすべての否定的なフィードバックを聞いた後）Passportを使用することに決めました...そしてそれを嫌っていました。それは不透明で、ミドルウェアとしてのみ機能し（たとえば、GraphQLエンドポイントから認証できませんでした）、デバッグが難しいバグを複数ヒットしました（例： 2つのExpressセッションがあるのですか？ =）。
だから私は探しに行きました https://github.com/jed/authom 。私のニーズにとって、これははるかに優れたライブラリです！他の2つのライブラリよりも少し低レベルなので、ユーザーを自分でセッションに入れるなどの作業を行う必要がありますが、それは1行だけなので、大したことではありません。
さらに重要なことは、その設計により、より多くの制御が可能になり、Passportが意図した方法ではなく、希望する方法で認証を簡単に実装できるようになることです。さらに、Passportと比較すると、はるかにシンプルで簡単に習得できます。
私はEveryauth、より具体的にはmongoose-authを使用していました。 everyauthモジュールを分解せずにファイルを適切に分割するのは難しいと感じました。私の意見では、パスポートはログインを作成するためのよりクリーンな方法です。私が非常に役立ったと思う記事があります http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/
この投稿の日付に注意してください。この投稿の関連性が示されます。
私の経験では、Everyauthはパスワードログインスタイルではすぐに機能しませんでした。私はexpress3を使用しており、ミドルウェアをapp.use(everyauth.middleware(app));のように宣言していますが、テンプレートのeveryauthローカルで渡されていません。最後のgitコミットは1年前であり、新しいパッケージがeveryauthを破損していると思います。今、私はパスポートを試すつもりです。