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.