node.js connect everyauth passport.js

node.js - Everyauth vs Passport.js?



connect (7)

Everyauth y Passport.js parecen tener conjuntos de características muy similares. ¿Cuáles son algunas de las comparaciones positivas y negativas entre las dos que me harían querer usar una sobre la otra?

Everyauth

  • un historial de desarrollo más largo, maduro.
  • excelentes documentos
  • mantenido activamente
  • trabaja con una amplia gama de servicios

Pasaporte

  • modular y transparente
  • buenos documentos
  • contribuciones de la comunidad (debido a su modularidad)
  • trabaja con todos y con su perro (nuevamente, debido a su modularidad)

Acabo de cambiar de everyauth a pasaporte. Las razones fueron las siguientes.

  1. Everyauth no es lo suficientemente estable. El colmo fue la semana pasada que me mordió un misterioso problema donde la autenticación de Facebook funcionaría en local.host y en el entorno de producción, pero no en mi entorno de prueba en heroku, incluso con código y bases de datos idénticos y una nueva instancia de aplicación heroku. En ese punto, me quedé sin teorías sobre cómo aislar el problema, por lo que quitar everyauth era el siguiente paso lógico.
  2. La forma en que proporciona soporte para la autenticación estándar utilizando credenciales de nombre de usuario / contraseña no se integra fácilmente con un enfoque de aplicación web de una sola página.
  3. No pude hacer que everyauth funcione con las cuentas de Google.
  4. El desarrollo activo de everyauth parece estar en declive.

El puerto fue sorprendentemente sencillo, solo tomó unas horas, incluidas las pruebas manuales.

Así que, obviamente, recomiendo ir por el pasaporte.

Entrando con mis dos centavos, como desarrollador de Passport.js .

Antes de desarrollar Passport, evalué everyauth y determiné que no cumplía con mis requisitos. Entonces, me puse a implementar una solución diferente que lo haría. Los principales puntos que quería abordar son:

Idiomatic Node.js

everyauth hace un uso extensivo de las promesas, en lugar del enfoque de Node de utilizar devoluciones de llamadas y cierres. Las promesas son un enfoque alternativo para la programación asincrónica. Si bien es útil en algunas situaciones de alto nivel, no me sentía cómodo con una biblioteca de autenticación que forzaba esta opción en mi aplicación.

Además, considero que el uso adecuado de devoluciones de llamadas y cierres produce un código conciso y bien estructurado (estilo casi funcional). Gran parte del poder de Node en sí proviene de este hecho, y Passport sigue su ejemplo.

Modular

Passport emplea un patrón de diseño de estrategia para definir una clara separación de preocupaciones entre el módulo principal y varios mecanismos de autenticación. Esto tiene una serie de beneficios, que incluyen un tamaño de código general más pequeño y interfaces bien definidas y comprobables.

Para una ilustración básica, compare la diferencia entre la ejecución del $ npm install passport $ npm install everyauth . Passport le permite crear su aplicación utilizando solo las dependencias que realmente necesita.

Esta arquitectura modular ha demostrado ser adaptable, lo que facilita una comunidad que ha implementado soporte para una amplia variedad de mecanismos de autenticación, incluidos OpenID, OAuth, BrowserID, SAML, etc.

Flexible

Passport es solo middleware , utilizando la convención fn(req, res, next) establecida por Connect y Express.

Esto significa que no hay sorpresas , ya que define dónde quiere sus rutas y cuándo desea usar la autenticación. Tampoco hay dependencias en un marco específico. Las personas están usando Passport con éxito con otros marcos como Flatiron

Por el contrario, cualquier módulo en everyauth puede insertar rutas en su aplicación. Esto puede dificultar la depuración, ya que no es obvio cómo se enviará una ruta y conduce a un acoplamiento estrecho con un marco específico.

Pasaporte también los errores de una manera que es totalmente convencional, junto con el middleware de error-handling definido por Express.

Por el contrario, everyauth tiene sus propias convenciones, que no encajan bien en el espacio problemático, causando problemas abiertos de larga data como #36

Autenticación API

El logro más destacado de cualquier biblioteca de autenticación es su capacidad para manejar la autenticación API tan elegantemente como el inicio de sesión basado en web.

No elaboraré mucho sobre este punto. Sin embargo, animo a las personas a investigar los proyectos de hermanos de Passport, OAuthorize y OAuth2orize . Con estos proyectos, puede implementar la autenticación de "pila completa", tanto para aplicaciones web basadas en sesión / HTML como para clientes API.

De confianza

Finalmente, la autenticación es un componente crítico de una aplicación, y uno en el que desea confiar plenamente. everyauth tiene una larga lista de issues muchos de los cuales permanecen abiertos y resurgen con el tiempo. En mi opinión, esto se debe a la baja cobertura de la prueba unitaria, lo que a su vez sugiere que las interfaces internas en everyauth no están adecuadamente definidas.

Por el contrario, las interfaces de Passport y sus estrategias están bien definidas y ampliamente cubiertas por pruebas unitarias. Issues presentan en contra de Passport suelen ser solicitudes de características menores, en lugar de errores relacionados con la autenticación.

A pesar de ser un proyecto más joven, este nivel de calidad sugiere una solución más madura que es más fácil de mantener y de confianza en el futuro.

Esto responde un poco tarde, pero encontré este hilo y (después de escuchar todos los comentarios negativos sobre Everyauth) decidí usar Passport ... y luego lo odié. Era opaco, solo funcionaba como middleware (no se podía autenticar desde un punto final GraphQL, por ejemplo), y toco más de un error difícil de depurar (por ejemplo, ¿cómo tengo dos sesiones Express? ).

Entonces fui a buscar y encontré https://github.com/jed/authom . ¡Para mis necesidades esta es una biblioteca mucho mejor! Es un nivel un poco más bajo que las otras dos bibliotecas, así que tienes que hacer cosas como poner al usuario en la sesión tú mismo ... pero esa es solo una línea, así que no es gran cosa.

Lo que es más importante, su diseño le brinda mucho más control, lo que facilita la implementación de su autorización de la manera que desee y no de la manera que pretendía Passport. Además, en comparación con Passport, es mucho más simple y fácil de aprender.

Primero probé Everyauth y luego fui a Pasaporte. Me pareció algo más flexible, esp. si (por ejemplo) necesito lógica diferente para diferentes proveedores. También hace que sea más fácil (imo) configurar estrategias de autenticación personalizadas. Por otro lado, no tiene los ayudantes de visualización, si esos son importantes para usted.

Solía ​​usar Everyauth más específicamente mongoose-auth. Me resultó difícil separar mis archivos correctamente sin desmantelar el módulo everyauth. El pasaporte en mi opinión es un método más limpio para crear inicios de sesión. Hay un escrito que encontré muy útil http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

Tenga en cuenta la fecha de esta publicación, indicará qué tan relevante es esta publicación.

En mi experiencia, Everyauth no funcionó de la caja con su estilo de inicio de sesión con contraseña. Estoy usando express3 y declaro mi middleware como app.use(everyauth.middleware(app)); y todavía no estaba pasando en everyauth local a mi plantilla. El último commit de git fue hace un año y creo que los nuevos paquetes han roto everyauth. Ahora voy a probar el pasaporte.