Node.js:Connect Auth VS.EveryAuth_Node.js

Node.js:Connect Auth VS.EveryAuth

node.js

Node.js:Connect Auth VS.EveryAuth,node.js,Node.js,有人能很好地比较一下：及这似乎是/的唯一选项，这两个库在功能集上非常接近，特别是在受支持的提供者方面connectauth提供了开箱即用的支持来创建自己的oAuth提供程序，因此，如果您需要这种东西，它可以很好地帮助您在这两者之间我注意到的主要一点是，我发现connectauth创建和接受中间件的方式更加简洁；您只需在everyauth中查看中间件所需的预配置量，就可以看出它会变得一团糟另一件不清楚的事情是everyauth是否同时支持多个提供者；使用connectauth，这似乎是可能

有人能很好地比较一下：及

这似乎是/

的唯一选项，这两个库在功能集上非常接近，特别是在受支持的提供者方面

connectauth

提供了开箱即用的支持来创建自己的oAuth提供程序，因此，如果您需要这种东西，它可以很好地帮助您

在这两者之间我注意到的主要一点是，我发现

connectauth

创建和接受中间件的方式更加简洁；您只需在

everyauth

中查看中间件所需的预配置量，就可以看出它会变得一团糟

另一件不清楚的事情是

everyauth

是否同时支持多个提供者；使用

connectauth

，这似乎是可能的/更简单，尽管我自己还没有尝试过。

我是

everyauth

的作者

我写了

everyauth

，因为我发现使用

connectauth

缺乏以下方面：

简单而强大的配置

具体来说，它在可配置性方面缺乏的一个方面是动态设置facebook的“范围”安全设置

良好的调试支持

我发现

connectauth

在确定auth进程失败的部分方面，调试起来并不那么简单。这主要是由于connect auth设置其嵌套回调的方式

使用everyauth，我尝试创建一个系统来解决使用connect auth遇到的问题

关于配置-每个everyauth auth模块都定义为一系列步骤和可配置参数。因此，对于需要更改的参数（例如主机名、回调url等）或步骤（例如getAccessToken、addToSession），您具有外科手术般的精确度。使用
```
connect auth
```
，除了每个auth策略提供的几个内置可配置参数外，如果您想更改一件事，则必须重新编写整个
```
this.authenticate
```
函数，该函数定义了所有该策略的逻辑。换句话说，它的可配置性精度不如
```
everyauth
```
。在其他情况下，您不能按原样使用
```
connect auth
```
——例如，实现动态facebook“scope”可配置性——即，当用户访问您的应用程序中需要更多权限的部分时，逐步要求用户获得更多facebook权限
除了可配置的步骤和参数外，您还可以利用
```
everyauth
```
的auth模块继承。所有模块都从everymodule auth模块继承原型。所有基于OAuth2的模块都继承自OAuth2模块。假设您希望所有oauth2模块的行为都不同。您所需要做的就是修改oauth2身份验证模块，所有基于oauth2的模块都将从中继承新的行为
关于调试-
```
在我看来，everyauth
```
具有更好的调试可视性，因为它将每个模块明确地划分为其组成的步骤。通过设置
```
everyauth.debug = true;
```
您将获得身份验证过程中哪些步骤已完成，哪些步骤已失败的输出。您还可以对每个auth策略中的每个步骤在超时之前的时间进行精确控制
关于可扩展性-我设计了everyauth以最大限度地提高代码重用率。如前所述，所有模块都从everymodule auth模块继承原型。这意味着您可以实现非常模块化的系统，同时在超越祖先模块的特定步骤方面进行细粒度控制。要了解使用自己的auth模块扩展everyauth有多容易，只需查看everyauth源代码中的任何特定auth模块

关于可读性-我发现

everyauth

源代码更易于阅读。使用

connectauth

，我发现自己在几个文件中跳跃，以了解策略配置的每个嵌套回调在什么上下文下运行（即，在什么步骤中，用

everyauth

的说法）。使用

everyauth

，您可以准确地知道与哪个上下文相关联的逻辑片段（也称为步骤）。例如，下面的代码描述了oauth2提供程序重定向回您的服务时发生的情况：

.get('callbackPath',                                                                                                                                               
     'the callback path that the 3rd party OAuth provider redirects to after an OAuth authorization result - e.g., "/auth/facebook/callback"')                     
  .step('getCode')
    .description('retrieves a verifier code from the url query')                                                                                                   
    .accepts('req res')  
    .promises('code')                                                       
    .canBreakTo('authCallbackErrorSteps')
  .step('getAccessToken')
    .accepts('code')
    .promises('accessToken extra')                                                                                                                                 
  .step('fetchOAuthUser')
    .accepts('accessToken')                                                                                                                                        
    .promises('oauthUser')
  .step('getSession')
    .accepts('req')
    .promises('session')
  .step('findOrCreateUser')                                                                                                                                        
    .accepts('session accessToken extra oauthUser')                                                                                                                
    .promises('user')
  .step('compile')
    .accepts('accessToken extra oauthUser user')
    .promises('auth')
  .step('addToSession')
    .accepts('session auth')                                                                                                                                       
    .promises(null)
  .step('sendResponse')
    .accepts('res')
    .promises(null)

不需要解释它是如何工作的，很容易就可以看到oauth2策略的作用。想知道getCode做什么吗？来源同样非常简单：

.getCode( function (req, res) {
  var parsedUrl = url.parse(req.url, true);
  if (this._authCallbackDidErr(req)) {
    return this.breakTo('authCallbackErrorSteps', req, res);
  }
  return parsedUrl.query && parsedUrl.query.code;
})

将这一切与

connectauth

的facebook代码进行比较，至少对我来说，它花费了比我想象的更多的时间来确定何时执行。这主要是因为代码在文件中的传播方式，以及使用单个

authenticate

方法和嵌套回调来定义身份验证逻辑（

everyauth

使用承诺将逻辑分解为易于理解的步骤）：

还有一些不同之处：

```
everyauth
```
支持传统的基于密码的身份验证<代码>连接身份验证，在撰写本文时还没有
connect auth中的foursquare和google支持基于较旧的OAuth1。规范
```
everyauth
```
的foursquare和google模块基于较新的OAuth2规范的实现
```
everyauth
```
中的OpenId支持
everyauth的文档比connect auth的文档更全面

最后，对于Nathan不确定同时支持多个提供者的回答，

everyauth

确实支持多个并发提供者，对此进行评论。

上的自述文件
that.authenticate= function(request, response, callback) {
  //todo: makw the call timeout ....
  var parsedUrl= url.parse(request.url, true);
  var self= this;
  if( parsedUrl.query && parsedUrl.query.code  ) {
    my._oAuth.getOAuthAccessToken(parsedUrl.query && parsedUrl.query.code ,
       {redirect_uri: my._redirectUri}, function( error, access_token, refresh_token ){
         if( error ) callback(error)
         else {
           request.session["access_token"]= access_token;
           if( refresh_token ) request.session["refresh_token"]= refresh_token;
             my._oAuth.getProtectedResource("https://graph.facebook.com/me", request.session["access_token"], function (error, data, response) {
               if( error ) {
                 self.fail(callback);
               }else {
                 self.success(JSON.parse(data), callback)
               }
             })
         }
    });
  }
  else {
     request.session['facebook_redirect_url']= request.url;
     var redirectUrl= my._oAuth.getAuthorizeUrl({redirect_uri : my._redirectUri, scope: my.scope })
     self.redirect(response, redirectUrl, callback);
   }
}