Everyauth vs Passport.js?

Everyauth e Passport.js parecem ter conjuntos de recursos muito semelhantes. Quais são algumas das comparações positivas e negativas entre as duas que me fazem querer usar uma sobre a outra?

Conversando com meus dois centavos, como desenvolvedor do Passport .

Antes de desenvolver o Passport, avaliei tudo e determinei que ele não atendia aos meus requisitos. Então, comecei a implementar uma solução diferente que seria. Os principais pontos que eu queria abordar são:

Idiomatic Node.js

everyauth faz uso extensivo de promessas, em vez da abordagem do Node de usar retornos de chamada e fechamentos. As promessas são uma abordagem alternativa à programação assíncrona. Embora útil em algumas situações de alto nível, não me senti à vontade com uma biblioteca de autenticação forçando essa escolha no meu aplicativo.

Além disso, acho que o uso adequado de retornos de chamada e fechamentos gera código conciso e bem arquitetado (estilo quase funcional). Grande parte do poder do Node vem desse fato, e o Passport segue o exemplo.

Modular

O Passport emprega um padrão de design de estratégia para definir uma clara separação de preocupações entre o módulo principal e vários mecanismos de autenticação. Isso tem vários benefícios, incluindo tamanho geral menor do código e interfaces bem definidas e testáveis.

Para uma ilustração básica, compare a diferença entre execução $ npm install passporte$ npm install everyauth . O Passport permite que você crie seu aplicativo usando apenas as dependências realmente necessárias.

Essa arquitetura modular provou ser adaptável, facilitando uma comunidade que implementou suporte para uma ampla variedade de mecanismos de autenticação, incluindo OpenID, OAuth, BrowserID, SAML, etc.

Flexível

O passaporte é apenas middleware , usando a fn(req, res, next)convenção estabelecida pelo Connect e Express.

Isso significa que não há surpresas , pois você define onde deseja suas rotas e quando deseja usar a autenticação. Também não há dependências em uma estrutura específica. As pessoas estão usando o Passport com sucesso com outras estruturas, como o Flatiron

Por outro lado, qualquer módulo em tudo pode inserir rotas no seu aplicativo. Isso pode dificultar a depuração, pois não é óbvio como uma rota será despachada e leva a um acoplamento rígido com uma estrutura específica.

O Passport também erros de uma maneira totalmente convencional, próximo ao middleware de tratamento de erros, conforme definido pelo Express.

Por outro lado, everyauth tem suas próprias convenções, que não se encaixam bem no espaço do problema, causando problemas abertos de longa data, como # 36

Autenticação de API

A principal conquista de qualquer biblioteca de autenticação é sua capacidade de lidar com a autenticação da API de maneira tão elegante quanto a conexão baseada na Web.

Não vou elaborar muito sobre esse ponto. No entanto, incentivo as pessoas a olharem para os projetos irmãos do Passport, OAuthorize e OAuth2orize . Usando esses projetos, você pode implementar a autenticação "pilha completa", para aplicativos Web baseados em HTML / sessão e clientes API.

Confiável

Por fim, a autenticação é um componente crítico de um aplicativo e você deseja se sentir totalmente confortável em confiar. everyauth tem uma longa lista de problemas, muitos dos quais permanecem abertos e ressurgem com o tempo. Na minha opinião, isso se deve à baixa cobertura do teste de unidade, o que sugere que as interfaces internas em todos os itens não estão definidas adequadamente.

Por outro lado, as interfaces do Passport e suas estratégias são bem definidas e amplamente cobertas por testes de unidade. Os problemas arquivados no Passport tendem a ser principalmente solicitações menores de recursos, em vez de erros relacionados à autenticação.

Apesar de ser um projeto mais jovem, esse nível de qualidade sugere uma solução mais madura, mais fácil de manter e confiar no futuro.

Passaporte

• modular e transparente
• bons documentos
• contribuições da comunidade (devido à sua modularidade)
• trabalha com todo mundo e seu cachorro (novamente, devido à sua modularidade)

Everyauth

• longa história de desenvolvimento, madura.
• não é mais mantido
• ótimos documentos
• trabalha com uma ampla gama de serviços

Acabei de mudar de tudo para passaporte. Os motivos foram os seguintes.

1. Everyauth não é estável o suficiente. O problema final foi na semana passada, fui mordido por um problema misterioso em que a autenticação do facebook funcionava no local.host e no ambiente de produção, mas não no meu ambiente de teste no heroku, mesmo com códigos e bancos de dados idênticos e uma nova instância de aplicativo heroku. Nesse ponto, fiquei sem teorias sobre como isolar o problema, então remover tudo era o próximo passo lógico.
2. A maneira como fornece suporte para autenticação padrão usando credenciais de nome de usuário / senha não é facilmente integrada a uma abordagem de aplicativo da web de página única.
3. Não consegui que tudo funcionasse com as Contas do Google.
4. O desenvolvimento ativo de tudo parece estar em declínio.

A porta era surpreendentemente indolor, levando apenas algumas horas, incluindo testes manuais.

Então, obviamente, eu recomendo ir para passaporte.

Experimentei o Everyauth primeiro e depois fui para o Passport. Pareceu-me um pouco mais flexível, esp. se (por exemplo) eu precisar de uma lógica diferente para diferentes provedores. Também facilita (imo) configurar estratégias de autenticação personalizadas. Por outro lado, ele não possui os auxiliares de exibição, se forem importantes para você.

Eu costumava usar o Everyauth mais especificamente mongoose-auth. Achei difícil dividir meus arquivos corretamente, sem desmontar o módulo everyauth. O passaporte, na minha opinião, é um método mais limpo para criar logins. Existe uma redação que achei muito útil http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

Isso responde um pouco tarde, mas eu encontrei esse tópico e (depois de ouvir todo o feedback negativo sobre o Everyauth) decidiu usar o Passport ... e depois o odiei. Era opaco, funcionava apenas como middleware (você não podia se autenticar a partir de um ponto de extremidade do GraphQL, por exemplo), e eu acertei mais de um bug difícil de depurar (por exemplo, como eu tenho duas sessões Express? ).

Então fui procurar e encontrei https://github.com/jed/authom . Para minhas necessidades, esta é uma biblioteca muito melhor! É um pouco mais baixo do que as outras duas bibliotecas, então você precisa fazer coisas como colocar o usuário na sessão ... mas isso é apenas uma linha, portanto não é grande coisa.

Mais importante ainda, seu design oferece muito mais controle, facilitando a implementação de sua autorização da maneira que você deseja e não da maneira que o Passport pretendia. Além disso, comparado ao Passport, é muito mais simples e fácil de aprender.

Observe a data desta postagem, ela indicará o quão relevante é essa postagem.

Na minha experiência, Everyauth não funcionou imediatamente com seu estilo de login com senha. Estou usando o express3 e declaro meu middleware assim app.use(everyauth.middleware(app));e ele ainda não estava sendo transmitido no local everyuth para o meu modelo. O último commit do git foi há um ano e eu acho que novos pacotes quebraram tudo. Agora vou tentar o passaporte.