Здається, у Everyauth та Passport.js дуже схожі набори функцій. Які є позитивні та негативні порівняння між двома, які змусили б мене використовувати одне за іншим?
Відповіді:
Здійснював мій два центи, як розробник Passport .
Перш ніж розробляти паспорт, я оцінив все, і визначив, що він не відповідає моїм вимогам. Отже, я почав реалізовувати інше рішення, яке було б. Основні моменти, на які я хотів звернутися, - це:
Ідіоматичний Node.js
Everyauth широко використовує обіцянки, замість підходу Node використовувати зворотні виклики та закриття. Обіцянки - це альтернативний підхід до асинхронного програмування. Будучи корисним у деяких ситуаціях високого рівня, мені не було зручно, щоб бібліотека аутентифікації змушувала цей вибір після моєї заявки.
Крім того, я вважаю, що правильне використання зворотних дзвінків та закриттів дає короткий, чітко сконструйований (майже функціональний стиль) код. Значна частина власне Вузла походить від цього факту, і Паспорт пасує за цим.
Модульний
У паспорті використовується схема розробки стратегії, щоб визначити чітке розділення проблем між основним модулем та різними механізмами аутентифікації. Це має ряд переваг, включаючи менший загальний розмір коду та чітко визначені та перевірені інтерфейси.
Для основної ілюстрації порівняйте різницю між бігом $ npm install passportта $ npm install everyauth. Паспорт дозволяє вам складати свою заявку, використовуючи лише ті залежності, які вам справді потрібні.
Ця модульна архітектура зарекомендувала себе пристосованою, сприяючи спільноті, яка реалізувала підтримку широкого спектру механізмів аутентифікації, включаючи OpenID, OAuth, BrowserID, SAML тощо.
Гнучка
Паспорт - це лише середнє програмне забезпечення , використовуючи fn(req, res, next)конвенцію, встановлену Connect і Express.
Це означає, що сюрпризів немає , оскільки ви визначаєте, де ви хочете свої маршрути та коли ви хочете використовувати автентифікацію. Також не існує залежностей від конкретних рамок. Люди успішно використовують паспорт із іншими рамками, такими як Flatiron
На відміну від цього, будь-який модуль у кожній мові може вставляти маршрути у вашу програму. Це може ускладнити налагодження, оскільки не очевидно, як маршрут буде розісланий, і це призведе до тісного з’єднання з конкретною рамкою.
Паспорт також помиляється таким чином, що є цілком звичайним, наступним чином до обробки помилок , визначених Express.
Навпаки, у Everyauth є свої умовні умови, які добре не підходять до проблемного простору, викликаючи давні відкриті питання, такі як # 36
Аутентифікація API
Найголовнішим досягненням будь-якої бібліотеки аутентифікації є її здатність обробляти автентифікацію API так само елегантно, як і веб-базі даних.
Я не буду дуже детально розробляти цю тему. Однак я закликаю людей заглядати в проекти побратимів , OAuthorize та OAuth2orize . За допомогою цих проектів ви можете реалізувати автентифікацію "повного стека" як для веб-додатків на основі HTML / сесії, так і для клієнтів API.
Надійний
Нарешті, автентифікація є найважливішим компонентом програми, і ви хочете, щоб вам було зручно покладатися. у кожній є довгий перелік питань, багато з яких залишаються відкритими і виникають з часом. На мою думку, це пов’язано з низьким покриттям тестових одиниць, що саме по собі говорить про те, що внутрішні інтерфейси у всіх значеннях не визначені належним чином.
Навпаки, інтерфейси Passport та його стратегії чітко визначені та широко охоплені одиничними тестами. Проблеми, подані проти паспорта, як правило, є незначними запитами на функції, а не помилками, що стосуються автентифікації.
Незважаючи на те, що це молодший проект, цей рівень якості пропонує більш зріле рішення, яке легше підтримувати і довіряти вперед.
Щойно закінчила перехід з алюміна на паспорт. Причини були такі.
Порт виявився напрочуд безболісним, зайнявши лише кілька годин, включаючи тестування вручну.
Тож очевидно, рекомендую їхати за паспортом.
Я спробував спершу Everyauth і відтоді поїхав до паспорта. Мене це вразило як дещо гнучкіше, особливо. якщо (наприклад) мені потрібна інша логіка для різних провайдерів. Це також спрощує (imo) налаштування користувальницьких стратегій аутентифікації. З іншого боку, він не має помічників для перегляду, якщо вони важливі для вас.
Раніше я використовував Everyauth більш конкретно мангуст-авт. Мені було важко правильно розділити свої файли, не демонтуючи модуль Everyauth. Паспорт на мою думку - це більш чистий метод створення логінів. Є запис, який мені здався дуже корисним http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/
На це я відповів трохи пізно, але я знайшов цю тему і (почувши всі негативні відгуки про Everyauth) вирішив скористатися паспортом ... а потім зненавидів його. Це було непрозоро, працювало лише як середнє програмне забезпечення (наприклад, ви не могли автентифікуватись із кінцевої точки GraphQL), і я вдарив більше ніж одну важку помилку налагодження (напр., Як у мене два сеанси експресів? ).
Тож я пішов шукати і знайшов https://github.com/jed/authom . Для моїх потреб це набагато краща бібліотека! Це трохи нижчий рівень, ніж інші дві бібліотеки, тому вам доведеться робити такі речі, як введення користувача в сеанс самостійно ... але це лише один рядок, так що це насправді не велика справа.
Що ще важливіше, його дизайн дає вам набагато більше контролю, що полегшує реалізацію вашої авторизації так, як ви хочете, а не так, як планував паспорт. Плюс до цього, порівняно з паспортом, це набагато простіше та легше в навчанні.
Зауважте дату цієї публікації, вона вказуватиме наскільки релевантною є ця публікація.
З мого досвіду, Everyauth не вийшов з коробки зі своїм стилем входу в пароль. Я використовую express3, і я заявляю про своє посередницьке програмне забезпечення таким, app.use(everyauth.middleware(app));і воно все ще не переходило в локальний алфавіт до мого шаблону. Останнє вчинення git було рік тому, і я вважаю, що нові пакети все порушили. Зараз я буду пробувати паспорт.