Everyauth与Passport.js?


Answers:


191

作为Passport的开发人员,花了我两分钱。

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

惯用Node.js

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

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

模块化的

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

对于基本说明,请比较running $ npm install passport和的区别$ npm install everyauth。通过Passport,您可以仅使用实际需要的依赖项来编写应用程序。

这种模块化体系结构已证明自身具有适应性,有助于为实现对各种身份验证机制(包括OpenID,OAuth,BrowserID,SAML等)的支持的社区提供便利。

灵活

Passport 只是中间件,使用fn(req, res, next)Connect和Express建立的约定。

这意味着您不会感到意外,因为您定义了要在哪里路由以及何时使用身份验证。也没有对特定框架的依赖。人们已经成功地将Passport与其他框架(例如Flatiron)一起使用

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

Passport还以完全传统的方式出错,仅次于Express定义的错误处理中间件。

相比之下,每个验证人都有自己的约定,这些约定不太适合问题空间,从而导致长期存在的开放性问题,例如#36

API认证

任何身份验证库的最大成就是其能够像基于Web的登录一样优雅地处理API身份验证。

在这一点上,我不会详细说明。但是,我鼓励人们研究Passport的同级项目OAuthorizeOAuth2orize。使用这些项目,您可以为基于HTML /会话的Web应用程序和API客户端实施“全栈”身份验证。

可靠

最后,身份验证是应用程序的重要组成部分,您想完全依赖于它。每个验证人都有很多问题,但随着时间的流逝,其中许多问题仍然存在。在我看来,这是由于单元测试覆盖率低而导致的,这本身表明在每个认证中的内部接口均未适当定义。

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

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


9
@EhevuTov>选择这个答案,它比我的完整得多,我同意他的观察100%。
保罗

1
@Jared Hanson:您有关于如何在RESTfull身份验证中使用护照的示例吗?
瑙尔

5
我看不到诺言如何真正改变香草回调风格所引述的好处。在一系列线性事件触发附加回调的情况下,您几乎可以用更少的代码来完成相同的事情。
Erik Reppen 2014年

1
同意@ErikReppen,在此比较中,诺言无关紧要。
vicneanschi '16

具有讽刺意味的是,但是护照现在有更多的问题:github.com/jaredhanson/passport/issues(273对148对auth而言)。
安东·贝索诺夫

19

护照

  • 模块化透明
  • 好的文档
  • 社区贡献(由于其模块化)
  • 与每个人和他们的狗一起工作(同样由于其模块化)

Everyauth

  • 发展历史悠久,成熟。
  • 不再维护
  • 很棒的文档
  • 可提供广泛的服务

1
Everyauth不再被主动维护。
YasharF

1
@YasharF感谢您告诉我。答案已经更新
Waylon Flinn

请注意,似乎也不再维护Passport。上一次进行功能提交是在2年前,有300个未解决的问题。
乌里(Uri)

16

刚刚从Everyauth更改为护照。原因如下。

  1. Everyauth不够稳定。最后一个稻草是上个星期,我被一个神秘的问题所困扰:facebook身份验证可以在local.host和生产环境上运行,但是在我的Heroku测试环境中却不能,即使使用相同的代码和数据库以及一个新的heroku应用程序实例也是如此。那时,我没有关于如何解决问题的理论,因此,删除Everyauth是合理的下一步。
  2. 它使用用户名/密码凭据为标准身份验证提供支持的方式很难与单页Web应用程序方法集成。
  3. 我无法让everyauth使用Google帐户。
  4. 每个验证的积极发展似乎正在下降。

该端口令人惊讶地无痛,仅需几个小时,包括手动测试。

所以很明显,我建议去拿护照。


尽管最后的稻草还不清楚,但感谢您的真实故事。
Andrew_1510 2014年

4

我先尝试了Everyauth,然后又去了Passport。尤其是它使我感到更加灵活。如果(例如)我需要为不同的提供程序使用不同的逻辑。它还使配置自定义身份验证策略更加容易(imo)。另一方面,如果这些视图控件对您很重要,则它没有视图助手。


我注意到Passport.js说它分散了人们的顾虑,我想知道是否每个Everyauth的构建都类似。
EhevuTov


2

答案有点晚,但是我找到了这个线程,并且(在听到了关于Everyauth的所有负面反馈之后)决定使用Passport ...然后讨厌它。它是不透明的,仅用作中间件(例如,您无法从GraphQL端点进行身份验证),而且遇到了多个难以调试的错误(例如,我如何有两个Express会话?)。

所以我去寻找并发现https://github.com/jed/authom。对于我的需求,这是一个更好的图书馆!它比其他两个库的级别低一些,因此您必须要做一些事情,例如自己将用户放入会话中……但这只是一行,所以实际上没什么大不了的。

更重要的是,它的设计为您提供了更多控制权,从而使您可以轻松按所需方式(而不是Passport预期的方式)实施授权。另外,与Passport相比,它更容易学习。


1

注意该帖子的日期,它将指示该帖子的相关性。

以我的经验,Everyauth的密码登录样式并不是开箱即用的。我正在使用express3,并且像这样声明了中间件app.use(everyauth.middleware(app));,但中间件仍未传递给模板的localauth。上一次git commit是一年前的,我认为新软件包破坏了Everyauth。现在,我要尝试护照。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.