Everyauth czy Passport.js?

Wydaje się, że Everyauth i Passport.js mają bardzo podobne zestawy funkcji. Jakie są pozytywne i negatywne porównania między tymi dwoma, które sprawiłyby, że chciałbym użyć jednego z nich?

Wbijam się w moje dwa centy, jako twórca Passport .

Zanim stworzyłem Passport, oceniłem każdyauth i stwierdziłem, że nie spełnia moich wymagań. Zacząłem więc wdrażać inne rozwiązanie. Główne punkty, do których chciałem się odnieść, to:

Idiomatic Node.js

everyauth szeroko wykorzystuje obietnice, zamiast podejścia Node do używania wywołań zwrotnych i domknięć. Obietnice to alternatywne podejście do programowania asynchronicznego. Chociaż przydatne w niektórych sytuacjach wysokiego poziomu, nie czułem się komfortowo z biblioteką uwierzytelniania wymuszającą ten wybór w mojej aplikacji.

Ponadto uważam, że prawidłowe użycie wywołań zwrotnych i domknięć daje zwięzły, dobrze zaprojektowany (prawie funkcjonalny styl) kod. Duża część mocy samego Node pochodzi z tego faktu, a Passport idzie za tym.

Modułowe

Passport wykorzystuje wzorzec projektowania strategii, aby zdefiniować wyraźne oddzielenie problemów między podstawowym modułem a różnymi mechanizmami uwierzytelniania. Ma to wiele zalet, w tym mniejszy całkowity rozmiar kodu oraz dobrze zdefiniowane i testowalne interfejsy.

Aby uzyskać podstawową ilustrację, porównaj różnicę między bieganiem $ npm install passporta $ npm install everyauth. Passport umożliwia tworzenie aplikacji przy użyciu tylko tych zależności, których faktycznie potrzebujesz.

Ta modułowa architektura okazała się elastyczna, ułatwiając społeczności, która wdrożyła obsługę wielu różnych mechanizmów uwierzytelniania, w tym OpenID, OAuth, BrowserID, SAML itp.

Elastyczne

Passport to tylko oprogramowanie pośredniczące , wykorzystujące fn(req, res, next)konwencję opracowaną przez Connect i Express.

Oznacza to, że nie ma żadnych niespodzianek , ponieważ określasz, gdzie chcesz mieć swoje trasy i kiedy chcesz użyć uwierzytelniania. Nie ma również żadnych zależności od określonej struktury. Ludzie z powodzeniem używają Passport z innymi frameworkami, takimi jak Flatiron

W przeciwieństwie do tego, każdy moduł w everyauth może wstawiać trasy do aplikacji. Może to utrudniać debugowanie, ponieważ nie jest oczywiste, w jaki sposób trasa zostanie wysłana i prowadzi do ścisłego powiązania z określoną strukturą.

Passport również popełnia błędy w sposób całkowicie konwencjonalny, obok oprogramowania pośredniczącego do obsługi błędów zdefiniowanego przez Express.

W przeciwieństwie do tego każdyauth ma swoje własne konwencje, które nie pasują dobrze do problemu, powodując długotrwałe otwarte problemy, takie jak # 36

Uwierzytelnianie API

Ukoronowaniem każdej biblioteki uwierzytelniającej jest jej zdolność do obsługi uwierzytelniania API równie elegancko, jak w przypadku logowania internetowego.

Nie będę się zbytnio rozwodził w tej kwestii. Jednak zachęcam ludzi do przyjrzenia się bliźniaczym projektom Passport, OAuthorize i OAuth2orize . Korzystając z tych projektów, można zaimplementować uwierzytelnianie „pełnego stosu” zarówno dla aplikacji internetowych opartych na HTML / sesjach, jak i dla klientów interfejsu API.

Niezawodny

Wreszcie, uwierzytelnianie jest krytycznym elementem aplikacji, na którym chcesz w pełni polegać. everyauth ma długą listę problemów, z których wiele pozostaje otwartych i pojawia się z czasem. Moim zdaniem wynika to z niskiego pokrycia testów jednostkowych, co samo w sobie sugeruje, że wewnętrzne interfejsy w każdymauth nie są odpowiednio zdefiniowane.

W przeciwieństwie do tego interfejsy Passport i jego strategie są dobrze zdefiniowane i szeroko objęte testami jednostkowymi. Problemy zgłoszone do usługi Passport to przeważnie drobne prośby o dodanie funkcji, a nie błędy związane z uwierzytelnianiem.

Pomimo tego, że jest to młodszy projekt, ten poziom jakości sugeruje bardziej dojrzałe rozwiązanie, które jest łatwiejsze w utrzymaniu i zaufaniu w przyszłości.

Paszport

• modułowe i przejrzyste
• dobrzy doktorzy
• wkład społeczności (dzięki swojej modułowości)
• współpracuje ze wszystkimi i ich psem (znowu dzięki swojej modułowości)

Everyauth

• długa historia rozwoju, dojrzała.
• nie jest już utrzymywany
• świetne dokumenty
• współpracuje z szeroką gamą usług

Właśnie skończyłem zmieniać wszystkie uwierzytelnienia na paszport. Powody były następujące.

1. Everyauth nie jest wystarczająco stabilny. W zeszłym tygodniu ugryzł mnie tajemniczy problem polegający na tym, że uwierzytelnianie Facebooka działało na local.host i na środowisku produkcyjnym, ale nie w moim środowisku testowym na heroku, nawet z identycznym kodem i bazami danych oraz nową instancją aplikacji heroku. W tym momencie zabrakło mi teorii, jak wyodrębnić problem, więc usunięcie wszystkich uwierzytelnień było logicznym następnym krokiem.
2. Sposób, w jaki zapewnia obsługę standardowego uwierzytelniania przy użyciu poświadczeń nazwy użytkownika / hasła, nie jest łatwo zintegrowany z podejściem opartym na pojedynczej stronie internetowej.
3. Nie udało mi się zmusić wszystkich uwierzytelnień do pracy z kontami Google.
4. Wydaje się, że aktywny rozwój wszystkich autorów słabnie.

Port był zaskakująco bezbolesny, zajmował tylko kilka godzin, łącznie z testami ręcznymi.

Więc oczywiście polecam pójść po paszport.

Najpierw wypróbowałem Everyauth i od tego czasu przeszedłem do Passport. Wydało mi się to nieco bardziej elastyczne, zwł. jeśli (na przykład) potrzebuję innej logiki dla różnych dostawców. Ułatwia również (imo) konfigurowanie niestandardowych strategii uwierzytelniania. Z drugiej strony nie ma pomocników widoku, jeśli są one dla Ciebie ważne.

Kiedyś używałem Everyauth bardziej szczegółowo, mongoose-auth. Okazało się, że trudno było poprawnie podzielić moje pliki bez demontażu modułu everyauth. Paszport to moim zdaniem czystsza metoda tworzenia loginów. Jest napis, który uważam za bardzo pomocny http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

Odpowiada trochę za późno, ale znalazłem ten wątek i (po wysłuchaniu wszystkich negatywnych opinii na temat Everyauth) zdecydowałem się użyć Passport ... i znienawidziłem go. Był nieprzejrzysty, działał tylko jako oprogramowanie pośrednie (na przykład nie można było uwierzytelnić się z punktu końcowego GraphQL) i trafiłem na więcej niż jeden trudny do debugowania błąd (np. Jak mam dwie sesje Express? ).

Poszedłem więc szukać i znalazłem https://github.com/jed/authom . Na moje potrzeby jest to znacznie lepsza biblioteka! Jest nieco niższy niż pozostałe dwie biblioteki, więc musisz samodzielnie wprowadzić użytkownika do sesji ... ale to tylko jedna linia, więc to naprawdę nic wielkiego.

Co ważniejsze, jego konstrukcja zapewnia o wiele większą kontrolę, ułatwiając wdrożenie autoryzacji w sposób, w jaki chcesz, a nie zgodnie z zamierzeniami Passport. Dodatkowo, w porównaniu z paszportem, jest dużo prostszy i łatwiejszy do nauczenia.

Zanotuj datę tego posta, wskaże ona, jak istotny jest ten post.

Z mojego doświadczenia wynika, że ​​Everyauth nie działał po wyjęciu z pudełka z jego stylem logowania za pomocą hasła. Używam express3 i deklaruję moje oprogramowanie pośrednie w ten sposób, app.use(everyauth.middleware(app));ale nadal nie przekazuje wszystkich uwierzytelnień lokalnych do mojego szablonu. Ostatnie zatwierdzenie git miało miejsce rok temu i wydaje mi się, że nowe pakiety zepsuły wszystkie uwierzytelnienia. Teraz spróbuję paszportu.