IT

everyauth vs passport.js?

itgroup 2023. 9. 15. 20:56
반응형

everyauth vs passport.js?

모든 auth와 passport.js는 매우 유사한 특징 집합을 가지고 있는 것 같습니다.두 사람의 긍정적인 비교와 부정적인 비교 중 하나를 다른 하나보다 사용하고 싶게 만드는 것은 무엇입니까?

패스포트 개발자로서 제 2센트에 동의합니다.

Passport를 개발하기 전에 저는 모든 저작물을 평가했고, 그것이 제 요구사항에 부합하지 않는다고 판단했습니다.그래서 저는 다른 솔루션을 구현하기 시작했습니다.제가 언급하고자 한 주요 사항은 다음과 같습니다.

관용 노드.js

모든 작성자는 노드가 콜백과 종료를 사용하는 방식 대신 약속을 광범위하게 사용합니다.약속은 비동기 프로그래밍에 대한 대안적 접근법입니다.일부 고급 상황에서는 유용하지만, 애플리케이션에 이 선택을 강요하는 인증 라이브러리가 불편했습니다.

또한 콜백과 클로징을 적절히 사용하면 간결하고 잘 설계된(거의 기능적인 스타일) 코드가 생성된다는 것을 알게 되었습니다.노드 자체의 힘의 상당 부분은 이 사실에서 비롯되며, 패스포트는 이를 따릅니다.

모듈러

Passport는 전략 설계 패턴을 사용하여 핵심 모듈과 다양한 인증 메커니즘 사이의 문제를 명확하게 구분합니다.이를 통해 전체적인 코드 크기가 작고, 잘 정의되고 테스트 가능한 인터페이스 등 여러 가지 이점을 얻을 수 있습니다.

설명을 실행 중인 인 의 의 를 합니다 합니다 의 차이를 비교합니다.$ npm install passport그리고.$ npm install everyauth 수 . 여권을 사용하면 실제로 필요한 의존 관계만 사용하여 응용 프로그램을 만들 수 있습니다.

이 모듈형 아키텍처는 적응력이 뛰어나다는 것이 입증되었으며, Open을 비롯한 다양한 인증 메커니즘에 대한 지원을 구현한 커뮤니티를 지원합니다.ID, OAuth, Browser아이디, SAML 등등.

유연한

여권은 미들웨어일 뿐입니다.fn(req, res, next)Connect and Express 설립한 관례 가 관례

즉, 원하는 경로와 인증 사용 시기를 정의할 때 놀라운 일이 발생하지 않습니다.특정 프레임워크에 대한 의존성도 없습니다.사람들은 Flatiron과 같은 다른 프레임워크로 Passport를 성공적으로 사용하고 있습니다.

반면, 모든 작성자의 모듈은 응용프로그램에 경로를 삽입할 수 있습니다.경로가 어떻게 파견될지 명확하지 않고 특정 프레임워크와 긴밀하게 연결되기 때문에 디버깅이 어려울 수 있습니다.

또한 여권은 Express에서 정의한 오류 처리 미들웨어 다음으로 완전히 관습적인 방식으로 오류를 처리합니다.

이와 대조적으로, 모든 저작자는 고유한 규약을 가지고 있는데, 이것은 문제 공간에 잘 맞지 않기 때문에 #36과 같은 오랫동안 열려있는 문제를 야기합니다.

API 인증

모든 인증 라이브러리의 가장 중요한 성과는 웹 기반 사인온처럼 우아하게 API 인증을 처리할 수 있다는 점입니다.

이 점에 대해서는 자세히 설명하지 않겠습니다.하지만 저는 사람들에게 패스포트의 형제 프로젝트인 OAuthorizeOAuth2orize를 조사해보라고 권장합니다.이러한 프로젝트를 사용하면 HTML/세션 기반 웹 앱과 API 클라이언트 모두에 대해 "전체 스택" 인증을 구현할 수 있습니다.

믿을 수 있는

마지막으로, 인증은 애플리케이션의 중요한 구성 요소이며, 완전히 편안하게 사용하고 싶은 애플리케이션입니다.모든 저작자는 많은 문제가 시간이 지남에 따라 열려 있고 다시 나타나는 긴 문제 목록을 가지고 있습니다.이는 단위 테스트 적용 범위가 낮기 때문이라고 생각합니다. 이 자체는 모든 저작물의 내부 인터페이스가 적절하게 정의되지 않았음을 시사합니다.

이와 대조적으로, 패스포트의 인터페이스와 전략은 잘 정의되어 있고 유닛 테스트에 광범위하게 적용됩니다.Passport에 대해 제기된 문제는 대부분 인증과 관련된 버그라기보다는 사소한 기능 요청인 경향이 있습니다.

젊은 프로젝트임에도 불구하고, 이러한 수준의 품질은 앞으로도 유지 및 신뢰하기 쉬운 보다 성숙한 솔루션을 제시합니다.

여권

  • 모듈식으로 투명한
  • 좋은 서류
  • 커뮤니티 기여(모듈화로 인해)
  • 모든 사람과 그들의 개와 함께 작업합니다(모듈화로 인해 다시).

에브리저

  • 오랜 개발 역사와 성숙함.
  • 더 이상 유지되지 않는
  • 훌륭한 문서들
  • 다양한 서비스를 제공하는 작품들

방금 모든 저작물에서 여권으로 변경을 마쳤습니다.그 이유는 다음과 같습니다.

  1. 모든 저작물은 충분히 안정적이지 않습니다.마지막 고비는 지난주에 페이스북 인증이 로컬에서 작동하는 의문의 문제에 물린 것입니다.호스트 및 프로덕션 환경에서 실행되지만 동일한 코드 및 데이터베이스와 새로운 heroku 앱 인스턴스를 사용하더라도 heroku의 테스트 환경에서는 실행되지 않습니다.그 시점에서 문제를 분리하는 방법에 대한 이론이 바닥났기 때문에 모든 저자를 제거하는 것이 논리적인 다음 단계였습니다.
  2. 사용자 이름/비밀번호 자격 증명을 사용하여 표준 인증을 지원하는 방식은 단일 페이지 웹 앱 방식과 쉽게 통합되지 않습니다.
  3. 구글 계정으로 모든 저작자를 작업할 수는 없었습니다.
  4. 모든 저작물의 적극적인 개발은 쇠퇴하는 것처럼 보입니다.

항구는 놀랍게도 고통이 없었고, 수동 테스트를 포함하여 몇 시간밖에 걸리지 않았습니다.

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

저는 먼저 Everyauth를 사용해보고 Passport로 갔습니다.특히 (예를 들어) 다른 공급자에 대해 다른 논리가 필요한 경우에는 좀 더 유연하다는 생각이 들었습니다.또한 사용자 지정 인증 전략을 보다 쉽게 구성할 수 있습니다.반면, 보기 도우미가 중요한 경우에는 해당 보기 도우미가 없습니다.

답변이 좀 늦었지만, 저는 이 스레드를 찾았고 (에브리오토에 대한 부정적인 피드백을 들은 후) 패스포트를 사용하기로 결정했고... 그리고는 싫어했습니다.불투명했고 미들웨어로만 작동했으며(예를 들어 GraphQL Endpoint에서 인증할 수 없음) 버그를 디버그하기 위해 하나 이상의 하드 히트를 쳤습니다(예:Express 세션을 두 개 하려면 어떻게 해야 합니까?

그래서 찾아보니 https://github.com/jed/authom .제가 필요로 할 때는 이 도서관이 훨씬 더 좋아요!다른 두 개의 라이브러리보다 수준이 조금 낮아서 사용자가 직접 세션에 참여하는 등의 작업을 수행해야 합니다. 하지만 이 작업은 한 줄에 불과하므로 큰 문제가 되지 않습니다.

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

저는 모든 저작물을 mongoose-auth를 좀 더 구체적으로 사용하곤 했습니다.everyauth 모듈을 해체하지 않고서는 파일을 제대로 분할하기가 어려웠습니다.제 생각에는 여권이 더 깨끗한 로그인 방법일 것 같습니다.http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/ 매우 도움이 되는 글이 있습니다.

이 게시물의 날짜를 기록해 두십시오. 이 게시물이 얼마나 관련이 있는지를 나타냅니다.

제 경험으로는 암호 로그인 방식으로 모든 인증이 실행되지 않았습니다.express3를 사용하고 있는데 미들웨어를 그렇게 선언합니다.app.use(everyauth.middleware(app));그리고 그것은 여전히 내 템플릿에 모든 로컬을 전달하지 않았습니다.마지막 git 커밋은 1년 전이었고 새 패키지가 모든 저작물을 깼다고 생각합니다.이제 여권을 써보려고 합니다.

언급URL : https://stackoverflow.com/questions/11974947/everyauth-vs-passport-js

반응형