123

EveryauthとPassport.jsの機能セットは非常に似ているようです。どちらか一方を使用したくなるような、2 つの肯定的な比較と否定的な比較にはどのようなものがありますか?

4

7 に答える 7

192

Passportの開発者として、私の 2 セントでチャイムを鳴らします。

Passport を開発する前に、everyauth を評価し、要件を満たしていないと判断しました。そこで、別のソリューションの実装に着手しました。私が対処したかった主なポイントは次のとおりです。

慣用的な Node.js

コールバックとクロージャを使用する Node のアプローチの代わりに、everyauth は promise を広範囲に使用します。Promise は、非同期プログラミングの代替アプローチです。高レベルの状況では便利ですが、アプリケーションにこの選択を強制する認証ライブラリには満足できませんでした。

さらに、コールバックとクロージャを適切に使用すると、簡潔で適切に設計された (ほとんど関数型の) コードが得られることがわかりました。Node 自体のパワーの多くはこの事実に由来しており、Passport もそれに続きます。

基本単位

Passport は戦略設計パターンを採用して、コア モジュールとさまざまな認証メカニズムの間の懸念事項を明確に分離します。これには、全体的なコード サイズの縮小や、明確に定義されたテスト可能なインターフェイスなど、多くの利点があります。

$ npm install passport基本的な図として、runningとの違いを比較し$ npm install everyauthます。Passport を使用すると、実際に必要な依存関係のみを使用してアプリケーションを作成できます。

このモジュラー アーキテクチャは適応性があることが証明されており、OpenID、OAuth、BrowserID、SAML などを含むさまざまな認証メカニズムのサポートを実装したコミュニティを促進しています。

フレキシブル

Passport は単なるミドルウェアfn(req, res, next)であり、 Connect と Express によって確立された規約を使用しています。

これは、ルートが必要な場所と認証をいつ使用するかを定義するため、驚きがないことを意味します. 特定のフレームワークへの依存もありません。人々は、 Flatironなどの他のフレームワークで Passport を使用して成功しています。

対照的に、everyauth の任意のモジュールは、ルートをアプリケーションに挿入できます。これにより、ルートがどのようにディスパッチされるかが明確ではなく、特定のフレームワークとの密結合につながるため、デバッグが困難になる可能性があります。

Passport はまた、Express によって定義されたエラー処理ミドルウェアに続いて、完全に従来の方法でエラーを発生させます。

対照的に、everyauth には独自の規則があり、問題領域にうまく適合せず、#36などの長年にわたる未解決の問題を引き起こしています。

API 認証

認証ライブラリの最高の成果は、API 認証を Web ベースのサインオンと同じくらいエレガントに処理できることです。

この点についてはあまり詳しく説明しません。ただし、Passport の兄弟プロジェクトであるOAuthorizeとOAuth2orizeを調べることをお勧めします。これらのプロジェクトを使用すると、HTML/セッションベースの Web アプリと API クライアントの両方に「フルスタック」認証を実装できます。

信頼性のある

最後に、認証はアプリケーションの重要なコンポーネントであり、完全に信頼できるものにしたいものです。everyauth には問題の長いリストがあり、その多くは未解決のままであり、時間の経過とともに再浮上します。私の意見では、これは単体テストのカバレッジが低いためであり、それ自体が everyauth の内部インターフェースが適切に定義されていないことを示唆しています。

対照的に、Passport のインターフェイスとその戦略は明確に定義されており、単体テストによって広範囲にカバーされています。 Passport に対して提出された問題は、認証に関連するバグではなく、マイナーな機能の要求である傾向があります。

若いプロジェクトであるにもかかわらず、このレベルの品質は、保守が容易で信頼できる、より成熟したソリューションを示唆しています。

于 2012-08-15T23:01:38.587 に答える
21

パスポート

  • モジュール式で透過的
  • 良いドキュメント
  • コミュニティへの貢献 (モジュール性による)
  • みんなと彼らの犬で動作します（これもモジュール性のためです）

エブリオース

  • 長い開発履歴、成熟。
  • 維持されなくなった
  • 素晴らしいドキュメント
  • 幅広いサービスで動作します
于 2012-08-15T19:43:07.167 に答える
16

everyauthからpassportへの変更が完了しました。その理由は以下のとおりです。

  1. Everyauth は十分に安定していません。最後のストローは先週、facebook 認証が local.host と実稼働環境では機能するという謎の問題に悩まされましたが、同じコードとデータベースと新しい heroku アプリ インスタンスを使用しても、heroku のテスト環境では機能しませんでした。その時点で、問題を特定する方法についての理論を使い果たしたので、すべての認証を削除することが論理的な次のステップでした。
  2. ユーザー名/パスワード資格情報を使用した標準認証のサポートを提供する方法は、単一ページの Web アプリ アプローチと簡単に統合できません。
  3. everyauth を Google アカウントで動作させることができませんでした。
  4. everyauth の積極的な開発は衰退しているようです。

移植は驚くほど簡単で、手動テストを含めて数時間しかかかりませんでした。

ですから、パスポートをお勧めします。

于 2013-05-26T22:49:14.190 に答える
5

最初に Everyauth を試してから、Passport に移行しました。特に、やや柔軟に感じました。（たとえば）プロバイダーごとに異なるロジックが必要な場合。また、カスタム認証戦略の構成が簡単になります (imo)。一方、それらが重要な場合、ビューヘルパーはありません。

于 2012-08-15T19:40:14.080 に答える
3

これは少し遅れて答えますが、私はこのスレッドを見つけ、(Everyauth に関するすべての否定的なフィードバックを聞いた後) Passport を使用することに決めました ...そして嫌いになりました。不透明で、ミドルウェアとしてしか機能せず (たとえば、GraphQL エンドポイントから認証できなかった)、デバッグが困難なバグが複数ありました (たとえば、2 つの Express セッションを使用するにはどうすればよいですか? )。

だから私は探しに行き、https://github.com/jed/authomを見つけました。私のニーズにとって、これははるかに優れたライブラリです! 他の2つのライブラリよりも少しレベルが低いので、自分でユーザーをセッションに入れるなどの作業を行う必要があります...しかし、それは1行だけなので、本当に大したことではありません.

さらに重要なことは、その設計により、より多くの制御が可能になり、Passport が意図した方法ではなく、必要な方法で承認を簡単に実装できるようになることです。さらに、Passport と比較すると、はるかにシンプルで簡単に習得できます。

于 2018-02-14T02:10:46.273 に答える
1

この投稿の日付に注意してください。この投稿の関連性が示されます。

私の経験では、Everyauth はそのままではパスワード ログイン スタイルでは機能しませんでした。私はexpress3を使用しており、ミドルウェアをそのように宣言してapp.use(everyauth.middleware(app));いますが、まだテンプレートにローカルのeveryauthを渡していませんでした。最後の git commit は 1 年前で、新しいパッケージが everyauth を壊したと思います。さっそくパスポートを試してみます。

于 2013-04-06T19:55:58.280 に答える