node.js Everyauth 与 Passport.js？

Everyauth vs Passport.js?

提问by EhevuTov

Everyauthand Passport.jsseem 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?

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

回答by Jared Hanson

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

作为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:

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

Idiomatic Node.js

惯用的 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.

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

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.

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

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.

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

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

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

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.

这种模块化架构已证明其适应性强，促进了社区实现了对各种身份验证机制的支持，包括 OpenID、OAuth、BrowserID、SAML 等。

Flexible

灵活的

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

Passport只是中间件，使用fn(req, res, next)Connect 和 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

这意味着没有任何意外，因为您定义了您想要路由的位置以及何时想要使用身份验证。也不依赖于特定框架。人们成功地将 Passport 与其他框架（例如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.

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

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

Passport 还以一种完全传统的方式出错，紧随Express 定义的错误处理中间件。

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

相比之下，everyauth 有自己的约定，不太适合问题空间，导致#36等长期悬而未决的问题

API Authentication

接口认证

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

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

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

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

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 issuesmany 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.

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

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

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

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

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

回答by Waylon Flinn

Passport

护照

• modular and transparent
• good docs
• community contributions (owing to it's modularity)
• works with everyone and their dog (again, owing to it's modularity)

• 模块化和透明
• 好文档
• 社区贡献（由于它的模块化）
• 与每个人和他们的狗一起工作（再次，由于它的模块化）

Everyauth

每次认证

• long development history, mature.
• no longer maintained
• great docs
• works with a wide range of services

• 发展历史悠久，成熟。
• 不再维护
• 很棒的文档
• 与广泛的服务合作

回答by Gudlaugur Egilsson

Just finished changing from everyauth to passport. The reasons were the following.

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

1. Everyauth is not stable enough. The final straw was last week I got bitten by a mysterious issue where facebook authentication would work on local.host and on the production environment, but not in my test environment on heroku, even with identical code and databases and a new heroku app instance. At that point I ran out of theories as to how to isolate the issue, so removing everyauth was the logical next step.
2. The way it provides support for standard authentication using username/password credentials is not easily integrated with a single page web app approach.
3. I was unable to get everyauth to work with Google accounts.
4. Active development of everyauth seems on the decline.

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

The port was surprisingly painless, only taking a few hours, including manual testing.

端口出人意料地轻松，只需要几个小时，包括手动测试。

So obviously, I recommend going for passport.

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

回答by Paul

I tried out Everyauth first and have since gone to Passport. It struck me as somewhat more flexible, esp. if (for example) I need different logic for different providers. It also makes it easier (imo) to configure custom auth strategies. On the other hand, it doesn't have the view helpers, if those are important to you.

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

回答by machineghost

This answers a bit late, but I found this thread and (after hearing all of the negative feedback about Everyauth) decided to use Passport ... and then hated it. It was opaque, only worked as middleware (you couldn't authenticate from a GraphQL endpoint, for instance), and I hit more than one hard to debug bug (eg. How do I have two Express sessions?).

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

So I went looking and found https://github.com/jed/authom. For my needs this is a much better library! It's a bit lower-level than the other two libraries, so you have to do things like putting the user into the session yourself ... but that's only one line so it's really no big deal.

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

More importantly its design gives you a lot more control, making it easy to implement your authorization the way you want and not the way Passport intended. Plus, compared to Passport it's a lot simpler and easier to learn.

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

回答by user1441287

I used to use Everyauth more specifically mongoose-auth. I found it hard to split up my files properly without dismantling the everyauth module. Passport in my opinion is a cleaner method for creating logins. There is a write up that I found very helpful http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

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

回答by Harsh Singh

Note the date of this post, it will indicate how relevant this post is.

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

In my experience, Everyauth didn't work out of the box with it's password login style. I am using express3 and I declare my middleware like so app.use(everyauth.middleware(app));and it still wasn't passing in the everyauth local to my template. The last git commit was a year ago and I figure new packages have broken everyauth. Now I'm going to try passport.

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