Everyauth vs Passport.js?

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

Coincidiendo con mis dos centavos, como desarrollador de Passport .

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 puntos principales que quería abordar son:

Idiomatic Node.js

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

Además, creo que el uso adecuado de devoluciones de llamada y cierres produce un código conciso y bien diseñado (estilo casi funcional). Gran parte del poder de Node en sí proviene de este hecho, y Passport hace lo mismo.

Modular

Passport emplea un patrón de diseño de estrategia para definir una clara separación de preocupaciones entre el módulo central 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 e interfaces bien definidas y comprobables.

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

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

Flexible

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

Esto significa que no hay sorpresas , ya que define dónde desea 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 distribuirá una ruta y conduce a un acoplamiento estrecho con un marco específico.

Passport también comete errores de una manera totalmente convencional, junto al middleware de manejo de errores como lo define Express.

En contraste, everyauth tiene sus propias convenciones, que no se ajustan bien al espacio del problema, causando problemas abiertos de larga data como el # 36

Autenticación API

El mayor logro de cualquier biblioteca de autenticación es su capacidad para manejar la autenticación API de manera tan elegante como el inicio de sesión basado en la web.

No voy a elaborar mucho sobre este punto. Sin embargo, animo a las personas a buscar en los proyectos 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 estar completamente seguro. everyauth tiene una larga lista de problemas, muchos de los cuales permanecen abiertos y resurgen con el tiempo. En mi opinión, esto se debe a la baja cobertura de prueba de la unidad, lo que sugiere que las interfaces internas en everyauth no están definidas adecuadamente.

En contraste, las interfaces de Passport y sus estrategias están bien definidas y ampliamente cubiertas por pruebas unitarias. Los problemas presentados contra Passport tienden a ser principalmente 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 confiar en el futuro.

Pasaporte

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

Everyauth

• larga historia de desarrollo, madura.
• ya no se mantiene
• grandes documentos
• trabaja con una amplia gama de servicios

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

1. Everyauth no es lo suficientemente estable. La gota que colmó el vaso la semana pasada fue mordida por un misterioso problema en el que 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ódigos y bases de datos idénticos y una nueva instancia de aplicación heroku. En ese momento me quedé sin teorías sobre cómo aislar el problema, por lo que eliminar el 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 conseguir que everyauth funcionara con las cuentas de Google.
4. El desarrollo activo de everyauth parece estar en declive.

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

Obviamente, recomiendo ir por pasaporte.

Probé Everyauth primero y desde entonces he ido a Passport. Me pareció algo más flexible, especialmente. si (por ejemplo) necesito una 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 vista, si esos son importantes para usted.

Solía ​​usar Everyauth más específicamente mongoose-auth. Me resultó difícil dividir 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 artículo que encontré muy útil http://rckbt.me/2012/03/transition-from-mongoose-auth-to-passport/

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 (por ejemplo, no se podía autenticar desde un punto final GraphQL), y detecté más de un error difícil de depurar (por ejemplo, ¿cómo tengo dos sesiones Express? ).

Así que fui a buscar y encontré https://github.com/jed/authom . ¡Para mis necesidades, esta es una biblioteca mucho mejor! Es un poco más bajo que las otras dos bibliotecas, por lo que debe hacer cosas como poner al usuario en la sesión usted mismo ... pero esa es solo una línea, por lo que realmente 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 desea y no de la forma en que Passport pretendía. Además, en comparación con Passport, es mucho más simple y fácil de aprender.

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

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