SharePoint 2007 - RunWithElevatedPrivileges - Cạm bẫy khi sử dụng này

Question

Tôi có cảm giác mạnh mẽ khi sử dụng SharePoint RunWithElevatedPrivileges nên tránh như bệnh dịch hạch, nhưng cần phải thuyết phục một số người khác biết chính xác lý do. Đây là những gì tôi có.

• Tạo ra một chủ đề mới với quyền cao
• Khối các hoạt động khác cho đến khi các đại biểu đã thông qua trả
• vấn đề an ninh (chạy với một mức độ cao về đặc quyền, có lẽ bởi một người dùng cuối)
• người khác?

Answer 1

lý do để nâng cao rơi vào hai loại:

1. Mã của bạn cần thực hiện các hoạt động trong SharePoint mà người dùng hiện nay không có quyền. Điều này phải luôn được thực hiện khi làm việc với Bảo mật SharePoint, không phải là biện pháp "chỉ trong trường hợp" cho biết bạn cần hiểu rõ tình trạng bảo mật của mình tốt hơn.
2. Mã của bạn cần truy cập các tài nguyên bên ngoài (hệ thống tệp máy chủ, cơ sở dữ liệu, chia sẻ tệp, v.v ...) mà bản sắc của hồ bơi ứng dụng có quyền truy cập nhưng người dùng hiện tại thì không.

Trước đây, bạn nên sử dụng SPSite impersonation tốt hơn. Lý do thứ hai là lý do duy nhất tôi sử dụng RWEP.

Để làm rõ, RWEP không sinh ra một chuỗi mới. Thay vào đó, nó sử dụng API Win32 để hoàn nguyên danh tính của chuỗi hiện tại trở lại danh tính quy trình (tắt mạo danh) để chạy mã nâng cao, sau đó chuyển tiếp mạo danh để tiếp tục hoạt động thay mặt cho người dùng hiện tại. Này có một số ý nghĩa:

1. RWEP không có gì nếu thread không được mạo nhận, vì vậy nó là vô ích trong công việc hẹn giờ, công việc Visual Studio, giao diện điều khiển ứng dụng, và mã chạy qua stsadm (thu tính năng).
2. Truy cập vào SharePoint, giả sử bạn tạo SPSite mới trong CodeToRunElevated, sẽ được thực hiện với quyền của nhóm ứng dụng (SHAREPOINT \ system). Tài khoản này sẽ có toàn quyền truy cập vào ứng dụng web hiện tại, nhưng không được có quyền cấp độ trang trại để thực hiện những việc như sửa đổi thuộc tính SPFarm hoặc thực hiện thay đổi đối với SSP.
3. Sử dụng các đối tượng nhận dạng nhận dạng (như SPSite và các con của nó) trên các ranh giới thực thi của CodeToRunElevated của bạn có khả năng gây ra một số hành vi và điều kiện cuộc đua thực sự sôi nổi. Đối với tất cả các ý định và mục đích, hãy xem xét điều này không được hỗ trợ.

Và như Alex đã nói, trẻ em của SPSite kế thừa quyền của chúng từ SPSite, lần lượt có quyền được đặt khi được tạo. Vì vậy, SPContext.Current.Site vẫn sẽ hành xử với các điều khoản của người dùng hiện tại ngay cả khi bạn tham chiếu nó trong CodeToRunElevated của bạn. Thay vào đó, bạn sẽ cần phải tạo và tiêu thụ một SPSite mới trong khối được nâng lên.

Để tóm tắt: RWEP để mạo danh App Pool bên ngoài SharePoint, mạo danh SPSite để mạo danh App Pool bên trong SharePoint.

Answer 2

RWEP, giống như mọi thứ khác, có ưu và khuyết điểm.

Nếu bạn quan tâm đến người dùng cuối đang chạy RWEP, có thể bạn đã gặp phải vấn đề lớn hơn, vì mã đó đã được cài đặt trên GAC.

Đôi khi, bạn chỉ cần gắn bó với nó: xem xét người dùng không có quyền quản trị, chạy quy trình làm việc của tài liệu. Sau khi người dùng này chấp nhận (hoặc từ chối, không quan trọng), công cụ luồng công việc của bạn sẽ có thể xác định lại các đặc quyền của SPListItem.

Answer 3

Tôi sử dụng nó và thấy nó là chức năng rất hữu ích. Theo quan điểm của tôi, tôi chọn để người dùng chạy mã của tôi và có mã đó làm những thứ mà người dùng không thể làm bình thường. Bạn có thể khóa một cái gì đó xuống, và vẫn cho phép người dùng truy cập nó một cách rất có kiểm soát.

Answer 4

1) Sử dụng đáng kể RWEP là dấu hiệu tốt về mùi mã. Nó có thể dễ dàng bị lạm dụng mà không có suy nghĩ dẫn đến các vấn đề an ninh nghiêm trọng. Nhiều nhà phát triển không nghĩ về những gì người dùng có thể làm với sức mạnh mà họ đang gián tiếp được đưa ra "dưới mui xe".

Chỉ cần một ví dụ: điều quan trọng là gọi ValidateFormDigest trước khi sử dụng RWEP đến prevent malicious requests in application pages.

---

2) Các đối tượng SPWeb và SPSite cần được tạo trong ngữ cảnh RWEP. Điều này là dễ dàng cho các nhà phát triển mới làm quen để quên, dẫn đến nhiều thất vọng.

Hạn chế này cũng có nghĩa là tất cả công việc và bất kỳ đối tượng nào được tạo bởi các đối tượng này phải được sử dụng và kết thúc trước khi kết thúc đại biểu RWEP. Đây là một sai lầm phổ biến khác.

Keith Dahlby đã viết extension methods để giải quyết các vấn đề này, cung cấp mã mạnh mẽ và dễ đọc hơn.