123

Everyauth和Passport.js似乎具有非常相似的功能集。两者之间有哪些正面和负面的比较会让我想使用其中的一个？

4

7 回答 7

192

作为Passport的开发人员，请用我的两分钱插话。

在开发 Passport 之前，我评估了everyauth 并确定它不符合我的要求。所以，我着手实施一个不同的解决方案。我想解决的主要问题是：

惯用的 Node.js

everyauth 广泛使用 Promise，而不是 Node 使用回调和闭包的方法。Promise 是异步编程的另一种方法。虽然在某些高级情况下很有用，但我对将这种选择强加于我的应用程序的身份验证库感到不舒服。

此外，我发现正确使用回调和闭包会产生简洁、架构良好（几乎是函数式风格）的代码。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 定义的错误处理中间件。

相比之下，everyauth 有自己的约定，不能很好地适应问题空间，导致长期存在的开放问题，例如#36

API 认证

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

关于这一点我不会过多阐述。但是，我鼓励人们研究 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 应用程序实例。那时我已经没有关于如何隔离问题的理论，因此删除everyauth 是合乎逻辑的下一步。
  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 端点进行身份验证），而且我遇到了不止一个难以调试的错误（例如，我如何拥有两个 Express 会话？）。

所以我去寻找并找到了https://github.com/jed/authom。对于我的需要，这是一个更好的图书馆！它比其他两个库要低一些，所以你必须自己做一些事情，比如让用户进入会话……但这只是一行，所以真的没什么大不了的。

更重要的是，它的设计为您提供了更多控制权，使您可以轻松地以您想要的方式而不是 Passport 预期的方式实施您的授权。另外，与 Passport 相比，它更简单、更容易学习。

于 2018-02-14T02:10:46.273 回答
2

我曾经更具体地说是使用 Everyauth mongoose-auth。我发现在不拆除everyauth 模块的情况下很难正确拆分我的文件。在我看来，Passport 是一种更简洁的创建登录的方法。有一篇文章我觉得很有帮助http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

于 2013-04-16T14:37:19.067 回答
1

注意这篇文章的日期，它将表明这篇文章的相关性。

以我的经验，Everyauth 的密码登录方式并不是开箱即用的。我正在使用 express3 并且我像这样声明了我的中间件app.use(everyauth.middleware(app));，但它仍然没有将 everyauth 本地传递给我的模板。最后一次 git 提交是一年前，我认为新包已经破坏了everyauth。现在我要试试护照。

于 2013-04-06T19:55:58.280 回答