Everyauth 대 Passport.js?

Everyauth 와 Passport.js 는 매우 유사한 기능 세트를 가지고있는 것 같습니다. 내가 다른 하나를 사용하고 싶게 만드는 두 가지 사이의 긍정적이고 부정적인 비교는 무엇입니까?

Passport 의 개발자로서 나의 2 센트를 들었습니다 .

Passport를 개발하기 전에 모든 인증을 평가하고 내 요구 사항을 충족하지 않는다고 판단했습니다. 그래서 저는 다른 솔루션을 구현하기 시작했습니다. 제가 다루고 싶은 주요 사항은 다음과 같습니다.

관용적 Node.js

everyauth는 콜백과 클로저를 사용하는 Node의 접근 방식 대신 promise를 광범위하게 사용합니다. 약속은 비동기 프로그래밍에 대한 대안적인 접근 방식입니다. 일부 높은 수준의 상황에서는 유용했지만 응용 프로그램에이 선택을 강제하는 인증 라이브러리가 마음에 들지 않았습니다.

또한 콜백과 클로저를 적절하게 사용하면 간결하고 잘 설계된 (거의 기능적인 스타일) 코드가 생성됩니다. Node 자체의 많은 힘은이 사실에서 비롯되며 Passport는이를 따릅니다.

모듈 식

Passport는 전략 디자인 패턴을 사용하여 핵심 모듈과 다양한 인증 메커니즘 사이의 우려 사항을 명확하게 구분합니다. 이것은 전체 코드 크기가 더 작고 잘 정의되고 테스트 가능한 인터페이스를 포함하여 많은 이점이 있습니다.

기본적인 그림을 보려면 running $ npm install passport과 $ npm install everyauth. Passport를 사용하면 실제로 필요한 종속성 만 사용하여 응용 프로그램을 만들 수 있습니다.

이 모듈 식 아키텍처는 적응성이 입증되어 OpenID, OAuth, BrowserID, SAML 등 다양한 인증 메커니즘에 대한 지원을 구현 한 커뮤니티를 촉진합니다.

융통성 있는

Passport는 Connect 및 Express에서 설정 한 규칙을 사용하는 미들웨어fn(req, res, next) 입니다.

즉 , 경로를 원하는 위치와 인증을 사용할시기를 정의 할 때 놀라움 이 없습니다 . 특정 프레임 워크에 대한 종속성도 없습니다. 사람들은 Flatiron 과 같은 다른 프레임 워크와 함께 Passport를 성공적으로 사용하고 있습니다.

반대로 everyauth의 모든 모듈은 애플리케이션에 경로를 삽입 할 수 있습니다. 경로가 어떻게 전달되는지 명확하지 않고 특정 프레임 워크와 긴밀하게 연결되므로 디버깅이 어려울 수 있습니다.

Passport는 또한 Express에서 정의한 오류 처리 미들웨어에 이어 완전히 전통적인 방식으로 오류 를 발생시킵니다 .

대조적으로, everyauth에는 문제 공간에 잘 맞지 않는 자체 규칙이있어 # 36 과 같은 오래 지속되는 공개 문제를 일으 킵니다.

API 인증

모든 인증 라이브러리의 가장 큰 성과는 웹 기반 로그인만큼 우아하게 API 인증을 처리 할 수있는 능력입니다.

이 점에 대해서는 자세히 설명하지 않겠습니다. 그러나 저는 사람들이 Passport의 형제 프로젝트 인 OAuthorize 및 OAuth2orize 를 살펴볼 것을 권장 합니다. 이러한 프로젝트를 사용하여 HTML / 세션 기반 웹 앱 및 API 클라이언트 모두에 대해 "풀 스택"인증을 구현할 수 있습니다.

신뢰성

마지막으로 인증은 응용 프로그램의 중요한 구성 요소이며 완전히 편안하게 사용할 수 있어야합니다. everyauth에는 긴 문제 목록이 있으며, 그 중 상당수는 시간이 지남에 따라 공개되고 다시 나타납니다. 제 생각에 이것은 단위 테스트 범위가 낮기 때문이며, 이는 자체적으로 everyauth의 내부 인터페이스가 적절하게 정의되지 않았 음을 시사합니다.

반대로 Passport의 인터페이스와 전략은 잘 정의되어 있으며 단위 테스트를 통해 광범위하게 다루어집니다. Passport에 대해 제기 된 문제 는 대부분 인증과 관련된 버그가 아니라 사소한 기능 요청 인 경향이 있습니다.

젊은 프로젝트 임에도 불구하고이 수준의 품질은 유지 관리가 더 쉽고 앞으로도 신뢰할 수있는보다 성숙한 솔루션을 제안합니다.

여권

• 모듈 식 및 투명
• 좋은 문서
• 커뮤니티 기여 (모듈화로 인해)
• 모든 사람과 개와 함께 작동합니다 (다시 말하지만 모듈화로 인해)

Everyauth

• 오랜 개발 역사, 성숙함.
• 더 이상 유지되지 않음
• 훌륭한 문서
• 다양한 서비스와 함께 작동

everyauth에서 여권으로 변경을 마쳤습니다. 그 이유는 다음과 같습니다.

1. Everyauth는 충분히 안정적이지 않습니다. 마지막 빨대는 지난주에 Facebook 인증이 local.host 및 프로덕션 환경에서 작동하지만 동일한 코드와 데이터베이스 및 새로운 heroku 앱 인스턴스를 사용하더라도 heroku의 테스트 환경에서는 작동하지 않는 신비한 문제에 물 렸습니다. 그 시점에서 문제를 분리하는 방법에 대한 이론이 부족했기 때문에 모든 인증을 제거하는 것이 논리적 다음 단계였습니다.
2. 사용자 이름 / 암호 자격 증명을 사용하여 표준 인증을 지원하는 방식은 단일 페이지 웹 앱 접근 방식과 쉽게 통합되지 않습니다.
3. Google 계정에서 모든 인증을 사용할 수 없었습니다.
4. everyauth의 적극적인 개발은 감소하고있는 것 같습니다.

포트는 놀라 울 정도로 고통스럽지 않았으며 수동 테스트를 포함하여 몇 시간 밖에 걸리지 않았습니다.

그래서 당연히 여권을 추천합니다.

먼저 Everyauth를 사용해 보았고 이후 Passport로갔습니다. 그것은 나를 다소 더 유연하게 느꼈습니다. (예를 들어) 다른 공급자에 대해 다른 논리가 필요한 경우. 또한 사용자 지정 인증 전략을 쉽게 구성 할 수 있습니다 (imo). 반면에 뷰 도우미가 중요하다면 뷰 도우미가 없습니다.

나는 Everyauth를 더 구체적으로 mongoose-auth를 사용했습니다. everyauth 모듈을 해체하지 않고 파일을 제대로 분할하는 것이 어려웠습니다. 제 생각에는 Passport는 로그인을 만드는 더 깨끗한 방법입니다. 내가 매우 도움이되는 글이있다 http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

이것은 조금 늦게 대답했지만이 스레드를 발견했고 (Everyauth에 대한 모든 부정적인 피드백을들은 후) Passport를 사용하기로 결정한 다음 싫어했습니다. 불투명하고 미들웨어로만 작동했으며 (예를 들어 GraphQL 엔드 포인트에서 인증 할 수 없습니다) 버그를 디버깅하기 어려운 버그 가 두 개 이상 발생했습니다 (예 : Express 세션이 두 개 있습니까? ).

그래서 나는 찾아 가서 https://github.com/jed/authom을 찾았습니다 . 내 필요에 따라 이것은 훨씬 더 나은 라이브러리입니다! 다른 두 라이브러리보다 약간 낮은 수준이므로 사용자를 세션에 직접 넣는 것과 같은 작업을 수행해야합니다.하지만 이것은 한 줄에 불과하므로 큰 문제가 아닙니다.

더 중요한 것은 디자인이 훨씬 더 많은 제어를 제공하므로 Passport가 의도 한 방식이 아닌 원하는 방식으로 인증을 쉽게 구현할 수 있습니다. 또한 Passport에 비해 훨씬 간단하고 배우기 쉽습니다.

이 게시물의 날짜를 기록하면이 게시물이 얼마나 관련이 있는지 표시됩니다.

내 경험상 Everyauth는 암호 로그인 스타일로 즉시 작동하지 않았습니다. 나는 express3를 사용하고 있으며 미들웨어를 그렇게 선언 app.use(everyauth.middleware(app));했지만 여전히 내 템플릿에 대한 everyauth 로컬로 전달되지 않았습니다. 마지막 git 커밋은 1 년 전이었고 새 패키지가 모든 인증을 깨뜨렸다 고 생각합니다. 이제 여권을 시험해 볼게요.