Everyauth và Passport.js dường như có bộ tính năng rất giống nhau. Một số so sánh tích cực và tiêu cực giữa hai phép so sánh khiến tôi muốn sử dụng cái này hơn cái kia là gì?
Câu trả lời:
Tham gia với hai xu của tôi, với tư cách là nhà phát triển Passport .
Trước khi phát triển Passport, tôi đã đánh giá everyauth và xác định rằng nó không đáp ứng yêu cầu của tôi. Vì vậy, tôi bắt đầu triển khai một giải pháp khác. Những điểm chính tôi muốn giải quyết là:
Idiomatic Node.js
everyauth sử dụng rộng rãi các lời hứa, thay vì cách tiếp cận của Node là sử dụng các lệnh gọi lại và các lệnh đóng. Hứa hẹn là một cách tiếp cận thay thế cho lập trình không đồng bộ. Mặc dù hữu ích trong một số tình huống cấp cao, nhưng tôi không thấy thoải mái với thư viện xác thực buộc lựa chọn này đối với ứng dụng của mình.
Hơn nữa, tôi thấy rằng việc sử dụng hợp lý các lệnh gọi lại và bao đóng sẽ mang lại mã ngắn gọn, được cấu trúc tốt (gần như kiểu chức năng). Phần lớn sức mạnh của Node xuất phát từ thực tế này và Passport cũng làm theo.
Mô-đun
Passport sử dụng một mô hình thiết kế chiến lược để xác định sự tách biệt rõ ràng các mối quan tâm giữa mô-đun cốt lõi và các cơ chế xác thực khác nhau. Điều này có một số lợi ích, bao gồm kích thước mã tổng thể nhỏ hơn và các giao diện được xác định rõ và có thể kiểm tra được.
Để có hình minh họa cơ bản, hãy so sánh sự khác biệt giữa running $ npm install passportvà $ npm install everyauth. Passport cho phép bạn tạo đơn đăng ký của mình chỉ bằng các phụ thuộc bạn thực sự cần.
Kiến trúc mô-đun này đã chứng tỏ bản thân có thể thích ứng, tạo điều kiện cho cộng đồng triển khai hỗ trợ cho nhiều cơ chế xác thực, bao gồm OpenID, OAuth, BrowserID, SAML, v.v.
Linh hoạt
Passport chỉ là phần mềm trung gian , sử dụng fn(req, res, next)quy ước được thiết lập bởi Connect và Express.
Điều này có nghĩa là không có gì ngạc nhiên khi bạn xác định nơi bạn muốn các tuyến đường của mình và khi nào bạn muốn sử dụng xác thực. Cũng không có phụ thuộc vào một khuôn khổ cụ thể. Mọi người đang sử dụng thành công Passport với các framework khác như Flatiron
Ngược lại, bất kỳ mô-đun nào trong everyauth đều có thể chèn các tuyến vào ứng dụng của bạn. Điều này có thể làm cho việc gỡ lỗi trở nên khó khăn, vì không rõ ràng một tuyến đường sẽ được gửi như thế nào và dẫn đến việc kết hợp chặt chẽ với một khuôn khổ cụ thể.
Passport cũng gặp lỗi theo cách hoàn toàn thông thường, tiếp theo là phần mềm trung gian xử lý lỗi như được Express định nghĩa.
Ngược lại, everyauth có các quy ước riêng, không phù hợp với không gian vấn đề, gây ra các vấn đề mở lâu dài, chẳng hạn như # 36
Xác thực API
Thành tựu đỉnh cao của bất kỳ thư viện xác thực nào là khả năng xử lý xác thực API một cách thanh lịch như đăng nhập dựa trên web.
Tôi sẽ không giải thích nhiều về điểm này. Tuy nhiên, tôi khuyến khích mọi người xem xét các dự án anh em của Passport, OAuthorize và OAuth2orize . Sử dụng các dự án này, bạn có thể triển khai xác thực "toàn bộ", cho cả ứng dụng web dựa trên HTML / phiên và ứng dụng khách API.
Đáng tin cậy
Cuối cùng, xác thực là một thành phần quan trọng của một ứng dụng và bạn muốn hoàn toàn thoải mái khi dựa vào. everyauth có một danh sách dài các vấn đề, nhiều vấn đề trong số đó vẫn mở và xuất hiện trở lại theo thời gian. Theo ý kiến của tôi, điều này là do phạm vi kiểm tra đơn vị thấp, bản thân nó cho thấy rằng các giao diện nội bộ trong everyauth không được xác định phù hợp.
Ngược lại, giao diện của Passport và các chiến lược của nó được xác định rõ ràng và được bao phủ rộng rãi bởi các bài kiểm tra đơn vị. Các vấn đề liên quan đến Hộ chiếu thường chủ yếu là các yêu cầu về tính năng nhỏ thay vì các lỗi liên quan đến xác thực.
Mặc dù là một dự án trẻ hơn, nhưng mức chất lượng này cho thấy một giải pháp hoàn thiện hơn, dễ bảo trì và tin tưởng hơn trong tương lai.
Vừa hoàn tất việc đổi từ everyauth sang passport. Những lý do sau đây.
Quá trình này không gây đau đớn một cách đáng ngạc nhiên, chỉ mất vài giờ, bao gồm cả thử nghiệm thủ công.
Vì vậy, rõ ràng, tôi khuyên bạn nên đi làm hộ chiếu.
Tôi đã dùng thử Everyauth trước và sau đó đã chuyển sang Passport. Nó khiến tôi cảm thấy linh hoạt hơn, đặc biệt. nếu (ví dụ) tôi cần logic khác nhau cho các nhà cung cấp khác nhau. Nó cũng giúp dễ dàng hơn (imo) để định cấu hình các chiến lược xác thực tùy chỉnh. Mặt khác, nó không có trình trợ giúp xem, nếu chúng quan trọng đối với bạn.
Tôi đã từng sử dụng Everyauth cụ thể hơn là mongoose-auth. Tôi thấy thật khó để chia nhỏ các tệp của mình một cách chính xác mà không tháo dỡ mô-đun everyauth. Passport theo ý kiến của tôi là một phương pháp rõ ràng hơn để tạo thông tin đăng nhập. Có một bài viết mà tôi thấy rất hữu ích http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/
Câu trả lời này hơi muộn, nhưng tôi đã tìm thấy chủ đề này và (sau khi nghe tất cả các phản hồi tiêu cực về Everyauth) đã quyết định sử dụng Passport ... và sau đó ghét nó. Nó không rõ ràng, chỉ hoạt động như phần mềm trung gian (ví dụ: bạn không thể xác thực từ điểm cuối GraphQL) và tôi gặp phải nhiều lỗi khó gỡ lỗi (ví dụ: Làm cách nào để có hai phiên Express? ).
Vì vậy, tôi đã đi tìm và tìm thấy https://github.com/jed/authom . Đối với nhu cầu của tôi, đây là một thư viện tốt hơn nhiều! Nó thấp hơn một chút so với hai thư viện còn lại, vì vậy bạn phải làm những việc như tự đưa người dùng vào phiên ... nhưng đó chỉ là một dòng nên thực sự không có gì to tát.
Quan trọng hơn, thiết kế của nó cho phép bạn kiểm soát nhiều hơn, giúp bạn dễ dàng thực hiện ủy quyền theo cách bạn muốn chứ không phải theo cách Passport dự định. Thêm vào đó, so với Passport, nó đơn giản và dễ học hơn rất nhiều.
Lưu ý ngày của bài đăng này, nó sẽ cho biết mức độ liên quan của bài đăng này.
Theo kinh nghiệm của tôi, Everyauth không hoạt động hiệu quả với kiểu đăng nhập bằng mật khẩu. Tôi đang sử dụng express3 và tôi khai báo phần mềm trung gian của mình như vậy app.use(everyauth.middleware(app));và nó vẫn không chuyển trong địa phương everyauth vào mẫu của tôi. Lần cam kết git gần đây nhất là một năm trước và tôi nghĩ rằng các gói mới đã bị hỏng everyauth. Bây giờ tôi sẽ thử hộ chiếu.