Laravel 4 Xác thực đa người dùng

Question

Tôi đang tạo ứng dụng Laravel 4 yêu cầu xác thực đăng nhập cho 3 loại thực thể: Huấn luyện viên, Sinh viên & Quản trị viên, tất cả đều có giao diện người dùng riêng biệt. Trong khi tôi có thể sử dụng một gói như Sentry 2 và một bảng người dùng DB duy nhất với các kiểu người dùng để đạt được điều này, một cái gì đó về các mẫu thiết kế DB đa hình tiềm năng và nhức đầu có thể xảy ra theo dõi, không ngồi tốt với tôi. Đã xử lý các vấn đề đa hình trong quá khứ với các ứng dụng trước đó, và nỗi đau nó có thể tạo ra khi bạn muốn bình thường hóa cấu trúc DB của bạn, vv .. có các bảng DB riêng cho từng loại thực thể có vẻ tốt hơn.

Bạn giải quyết vấn đề thiết kế này như thế nào?

Laravel 4 auth sử dụng về cơ bản các tập tin sau đây:

• Auth.php (mặt tiền)
• AuthManager.php
• AuthServiceProvider.php
• Guard.php
• auth.php (config)
• User.php (mô hình eloquent)

Tôi đã chơi xung quanh bằng cách sao chép các tệp này để tạo ra hầu hết độc lập cho thực thể huấn luyện hoạt động, đăng ký mặt tiền và nhà cung cấp dịch vụ trong tệp app.php, cũng như thực hiện các thay đổi cần thiết để định cấu hình sử dụng mô hình hùng hồn HLV để xác thực:

• AuthCoach.php (mặt tiền)
• AuthCoachManager.php
• AuthCoachServiceProvider.php
• Guard.php
• authcoach.php (config)
• Coach.php (model hùng hồn)

tôi vẫn đang sử dụng Guard.php từ tiêu chuẩn Laravel 4 auth, nhưng Guard có thể dễ dàng được mở rộng nếu có nhu cầu để tùy chỉnh phương pháp Guard để xác thực HLV bằng cách tạo ra một Tệp GuardCoach.php.

Nếu tôi sẽ có auth riêng biệt cho từng loại thực thể, bạn có nghĩ đây là một cách hay để đạt được nó không?

Bạn có thấy bất kỳ vấn đề tiềm ẩn nào hoặc biết cách làm tốt hơn không?

Answer 1

Có lẽ tôi không hiểu rõ bối cảnh của bạn, nhưng tại sao bạn không sử dụng khái niệm cơ bản về kiểm soát truy cập dựa trên vai trò và hiển thị các nội dung khác nhau cho các vai trò khác nhau? Nếu điều đó không đủ chặt chẽ, bạn có thể sử dụng các chính sách xác thực dựa trên thuộc tính để tạo hạt cho phép. Lý do bạn muốn sao chép (ba là) auth-logic? Không đề cập đến thực tế của dữ liệu db dư thừa (bảng người dùng riêng biệt cho loại người dùng riêng biệt? Yuk!)?

Nếu bạn không được satisifed với Sentry (cá nhân, tôi không sử dụng thư viện đó) tôi có thể khuyên bạn nên Zizaco/Confide + Zizaco/Entrust như một giải pháp sạch sẽ và thanh lịch cho người dùng/vai trò/quản lý quyền. Hãy xem tại đây Zizaco GitHub.

Một ý tưởng chung nhanh:

• sử dụng một cơ chế xác thực sạch duy nhất cho toàn bộ ứng dụng
• truy cập nghiền với vai trò hoặc Role + Quyền
• tách lý quản trị của bạn thành bộ điều khiển riêng biệt (AdminUserController, AdminCoachController, bất cứ điều gì ..)
• Tôi thấy không có khó khăn trong việc soạn cấu trúc lưỡi khuôn phù hợp để có tất cả được thực hiện tốt và được tổ chức tốt

Các mối quan tâm đa hình của bạn là gì?

Nếu bạn lo lắng rằng bảng người dùng của bạn sẽ bị lộn xộn, hãy để nó làm nơi lưu trữ chi tiết xác thực và đặt tất cả chi tiết người dùng cần thiết khác (không phải người dùng) trong bảng khác.

Hy vọng điều này sẽ giúp bạn, nếu tôi chỉ hiểu rõ vấn đề của bạn.

Answer 2

Tôi nghĩ bạn đang cố gắng văng một con muỗi bằng cách sử dụng vồ.

Dưới đây là cách tôi giải quyết cùng một vấn đề:

• tôi muốn chắc chắn rằng xác thực của người dùng (username, password) được lưu trữ trong cùng một bảng. Về cơ bản, tôi có ba loại người dùng.

• Tôi đã sử dụng Sentry 2 giúp bạn dễ dàng quản lý nội dung xác thực.

• Sử dụng di chuyển mặc định được cung cấp bởi Sentry 2, tôi đã thêm cột 'vai trò' vào bảng 'người dùng' - điều này phân biệt 3 loại người dùng.

• Đối với mỗi loại người dùng, tôi đã tạo một bảng với các trường cụ thể.

• Khi người dùng xác thực, tôi sẽ lấy 'vai trò' của họ từ bảng 'người dùng', chạy một vài câu lệnh if và biết chế độ xem nào để phân phối chúng.

Và muỗi đã chết hoàn toàn.

Onto của bạn:

• Về cơ bản, cả hai cách tiếp cận của chúng tôi đều giống nhau - vì mỗi loại người dùng có một bảng riêng biệt cho các lĩnh vực họ làm không phải tất cả cổ phiếu (trừ tên đầu tiên, cuối cùng tên, email, mật khẩu, lần đăng nhập cuối cùng, v.v.).

• Cách tiếp cận của bạn sẽ cho phép người dùng thuộc về ba thực thể - điều này không chính xác về mặt logic. Tôi sẽ không - đó là một cách hợp lý ...

• Bạn sợ 'vấn đề đa hình' nhưng tôi không nghĩ rằng chúng tôi có rất nhiều để đối phó với ở đây. Tất cả những gì chúng tôi có thể làm là xác định trong các mô hình của chúng tôi rằng một huấn luyện viên, ví dụ: belongsTo một người dùng. Và người dùng là huấn luyện viên hasOne.

• Nhưng trên thực tế, chúng tôi thậm chí không cần phải xác định mối quan hệ. Bởi vì khi xác thực, chúng ta cần chạy câu lệnh if anyway. Vì vậy, bằng cách sử dụng đối tượng người dùng được trả về từ xác thực, chúng tôi sẽ biết hai điều: bảng nào sau đó đi tới thông tin người dùng loại riêng biệt và chế độ xem nào để phân phát cho người dùng đã xác thực.

Đừng sợ, con trai