Everyauth与Passport.js? [英] Everyauth vs Passport.js?

问题描述

Everyauth 和解决方案

以我的两分钱作为护照的开发人员. /p>

在开发Passport之前，我评估了Everyauth并确定它不符合我的要求.因此，我着手实施一个不同的解决方案.我要解决的主要问题是:

惯用Node.js

everyauth广泛使用了Promise，而不是Node使用回调和闭包的方法.承诺是异步编程的另一种方法.虽然在某些高级情况下很有用，但我对将身份验证库强加到我的应用程序上的身份验证库不满意.

此外，我发现正确使用回调和闭包可以产生简洁，结构良好(几乎功能性的样式)的代码. Node本身的大部分功能都来自这个事实，Passport也照此进行.

模块化

Passport采用一种策略设计模式来定义核心模块和各种身份验证机制之间明确的关注点分离.这有很多好处，包括较小的整体代码大小以及定义良好且可测试的接口.

有关基本说明，请比较运行$ npm install passport和$ npm install everyauth的区别.通过Passport，您可以仅使用实际需要的依赖项来制作应用程序.

事实证明，这种模块化体系结构具有适应性，可以促进社区实现对多种身份验证机制的支持，包括OpenID，OAuth，BrowserID，SAML等.

灵活

使用Connect和Express建立的fn(req, res, next)约定，

护照只是中间件.

这意味着毫无意外，因为您定义了要在哪里路由以及何时使用身份验证.也没有对特定框架的依赖.人们已经在其他框架(例如 Flatiron

)中成功使用了Passport.

相比之下，everyauth中的任何模块都可以将路由插入到您的应用程序中.这会增加调试难度，因为不清楚如何分配路由并导致与特定框架的紧密耦合.

Passport还会以完全传统的方式出错，仅次于定义的错误处理中间件通过快递.

相反，每个验证人都有其自己的约定，这些约定无法很好地适应问题空间，从而导致长期存在的未解决问题，例如 OAuthorize 和

可靠

最后，身份验证是应用程序的重要组成部分，您想完全依靠它来进行身份验证.每个验证人都有一长串问题，其中许多问题一直保持开放状态并随着时间的推移而浮出水面.在我看来，这是由于单元测试覆盖率较低，这本身表明在每个认证中的内部接口未适当定义.

相比之下，Passport的界面及其策略定义明确，并且被单元测试广泛涵盖.针对Passport提出的问题通常主要是次要功能请求，而不是与身份验证有关的错误.

尽管是一个较年轻的项目，但这种质量水平表明它是一种更成熟的解决方案，易于维护和信任.

Everyauth and Passport.js seem to have very similar feature sets. What are some of the positive and negative comparisons between the two that would make me want to use one over the other?

解决方案

Chiming in with my two cents, as the developer of Passport.

Before developing Passport, I evaluated everyauth and determined that it didn't meet my requirements. So, I set about implementing a different solution which would. The major points I wanted to address are:

Idiomatic Node.js

everyauth makes extensive use of promises, instead of Node's approach of using callbacks and closures. Promises are an alternative approach to async programming. While useful in some high-level situations, I wasn't comfortable with an authentication library forcing this choice upon my application.

Furthermore, I find that proper use of callbacks and closures yields concise, well architected (almost functional style) code. Much of the power of Node itself comes from this fact, and Passport follows suit.

Modular

Passport employs a strategy design pattern to define a clear separation of concerns between the core module and various authentication mechanisms. This has a number of benefits, including smaller overall code size and well defined and testable interfaces.

For a basic illustration, compare the difference between running $ npm install passport and $ npm install everyauth. Passport lets you craft your application using only the dependencies you actually need.

This modular architecture has proven itself adaptable, facilitating a community that has implemented support for a wide variety of authentication mechanisms, including OpenID, OAuth, BrowserID, SAML, etc.

Flexible

Passport is just middleware, using the fn(req, res, next) convention established by Connect and Express.

This means that there are no surprises, as you define where you want your routes and when you want to use authentication. There are also no dependencies on a specific framework. People are successfully using Passport with other frameworks such as Flatiron

In contrast, any module in everyauth can insert routes into your application. This can make debugging difficult, as it is non-obvious how a route will be dispatched and leads to tight coupling with a specific framework.

Passport also errors in a way that is entirely conventional, next-ing to error-handling middleware as defined by Express.

In contrast, everyauth has its own conventions, which don't fit the problem space well, causing long-standing open issues such as #36

API Authentication

The crowning achievement of any authentication library is its ability to handle API authentication as elegantly as web-based sign on.

I won't elaborate much on this point. However, I encourage people to look into Passport's sibling projects, OAuthorize and OAuth2orize. Using these projects, you can implement "full-stack" authentication, for both HTML/session-based web apps and API clients.

Reliable

Finally, authentication is a critical component of an application, and one you want to be fully comfortable relying on. everyauth has a long list of issues many of which remain open and resurface over time. In my opinion, this is due to low unit test coverage, which itself suggests that the internal interfaces in everyauth are not suitably defined.

In contrast, Passport's interfaces and its strategies are well-defined and extensively covered by unit tests. Issues filed against Passport tend to mostly be minor feature requests, rather than bugs relating to authentication.

Despite being a younger project, this level of quality suggests a more mature solution that is easier to maintain and trust going forward.

这篇关于Everyauth与Passport.js?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！