2009-09-10 38 views
10

Cho phép nói rằng tôi có một ASP.Net MVC App và ứng dụng này (UI) tham chiếu một lớp logic nghiệp vụ (BLL) và BLL tham chiếu lớp truy cập dữ liệu (DAL) của tôi..Net Membership trong nTier App

Tôi đang sử dụng Nhà cung cấp tư cách thành viên và vai trò tùy chỉnh để cấp phép.

Tôi đang cố gắng xác định những lớp nào cần tham khảo nhà cung cấp tư cách thành viên của tôi.

Trong MVC bạn có thể thực hiện kiểm tra ủy quyền theo cách sau đây:

[Authorize(Roles = "SomeRoleName")] 
public ActionResult Index() 
{ 
//do something 
} 

Và trong BLL của tôi, tôi có thể muốn kiểm tra xem nếu một người dùng đang ở trong một vai trò cũng như:

public static bool IsRoleEditor(User user, Role userRole) 
    { 
    bool retValue = false; 

    if (user.Application.AppID == UserRole.Application.AppID) 
    { 
     if (Roles.IsUserInRole("ModifyRoles")) 
     { 
      retValue = true; 
     } 


    return retValue; 
    } 

Tôi sẽ phải tham khảo và khởi tạo các lớp thành viên trong cả hai lớp nếu tôi làm điều này. Đây có phải là cách đúng để kiến ​​trúc sư một ứng dụng như thế này? Có vẻ như rất nhiều dự phòng.

Vì tôi có BLL nên tránh sử dụng thuộc tính "[Authorize (Roles =" SomeRoleName ")]" và thay vào đó gọi hàm BLL từ bên trong mã MVC để kiểm tra xem người dùng có trong vai trò không? Nếu tôi làm điều này thì MVC vẫn cần một tham chiếu đến nhà cung cấp thành viên để xác thực và như vậy để tận dụng lợi thế của Đăng nhập và các điều khiển ASP khác, phải không?

Tôi có thoát khỏi cơ sở và đi sai hướng không?

Trả lời

4

Theo quan điểm của tôi đây là một điểm yếu của thiết kế thành viên/Vai trò. Cách thức tôi sẽ làm tròn điều này, ví dụ để có ủy quyền dựa trên vai trò trên cả hai tầng UI và BLL trong một ứng dụng n-tier phân tán, sẽ đưa ra một dịch vụ trong tầng BLL để lộ các bit liên quan (GetRolesForUser vv) và được thực hiện bằng cách gọi RoleProvider trên máy chủ.

Sau đó triển khai RoleProvider tùy chỉnh trên máy khách được triển khai bằng cách gọi dịch vụ được BLL tiếp xúc.

Bằng cách này, tầng UI và BLL đều chia sẻ cùng một RoleProvider. Tầng UI có thể sử dụng kiến ​​thức về vai trò của người dùng hiện tại để cải thiện giao diện người dùng (ví dụ: ẩn/tắt điều khiển giao diện người dùng tương ứng với các tính năng trái phép) và BLL có thể đảm bảo rằng người dùng không thể thực thi logic kinh doanh mà họ không được ủy quyền.

0

Nhận đối tượng người dùng của bạn để triển khai giao diện IPrincipal và ném xung quanh các lớp. Sau đó, bạn vẫn có thể sử dụng thuộc tính [Autorize] được tích hợp sẵn.

Mặc dù được viết cách đây hơn 3 năm và về lâu đài, this article có thể hữu ích. Nó bắt đầu nhận được vào công cụ IPrincipal một nửa xuống.

HTHS
Charles

+0

Chắc chắn sử dụng thuộc tính Ủy quyền trong MVC. Bạn không cần phải kiểm tra thủ công IsInRoles. –

+0

Vấn đề là tôi cần phải xử lý thêm logic kinh doanh ngoài "IsInRole" hoặc "Ủy quyền" mà tôi nghĩ nên luôn luôn có trong BLL. Tôi có thể chuyển đối tượng người dùng ở mọi nơi, nhưng sau đó tại sao không chỉ bỏ qua ủy quyền và chỉ sử dụng BLL. – Jay

1

xuất sắc câu hỏi, tôi tự hỏi điều tương tự ngày hôm nay. Một trong những ý tưởng tôi đã có (nhưng tôi không thực sự chắc chắn nếu đó là cách tốt nhất để đi) là sử dụng một giao diện (ví dụ: IRoleProvider) mà bạn có thể vượt qua để BLL của bạn để kiểm tra truy cập của bạn.

public static bool IsRoleEditor(User user, IRoleProvider rp) 
{ 
    return (rp.IsUserInRole(user,"ModifyRoles")); 
} 

Với điều này, bạn vẫn xác minh truy cập của bạn trong BLL, bạn có thể sử dụng một mô hình trong các thử nghiệm đơn vị của bạn để kiểm tra logic của bạn và bạn chỉ cần tạo ra một lớp (hoặc thực hiện điều này trong một lớp học BaseController) trong trang web MVC của bạn sẽ triển khai IRoleProvider và thực hiện kiểm tra thích hợp bằng cách sử dụng API ủy quyền ASP.NET.

Hy vọng điều này sẽ hữu ích.

-1

Quyền truy cập vai trò thường không được trong BLL. Truy cập là trách nhiệm giao diện người dùng.

Với điều đó đã nói, hãy tận dụng giao diện IPrinciple như các áp phích trên đã nêu. Bạn có quyền truy cập vào IPrinciple ở cấp độ Thread.

Thread.CurrentPrincipal 
+0

Charles, thx để trả lời. Như bạn có thể thấy mặc dù tôi phải xử lý một số logic nghiệp vụ, ngoài việc kiểm tra vai trò cơ bản, để xác định để xác định người dùng bảo mật thực sự. Tôi nghĩ rằng tất cả BL nên ở trong BLL đó là lý do tại sao tôi đã lên kế hoạch đóng gói an ninh ở đó. Bạn có nói rằng nó là thích hợp hơn là "IsRoleEditor" ở trên nằm trong lớp giao diện người dùng của tôi và không phải trong một BLL? – Jay

+1

-1 Tôi không đồng ý: ủy quyền (cho dù thừa nhận vai trò hoặc một số cơ chế khác) có chắc chắn là trách nhiệm của BLL không. Tầng giao diện người dùng có thể đang chạy trên máy khách (ví dụ: Winforms) để có thể bị xâm nhập. – Joe

+0

Nó thực sự tất cả phụ thuộc vào cách bạn đang thiết kế ứng dụng này. Hãy cho chúng tôi một ví dụ về giải pháp của bạn, một cái gì đó đơn giản chỉ là tên dự án và cách chúng tham chiếu lẫn nhau. – dmportella

0

Tại sao không chuyển vai trò vào BLL của bạn để bạn không phụ thuộc vào tư cách thành viên. Hoặc sử dụng một giao diện như MartinB đề nghị.

Điều gì xảy ra trong tương lai khi người giữ cổ phần của bạn quyết định đi theo một hình thức xác thực khác và bạn không còn làm việc với đối tượng Vai trò nữa?

Ví dụ:

IsRoleEditor(User user, string[] roles) 
{ 
    return roles.Contains("ModifyRoles"); 
} 
0

Bạn không bị thiếu điểm MVC. MVC phân chia tính tự nhiên thành các tầng. Model (DAL), bộ điều khiển (BLL), View (Presentation). Chúng có thể đi trong các dự án khác nhau nếu bạn thích nhưng khi bộ điều khiển có tất cả logic nghiệp vụ - bạn chỉ cần truy cập RoleProvider ở đó.

Sau đó áp dụng các mẫu như kho, mẫu, v.v. để tách ra xa hơn nếu bạn muốn.

Davy

+0

Tôi hiểu khái niệm về MVC nhưng sau đó nếu tôi thiết lập BLL để chứa xác nhận Vai trò thì tại sao "Khả năng [Cấp quyền (Vai trò =" SomeRoleName ")]" trong giao diện người dùng? – Jay

+0

@jay thuộc tính Authorize được sử dụng trong bộ điều khiển, theo Davy cho biết đó sẽ là Lớp nghiệp vụ. Tôi nghĩ rằng những gì ông đang lái xe là bạn dường như được bỏ qua thực tế là các "lớp" đã được phân chia theo mô hình MVC. Tôi nghĩ rằng tất cả phụ thuộc vào cách bạn đang tái cấu trúc giải pháp này Jay, bạn có thể làm một sơ đồ để cho chúng ta thấy làm thế nào bạn đang thiết kế này? – dmportella

+0

Sơ đồ sẽ giúp ích. Bạn có nghĩa là UI capabulity như trong quan điểm? Nếu bạn làm thế, tôi nghĩ thật tuyệt khi chỉ có HTML ngu ngốc nhưng bạn có một cái nhìn mà bạn muốn hiển thị một cái gì đó dựa trên vai trò như 'hộp kiểm được ủy quyền' mà chỉ người giám sát mới có thể nhìn thấy trong một chế độ xem được chia sẻ khác. Vì vậy, việc có thể truy cập các vai trò ở đây hữu ích theo ý kiến ​​của tôi. – Davy

0

Để gọi bộ điều khiển MVC 'UI' là cách tắt dấu .. Các 'C' trong MVC là phần của BLL của bạn, ngay cả khi nó tham chiếu lớp bạn sẽ gọi BLL. Tuy nhiên, đó không phải là điểm của câu hỏi của bạn.

Tôi nghĩ rằng tôi sẽ giải quyết vấn đề này bằng cách đặt câu hỏi, "có yêu cầu thực sự cho việc tách 100% ứng dụng 'Giao diện người dùng' của bạn và 'BLL' của bạn không?". Nếu cả hai thành phần chia sẻ một sự phụ thuộc vào các nhà cung cấp thành viên/vai trò, thì hãy để nó như vậy và làm việc.

Trong trường hợp bạn rút phích cắm BLL của bạn và cắm vào một cái mới, có lẽ có sự phụ thuộc được chia sẻ trên một nhà cung cấp .NET là thứ bạn có thể sống cùng. Bạn biết đó có lẽ là ok và ứng dụng của bạn chỉ có thể không sụp đổ.

Tôi nghĩ rằng câu trả lời của Joe trên làm cho nhiều ý nghĩa mặc dù ...

+1

Không chắc chắn bộ điều khiển là một phần của BLL của bạn, infact, tôi nghĩ rằng nó không nên chứa bất kỳ logic kinh doanh, chỉ cần dàn nhạc giữa các đối tượng miền của bạn. –

+0

WTF là logic kinh doanh không? Toàn bộ ứng dụng là logic nghiệp vụ, bao gồm các thành phần khác nhau của logic nghiệp vụ .. phần UI của logic, phần MVC của logic .. có mã của bạn được cấu trúc và trừu tượng đúng là mục đích, không áp dụng tên chung cho các thành phần phức tạp . Ý tưởng của các lớp thẳng lên và xuống này là ngu xuẩn. Một sơ đồ giải pháp là một bản đồ phức tạp của các đối tượng, và đối phó với việc vượt qua là công việc của chúng ta - vấn đề của Jay là một vấn đề tốt, giao dịch với các phụ thuộc sẽ là một nhiệm vụ thú vị .. Tôi vẫn nghĩ câu trả lời của Joe có ý nghĩa nhất và bây giờ Tôi chỉ ranting thôi. – misteraidan

0

Tôi nghĩ rằng những gì bạn đang làm là tốt.

Uỷ quyền và xác thực phải nằm trong lớp dịch vụ, có thể được chuyển vào bộ điều khiển của bạn.

Nếu bộ điều khiển thiết lập chính và danh tính và sau đó bạn sử dụng điều đó trong bộ điều khiển thông qua việc sử dụng các thuộc tính MVC thì có vẻ như đó là một ý tưởng hay. Nó sẽ là tốt đẹp để ẩn nhà cung cấp thành viên MVC của bạn phía sau một giao diện, theo cách đó bạn có thể trao đổi nó ra cho một nhà cung cấp thành viên WinForms (ví dụ) và sẽ có thể đơn vị kiểm tra bộ điều khiển của bạn.

Các vấn đề liên quan