Làm thế nào để biết người dùng thực hiện hành động xóa trên bảng kiểm toán, khi sử dụng đăng nhập được chia sẻ?

Thông tin lai lịch:

• Tôi đang tạo một tập hợp các bảng kiểm toán để theo dõi các cập nhật và xóa vào một tập hợp các bảng dữ liệu cho ứng dụng của tôi.
• Hồ sơ kiểm toán được tạo ra thông qua kích hoạt.
• DML trong cơ sở dữ liệu của ứng dụng của tôi thường sẽ đến từ thông tin đăng nhập mà dịch vụ sử dụng để truy cập vào cơ sở dữ liệu. Bởi vì điều này, tôi nghĩ rằng kết quả từ SYSTEM_USERsẽ luôn giống nhau khi được gọi trong một kích hoạt.
• Ứng dụng của tôi hiện không lưu trữ dữ liệu người dùng, mặc dù một chuỗi UserIdđược cung cấp cho nó mỗi khi DML được thực hiện (được thực hiện riêng trong các thủ tục được lưu trữ).

Vấn đề tôi gặp phải là khi người dùng xóa một bản ghi, tôi muốn biết ai đã làm nó. Bởi vì nó sẽ được thực hiện bằng cùng một thông tin đăng nhập, tôi không muốn thấy rằng tất cả các hành động đã được thực hiện bởi dịch vụ, tôi muốn xem người dùng nào đã làm điều đó. Đây không phải là vấn đề về bản cập nhật, bởi vì chúng tôi có ModifiedBycác cột sẽ được cập nhật thông qua việc gửi trong các UserIdbản cập nhật.

Câu hỏi là: Có cách nào để thiết lập SYSTEM_USERhoặc lấy thông tin người dùng vào trình kích hoạt khi xóa không?

Ý tưởng "tốt nhất" tôi có ngay bây giờ, mặc dù tôi không chắc đó có phải là ý tưởng hay không, đó là trong dịch vụ tôi kiểm tra xem liệu dòng điện UserIdcó trong cơ sở dữ liệu với tư cách là người dùng không và nếu không tạo người dùng đối tượng cho họ. Sau đó chạy thủ tục lưu trữ với EXECUTE AS User = @UserId. Sau đó, khi DML được thực hiện trong thủ tục được lưu trữ và kích hoạt kích hoạt, SYSTEM_USERsẽ trả về người dùng từ EXECUTE AS.

Mặc dù sử dụng EXECUTE AS User = @UserIdcó thể là lựa chọn tốt nhất của bạn (tùy thuộc vào các vấn đề khác), đây là một cách tiếp cận khác:

Trong các thủ tục được lưu trữ của bạn hoặc bất cứ lúc nào trong phiên SQL của bạn trước khi bạn DELETEthực hiện lệnh sau:

SET CONTEXT_INFO @UserId

Sau đó, trong Kích hoạt của bạn, bạn có thể truy xuất giá trị này với

SELECT @var = CAST(CAST(CONTEXT_INFO() As Varbinary(4)) As Int)

Điều này có một số nhược điểm, trong đó quan trọng nhất là bạn không thể dễ dàng sử dụng CONTEXT_INFO cho nhiều thứ cùng một lúc.

Tùy thuộc vào cách bạn thay đổi bối cảnh người dùng từ đăng nhập cá nhân sang đăng nhập dịch vụ, bạn có thể thấy rằng ORIGINAL_LOGIN () hữu ích.

http://technet.microsoft.com/en-us/l Library / ms189492.aspx

"Hàm này có thể hữu ích trong việc kiểm tra danh tính của bối cảnh kết nối ban đầu. Trong khi đó, các hàm như SESSION_USER và CURRENT_USER trả về bối cảnh thực thi hiện tại, ORIGINAL_LOGIN trả về danh tính của thông tin đăng nhập được kết nối lần đầu với phiên bản SQL Server trong phiên đó."

Bạn cũng có thể thử thêm Host_Namevào bảng của bạn. Tôi đã tìm thấy trong các tình huống đăng nhập được chia sẻ, tôi thường có thể theo dõi một cá nhân bằng tên máy của họ vì 95% thời gian một người làm việc từ máy của họ. Nó không phải lúc nào cũng hoạt động, nhưng nó có thể là một thông tin thứ cấp hữu ích.

SELECT host_name FROM sys.dm_exec_sessions WHERE session_id = @@SPID

Thật không may, điều này sẽ không hoạt động nếu bạn đang làm việc với một ứng dụng web, nơi máy chủ luôn luôn là ứng dụng web nhưng nó có thể đáng để thử.