Everyauth vs Passport.js？答案

【问题标题】：Everyauth vs Passport.js?Everyauth vs Passport.js？
【发布时间】：2012-08-12 01:57:18
【问题描述】：

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

【问题讨论】：

另一个 alternative 是使用 Grant - 只有当您正在寻找 OAuth 中间件时。它支持数百个提供程序，并通过简单的 JSON 数据结构进行配置。

标签： node.js connect everyauth passport.js

【解决方案1】：

我首先尝试了 Everyauth，然后又使用了 Passport。它让我觉得更灵活，尤其是。如果（例如）我需要为不同的提供者提供不同的逻辑。它还使配置自定义身份验证策略更容易（imo）。另一方面，它没有视图助手，如果这些对你很重要的话。

【讨论】：

我注意到 Passport.js 说它会分散关注点，我想知道是否每个身份验证都是类似的。

【解决方案2】：

护照

模块化和透明
好文档
社区贡献（由于它的模块化）
适用于每个人和他们的狗（同样，由于它的模块化）

每个身份验证

发展历史悠久，成熟。
不再维护
很棒的文档
适用于广泛的服务

【讨论】：

Everyauth 不再积极维护。
@YasharF 感谢您让我知道。答案已更新
请注意，似乎也不再维护 Passport。上一次功能性提交是在 2 年前完成的，有 300 个未解决的问题。

【解决方案3】：

作为Passport 的开发者，请与我的两分钱相提并论。

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

惯用的 Node.js

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

此外，我发现正确使用回调和闭包会产生简洁、架构良好（几乎是函数式风格）的代码。 Node 本身的大部分力量都来自这一事实，Passport 也效仿。

模块化

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

对于基本说明，比较运行$ npm install passport 和$ npm install everyauth 之间的区别。 Passport 允许您仅使用您实际需要的依赖项来制作您的应用程序。

这种模块化架构已证明自己具有适应性，有助于实现对各种身份验证机制（包括 OpenID、OAuth、BrowserID、SAML 等）的支持的社区。p>

灵活

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

这意味着没有意外，因为您可以定义您想要路由的位置以及何时要使用身份验证。也不依赖于特定的框架。人们成功地将 Passport 与其他框架一起使用，例如 Flatiron

相比之下，everyauth 中的任何模块都可以将路由插入到您的应用程序中。这可能会使调试变得困难，因为如何调度路由并导致与特定框架的紧密耦合并不明显。

Passport 也以完全传统的方式出错，仅次于 Express 定义的 error-handling 中间件。

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

API 认证

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

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

可靠

最后，身份验证是应用程序的关键组件，您希望完全放心地依赖它。 everyauth 有一个很长的issues 列表，其中许多会随着时间的推移保持开放并重新出现。在我看来，这是由于单元测试覆盖率低，这本身表明everyauth 中的内部接口没有适当定义。

相比之下，Passport 的接口及其策略定义良好，并且被单元测试广泛覆盖。针对 Passport 提出的Issues 大多是次要功能请求，而不是与身份验证相关的错误。

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

【讨论】：

@EhevuTov > 选择这个答案，它比我的要完整得多，我 100% 同意他的观察。
@Jared Hanson：你有什么例子可以说明如何将护照与 RESTfull auth 一起使用吗？
我不明白 Promise 是如何真正改变原版回调风格所引用的好处的。在一系列线性事件触发额外回调的情况下，您几乎可以用更少的代码做同样的事情。
同意@ErikReppen 的观点，在这个比较中承诺是无关紧要的。
具有讽刺意味的是，但护照现在有更多问题：github.com/jaredhanson/passport/issues（everyauth 为 273 对 148）。

【解决方案4】：

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

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

【讨论】：

【解决方案5】：

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

【讨论】：

【解决方案6】：

刚刚完成从everyauth 到passport 的更改。原因如下。

Everyauth 不够稳定。最后一根稻草是上周我被一个神秘的问题咬住了，Facebook 身份验证可以在 local.host 和生产环境上工作，但不能在我的 heroku 测试环境中工作，即使使用相同的代码和数据库以及新的 heroku 应用程序实例。那时我已经没有关于如何隔离问题的理论了，因此删除everyauth 是合乎逻辑的下一步。
它支持使用用户名/密码凭据的标准身份验证的方式不容易与单页 Web 应用程序方法集成。
我无法让everyauth 使用Google 帐户。
everyauth 的积极发展似乎正在下降。

移植过程出奇地无痛，只需要几个小时，包括手动测试。

很明显，我建议去办护照。

【讨论】：

谢谢你的真实故事，虽然最后一根稻草还不清楚。

【解决方案7】：

这个答案有点晚了，但我发现了这个帖子（在听到了关于 Everyauth 的所有负面反馈之后）决定使用 Passport ......然后讨厌它。它是不透明的，只能用作中间件（例如，您无法从 GraphQL 端点进行身份验证），而且我遇到了不止一个难以调试的错误（例如。How do I have two Express sessions?）。

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

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

【讨论】：