Everyauth против загранпаспорт.Джей?


Everyauth и паспорт.js Кажется, есть очень похожие наборы функций. Каковы некоторые из положительных и отрицательных сравнений между ними, которые заставили бы меня захотеть использовать один над другим?

7 121

7 ответов:

подхватывая мои два цента, как разработчик паспорт.

прежде чем разрабатывать паспорт, я оценил everyauth и определил, что он не соответствует моим требованиям. Итак, я приступил к реализации другого решения. Основные моменты, которые я хотел бы рассмотреть:

Идиоматическое Узел.js

everyauth широко использует обещания, а не подход узла к использованию обратных вызовов и замыканий. Обещания есть альтернативный подход к асинхронному программированию. Хотя это полезно в некоторых ситуациях высокого уровня, мне было неудобно с библиотекой аутентификации, заставляющей этот выбор в моем приложении.

кроме того, я считаю, что правильное использование обратных вызовов и замыканий дает сжатый, хорошо спроектированный (почти функциональный стиль) код. Большая часть мощности самого узла исходит из этого факта, и паспорт следует этому примеру.

модульная

паспорт использует стратегию шаблон проектирования для определения четкого разделения проблем между основным модулем и различными механизмами аутентификации. Это имеет ряд преимуществ, включая меньший общий размер кода и хорошо определенные и тестируемые интерфейсы.

для основной иллюстрации, сравните разницу между управлением $ npm install passport и $ npm install everyauth. Паспорт позволяет создавать приложение, используя только зависимости, которые вам действительно нужны.

эта модульная архитектура зарекомендовала себя адаптируемый, содействие сообществу, которое реализовало поддержку широкого спектра механизмов аутентификации, включая OpenID, OAuth, BrowserID, SAML и т. д.

гибкий

паспорт просто middleware, С помощью fn(req, res, next) конвенция, установленная Connect и Express.

Это означает, что есть никаких сюрпризов, как вы определяете, где вы хотите, чтобы ваши маршруты и когда вы хотите использовать аутентификацию. Есть также нет зависимостей от конкретной платформы. Люди успешно используют паспорт с другими фреймворками, такими как Flatiron

напротив, любой модуль в everyauth может вставлять маршруты в ваше приложение. Это может затруднить отладку, поскольку неочевидно, как будет отправлен маршрут, и приводит к плотной связи с определенной структурой.

паспорт также ошибки в пути, который является полностью обычным, рядом с обработка ошибок промежуточного программного обеспечения, как это определено выразить.

напротив, everyauth имеет свои собственные соглашения, которые не соответствуют проблемному пространству хорошо, вызывая давние открытые проблемы, такие как #36

аутентификация API

главным достижением любой библиотеки аутентификации является ее способность обрабатывать аутентификацию API так же элегантно, как и веб-вход.

Я не буду подробно останавливаться на этом вопросе. Тем не менее, я призываю людей смотреть в родственные проекты паспорта,OAuthorize и OAuth2orize. Используя эти проекты, вы можете реализовать аутентификацию "полного стека" как для HTML/сеансовых веб-приложений, так и для клиентов API.

надежный

наконец, аутентификация является важным компонентом приложения, и вы хотите, чтобы вам было полностью комфортно полагаться. everyauth имеет длинный список вопросы многие из которых остаются открытыми и выплывут со временем. На мой взгляд, это связано с низким охватом модульных тестов, что само по себе говорит о том, что внутренние интерфейсы в everyauth не определены надлежащим образом.

напротив, интерфейсы Passport и его стратегии четко определены и широко охвачены модульными тестами. вопросы поданные против паспорта, как правило, в основном являются незначительными запросами функций, а не ошибками, связанными с аутентификацией.

несмотря на то, что это более молодой проект, этот уровень качества предполагает более зрелое решение, которое легче поддерживать и доверять в будущем.

паспорт

  • модульная и прозрачный
  • хороших врачей
  • вклад сообщества (благодаря его модульности)
  • работает со всеми и их собакой (опять же, из-за его модульности)

Everyauth

  • длинная история развития, зрелая.
  • больше не поддерживается
  • хороших врачей
  • работает с широким спектром услуг

только что закончил переход от everyauth к паспорту. Причины были следующие.

  1. Everyauth не является достаточно стабильным. Последняя капля была на прошлой неделе, когда меня укусила загадочная проблема, когда аутентификация facebook будет работать на местном уровне.хост и в рабочей среде, но не в моей тестовой среде на heroku, даже с идентичным кодом и базами данных и новым экземпляром приложения heroku. В этот момент у меня закончились теории о том, как изолировать проблему, поэтому удаление everyauth был логичным следующим шагом.
  2. способ, которым он обеспечивает поддержку стандартной аутентификации с использованием учетных данных имени пользователя/пароля, нелегко интегрировать с подходом к веб-приложению на одной странице.
  3. Я не смог заставить everyauth работать с учетными записями Google.
  4. активное развитие everyauth, кажется, на спаде.

порт был удивительно безболезненным, всего за несколько часов, включая ручное тестирование.

так очевидно, Я рекомендую пойти за паспортом.

Я сначала опробовал Everyauth и с тех пор пошел в паспорт. Это показалось мне несколько более гибким, особенно. если (например) мне нужна другая логика для разных провайдеров. Это также упрощает (imo) настройку пользовательских стратегий аутентификации. С другой стороны, у него нет помощников просмотра, если они важны для вас.

Я использовал Everyauth более конкретно Мангуст-auth. Мне было трудно правильно разделить мои файлы без демонтажа модуля everyauth. Паспорт на мой взгляд является более чистым методом для создания Логинов. Есть запись, что я нашел очень полезным http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

обратите внимание на дату этого сообщения, она будет указывать, насколько актуальна эта запись.

по моему опыту, Everyauth не работал из коробки с его стилем логин пароль. Я использую express3 и объявляю свое промежуточное программное обеспечение так app.use(everyauth.middleware(app)); и он все еще не передавался в everyauth local моему шаблону. Последний git commit был год назад, и я считаю, что новые пакеты сломали everyauth. Теперь я собираюсь попробовать паспорт.

Это ответы немного поздно, но я нашел эту тему и (услышав все отрицательные отзывы о Everyauth) решил использовать паспорт ... а потом возненавидел его. Он был непрозрачным, работал только как промежуточное программное обеспечение (например, вы не могли аутентифицироваться из конечной точки GraphQL), и я ударил более чем одну трудную для отладки ошибку (например. как у меня есть две экспресс-сессии?).

поэтому я пошел искать и нашел https://github.com/jed/authom. для моих нужд это гораздо лучше библиотека! Это немного более низкий уровень, чем две другие библиотеки, поэтому вам нужно делать такие вещи, как помещение пользователя в сеанс самостоятельно ... но это только одна линия, так что это действительно не имеет большого значения.

Что еще более важно его дизайн дает вам гораздо больше контроля, что делает его легким для реализации вашего разрешения так, как вы хотите, а не так, как паспорт предназначен. Плюс, по сравнению с паспортом это намного проще и легче учиться.