Node.js: Connect-Auth VS. EveryAuth

node express api boilerplate

Question

¿Alguien puede dar una buena comparación entre: https://github.com/ciaranj/connect-auth y https://github.com/bnoguchi/everyauth

Las que parecen ser las únicas opciones para express / connect

Answer 1

Mi experiencia con cada uno:

everyauth es mucho más configurable. Por ejemplo, deseo manejar mis propias sesiones. Con everyauth , con su modularidad e introspección, una tarea sencilla. Por otro lado, hemos encontrado todos los errores llenos de errores menores y documentación incompleta o incorrecta. Para mí, cada estrategia de autenticación ha requerido su propia comprensión y solución de problemas.

passport podría ser una buena apuesta si está haciendo todo "por el libro". Pero cualquier desviación podría hacer la vida muy difícil muy rápidamente, por lo que, para mí , no es un motor de arranque.

Answer 2

Pasé una mañana jugando con everyauth y mongoose-auth para encontrar que los ejemplos estaban en quiebra y que eran proyectos muertos. Aquí están las historias de cometer:

https: // github.com/jaredhanson/passport/commits/master - 5 de junio (es el 18 de junio) https: // github.com/ciaranj/connect-auth/commits/master - 18 de abril (hace 2 meses) https: // github.com/bnoguchi/mongoose-auth/commits/master - febrero de 2012

Aquí hay un Google Trends de everyauth, connect-auth y passportjs http://www.google.com/trends/explore?q=passportjs%2C+connect-auth%2C+everyauth#q=passportjs%2C%20connect-auth%2C%20everyauth&cmpt=q

Answer 3

Pensé en mencionar que ahora hay un nuevo jugador en la ciudad llamado PassportJS que presenta muchos de los mismos beneficios que todos los proveedores de autenticación, sin embargo, los módulos de npm brindan los proveedores de npm, por lo tanto optin en lugar de incluir todo.

Answer 4

Soy el autor de everyauth .

Escribí everyauth porque encontré el uso de connect-auth en términos de:

1. Configuración fácil y potente.

   Para concretar, un área donde faltaba en términos de configuración era establecer dinámicamente la configuración de seguridad de "alcance" de Facebook.

2. Buen soporte de depuración

   Encontré que connect-auth no es tan sencillo de depurar en términos de localizar la parte del proceso de autenticación que estaba fallando. Esto se debe principalmente a la forma en que connect-auth configura sus devoluciones de llamada anidadas.

Con everyauth, intenté crear un sistema que resolviera los problemas que encontré con connect-auth.

• En la configuración : cada módulo de autenticación de everyauth se define como una serie de pasos y parámetros configurables. Como resultado, tiene una precisión similar a la cirugía sobre qué parámetros (por ejemplo, nombre de host, url de devolución de llamada, etc.) o pasos (por ejemplo, getAccessToken, addToSession) que desea modificar. Con connect-auth , si desea cambiar una cosa además de los pocos parámetros configurables incorporados que proporciona cada estrategia de autenticación, debe volver a escribir toda la función this.authenticate que define la lógica de toda esa estrategia. En otras palabras, tiene menos precisión de configurabilidad que everyauth . En otros casos, no puede usar connect-auth , tal como está, por ejemplo, logrando una configuración de "alcance" de facebook dinámica, es decir, pedir a los usuarios más permisos de facebook progresivamente a medida que llegan a partes de su aplicación que requieren más permisos.

  Además de los pasos y parámetros configurables, también puede aprovechar la herencia del módulo de autenticación de everyauth . Todos los módulos se heredan prototípicamente del módulo de autenticación de todos los módulos. Todos los módulos basados ​​en OAuth2 heredan del módulo oauth2. Digamos que quiere que todos los módulos oauth2 se comporten de manera diferente. Todo lo que necesita hacer es modificar el módulo de autenticación oauth2, y todos los módulos basados ​​en oauth2 heredarán ese nuevo comportamiento.

• Sobre la depuración : everyauth , en mi opinión, tiene una mejor visibilidad de la depuración debido al hecho de que segmenta cada módulo explícitamente en los pasos de los que está compuesto. Configurando

  everyauth.debug = true;

  obtienes información sobre los pasos que se han completado en el proceso de autenticación y cuáles han fallado. También tiene control granular sobre cuánto tiempo tiene cada paso en cada estrategia de autenticación antes de que se agote el tiempo.

• Sobre la extensibilidad : diseñé Everyauth para maximizar la reutilización del código. Como se mencionó anteriormente, todos los módulos heredan prototípicamente del módulo de autenticación de todos los módulos. Esto significa que puede lograr sistemas muy modulares y al mismo tiempo tener un control preciso en términos de superar un paso específico de un módulo ancestral. Para ver lo fácil que es extender Everyauth con su propio módulo de autenticación, simplemente eche un vistazo a cualquiera de los módulos de autenticación específicos en la fuente de Everyauth.

• Sobre la legibilidad : me parece que everyauth fuente es más fácil de leer en términos de lo que está sucediendo. Con connect-auth , me encontré saltando alrededor de varios archivos para comprender en qué contextos (es decir, durante qué pasos, en todos los everyauth ) se everyauth cada devolución de llamada anidada configurada por una estrategia. Con everyauth , usted sabe exactamente qué parte de la lógica está asociada con qué contexto (también conocido como paso). Por ejemplo, aquí está el código que describe lo que sucede cuando un proveedor oauth2 redirige a su servicio:

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

  Sin necesidad de explicar cómo funciona esto, es bastante sencillo ver lo que hace una estrategia oauth2. ¿Quieres saber qué hace getCode? La fuente de nuevo es muy sencilla:

  .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;
  })

  Compare todo esto con el código de Facebook de connect-auth , que para mí al menos me tomó más tiempo del que pensé que debía tener para averiguar qué se ejecuta cuando. Esto se debe principalmente a la forma en que el código se distribuye en los archivos y al uso de un único método de authenticate y devoluciones de llamadas anidadas para definir la lógica de autenticación ( everyauth utilizan promesas para dividir la lógica en pasos fáciles de digerir):

  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);
  }
  }

Algunas otras diferencias :

• everyauth admite la everyauth tradicional basada en contraseña. connect-auth , a partir de este escrito, no lo hace.
• El soporte de foursquare y google en connect-auth se basa en la especificación OAuth1.a más antigua. everyauth foursquare y google de everyauth se basan en sus implementaciones de la nueva especificación OAuth2.
• Soporte de everyauth en todos los everyauth .
• La documentación de everyauth es mucho más completa que la de connect-auth.

Finalmente, para comentar sobre la respuesta de Nathan, que no estaba segura de que everyauth los proveedores everyauth múltiples proveedores al mismo tiempo, everyauth admiten múltiples proveedores concurrentes. El README en la página de github de everyauth proporciona instrucciones sobre cómo usar everyauth para lograr esto.

Para concluir, creo que la elección de las bibliotecas depende del desarrollador. Yo, y otros, encontramos a everyauth más poderosos desde su punto de vista. Como ilustra la respuesta de Nathan, otros encuentran que connect-auth más sintonizado con sus preferencias. Sea cual sea su elección, espero que este artículo sobre por qué escribí everyauth ayude en su decisión.

Answer 5

Ambas bibliotecas son bastante cercanas en cuanto a conjuntos de características, especialmente en términos de proveedores compatibles. connect-auth brinda asistencia inmediata para que usted pueda hacer sus propios proveedores de oAuth, de modo que eso podría ayudarlo si va a necesitar ese tipo de cosas.

Lo principal que he notado entre los dos es que me parece que connect-auth mucho más limpio con la forma en que crea y acepta el middleware; solo tiene que mirar la cantidad de preconfiguración requerida para el middleware en todos los everyauth para ver que se va a ensuciar.

Otra cosa que no está clara es si everyauth admite múltiples proveedores al mismo tiempo; con connect-auth , parece posible / más sencillo, aunque todavía no lo he probado.