[解決済み] EveryauthとPassport.jsの違い？

質問

常用漢字 と Passport.js は非常によく似た機能セットを持っているように見えます。この 2 つの間で、どちらかを使用したいと思わせるような肯定的および否定的な比較は何でしょうか。

どのように解決するのですか?

の開発者として、私の意見を述べさせていただきます。 パスポート .

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

自動的な Node.js

everyauthはコールバックとクロージャを使うNodeのアプローチの代わりに、プロミスを多用します。 プロミスは非同期プログラミングへの代替アプローチです。 いくつかのハイレベルな状況では有用ですが、私は認証ライブラリが私のアプリケーションにこの選択を強制することに抵抗がありました。

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

モジュラー

Passport は、コアモジュールとさまざまな認証メカニズムとの間の明確な関心の分離を定義するために、ストラテジーデザインパターンを採用しています。 これには、全体的なコードサイズを小さくし、よく定義されテスト可能なインターフェイスなど、多くの利点があります。

基本的な説明のために、Passport で $ npm install passport と $ npm install everyauth . Passportは、実際に必要な依存関係のみを使用してアプリケーションを作成することができます。

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

柔軟な

パスポートは 単なるミドルウェア を使用しています。 fn(req, res, next) を使用しています。

があることを意味します。 驚きなし のように、ルートが必要な場所や認証を使用するタイミングを定義することができます。 また、特定のフレームワークに依存することもありません。 人々は、Passportを次のような他のフレームワークとうまく組み合わせて使っています。 フラットアイアン

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

Passport はまた、まったく従来の方法でエラーを起こし、次のような エラー処理 のミドルウェアを使用します。

対照的に、everyauth は独自の規約を持っており、それは問題空間にうまく適合せず、次のような長年の未解決問題を引き起こしています。 #36

API認証

どんな認証ライブラリでも、Webベースのサインオンと同じくらいエレガントにAPI認証を扱えることが最大の功績です。

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

信頼性の高い

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

対照的に、Passport のインターフェイスとその戦略はよく定義されており、ユニットテストによって広範囲にカバーされています。 問題点 は、認証に関連するバグというよりも、むしろ小さな機能要求であることがほとんどです。

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