Tại sao tôi nên mã hóa quyền người dùng trong các thuộc tính điều khiển của mình?

Question

Tôi đã thấy mã ví dụ trông như thế này, mà dường như hoàn toàn hợp lý:

[Authorize(Roles = "Admin, User")] 
public class SomeController : Controller 

Nhưng tôi cũng đã thấy một số ví dụ mà trông như thế này:

[Authorize(Users = "Charles, Linus")] 
public class SomeController : Controller 

Tại sao tôi đã bao giờ muốn làm điều này? Tôi không thể tưởng tượng bất kỳ kịch bản nào mà tôi muốn xây dựng một hệ thống biết trước tên người dùng của nó.

Answer 1

Có một vài cách sử dụng hợp pháp, và đây là một ví dụ: Nếu bạn xây dựng một trang web thực sự đơn giản, chỉ cần có tài khoản quản trị và tài khoản chưa được xác thực, bạn có thể làm

[Authorize(Users = "Admin")] 

Điều này giúp bạn không phải lo lắng về việc xây dựng vai trò cho một người dùng. Hãy nghĩ kiểu UNIX, trong đó tài khoản gốc (uid 0) đặc biệt hơn là một nhóm cụ thể.

Ví dụ khác chỉ đơn giản là một ứng dụng ném đi, nơi bạn đang thử nghiệm điều gì đó. Không có lý do để bận tâm với vai trò nếu bạn chỉ muốn kiểm tra trang xác thực của bạn hoặc một cái gì đó như thế.

Một lý do nữa: thử nghiệm. Bạn có thể xây dựng một bài kiểm tra đơn vị chỉ để xác thực của bạn mà không muốn đơn vị kiểm tra khuôn khổ dựa trên vai trò của bạn. (Lưu ý, không phải ai cũng sử dụng nhà cung cấp thành viên mặc định, và một số nhà cung cấp thành viên khá tinh vi.) Bằng cách tạo xác thực mã hóa cứng cho người dùng thử, bạn có thể bỏ qua khung vai trò.

Answer 2

Bạn sẽ không, mã hóa người dùng là mùi hôi. Vai trò tồn tại cho những thứ như thế.

Chỉnh sửa: Tôi tin rằng, giống như khi .net 1.0 nhấn với toàn bộ web.config với quyền cho phép/từ chối, đó là (hoặc ít nhất NÊN CHỈ) được sử dụng làm ví dụ sốt, thậm chí tho tôi vào đống của những người tin rằng blog, hướng dẫn và mẫu chỉ nên sử dụng các phương pháp hay.

Answer 3

Lý do "hợp pháp" duy nhất để làm điều đó tôi có thể nghĩ đến là xây dựng cửa sau - cho mục đích bất chính hoặc để "bảo trì trong tương lai". Sau này là Bad Juju vì nó giới thiệu nguy cơ bảo mật. Trước đây là Bad Juju cũng dĩ nhiên :)

Answer 4

Một vài lý do bạn có thể xem xét làm việc đó:

1. Ứng dụng này được dự kiến ​​sẽ có một vòng đời rất ngắn và không bảo trì là bắt buộc.
2. Người dùng được đề cập có thể không thuộc về nhóm được xác định đầy đủ (như trong trường hợp của một doanh nghiệp nhỏ) và không có thay đổi được mong đợi. (vẫn thiết kế rất xấu, nhưng nó sẽ không nghe)
3. Bạn có thể phải nhiều quá tải trong một ứng dụng nhỏ mà yêu cầu hành vi khác nhau cho các cá nhân trong một nhóm .

Trong bất kỳ trường hợp nào, thiết kế đều bị hỏng và bạn sẽ không muốn làm điều đó. Nhưng giao diện là có bởi vì nó là mức kiểm soát đơn giản nhất.

Answer 5

Tôi đồng ý với David Pfeffer. Ngoài ra tôi nghĩ rằng bạn có thể xác định một tập hợp người dùng với các quyền và công việc rất cụ thể trong ứng dụng của bạn - mục đích thử nghiệm, có lẽ theo dõi hiệu quả ... bạn sẽ biết khi yêu cầu gõ cửa;) -.

Chỉ cần một nhóm không được cho là chứa trong nhóm người dùng hợp lệ được ứng dụng của bạn sử dụng. :) -the hardcore way-