就像標題所說的，我被要求提出一個改進現有asp應用程序的估計。在經典的asp應用程序中改進記錄級訪問限制
當前安全機制控制對應用程序不同部分的訪問（頁面級限制），但沒有將單個記錄標記爲受限制的機制。爲用戶分配權限（使用現有的自定義訪問管理代碼）是沒有問題的，但是強制執行權限是另一回事 - 每個asp頁面都嵌入了sql - 沒有使用存儲的特效，對象等。
是修改每個表和查詢的唯一解決方案，還是有更好的方法？任何指針，建議或祈禱將受到歡迎。
這是在IIS6上運行的經典asp，針對oracle數據庫。
更新：這是一個用戶場景。
我們有用戶，經理，董事和副總裁。經理可以看到由向其報告的用戶創建的數據，但不會向其他經理報告。用戶無法查看任何管理員創建的數據。與董事一樣 - 他們可以看不起，但他們的報告看不到。
假設你需要最大的粒度，能夠「授予」任何非常多用戶的每一行，那麼你有一個多對多的關係，是嗎？
所以應用以下模式：
添加用戶表。
然後，對於每個限制表，所以下面：
將其重命名錶名+ 「_base」。
創建多到多表關聯 該表的一個 用戶的ID，叫做表名+ 「allowed_user」。
創建與聯接tablename_base到 table_name_allowed_user名稱表 名稱的視圖，具有 SELECT * FROM tablename_base和tablename_allowed_user USER_ID。 這個視圖應該符合Oracle的 的要求rto是「固有的 可更新」。
現在到了困難的部分。您需要爲每個查詢添加「和user_id = $ user_id」。查找您用於查詢的各種功能。將這些函數包裝在從會話獲取用戶標識並添加謂詞的函數中。
一個可行的方法是讀取選擇字符串，找到所有「where」（對於子查詢可能多於那個），並將其替換爲「where（user = $ user）and」。對於沒有where的查詢，您需要在任何「group by」或「order by」之前插入。這很脆弱，所以很明顯你會測試它適用於所有頁面（你對所有頁面都有一個自動測試，對吧？），並且添加黑客來覆蓋特殊情況。
「update」語句不會改變; 「插入」可能會插入到視圖中，然後使用插入用戶的ID對錶的「allow_user」表單獨插入，以自動授予將插入的用戶訪問權限插入到他所插入的內容中。
如果您的用戶數量更有限，或者您限制了用戶類型，則可以使用爲用戶或類型命名的多個視圖策略;那麼你會用適當的視圖替換查詢中的表名。
這聽起來像是實現行級安全的理想時間。 Oracle有一個包DBMS_RLS，它允許您定義可應用於一個或多個表的任意訪問策略，以限制特定用戶允許查看的行。從概念上講，當用戶自動發出與一個受保護的表沒有過濾器的查詢，即
SELECT *
FROM my_table
Oracle和透明地插入WHERE子句通過限制結果集安全策略定義。您不需要對應用程序正在執行的SQL進行任何更改。
不同的用戶，或不同類型的用戶？換句話說，在什麼粒度水平上？ – tpdi 2009-04-17 04:32:51