我與開發人員就用戶登錄並訪問Web應用程序中的文檔的情況進行了友好辯論。當我們加載文檔供用戶查看時，我們有會話中的用戶ID和可以通過QueryString傳遞的documentID。用戶訪問權限檢查特定數據庫對象或記錄的權限
爲了防止用戶修改QueryString上的documentID，我建議加載文檔的存儲過程將UserId作爲參數來驗證文檔的權限。
我的開發人員朋友建議我們運行一個單獨的過程來確定頁面前面的文檔的訪問權限，並且只需運行一個過程以在顯示文檔時抓取文檔。
我們錯過了什麼嗎？哪個最有效和最安全？我認爲將帶有DocID的UserId傳遞給一個過程調用來檢查權限，並將文檔拉到一個更有效的解決方案。
嚴格地說，從性能的角度來看，將UserID和DocumentID一起傳遞到一個存儲過程將是最好的。您只需往返數據庫服務器一次。另外，正如其他人指出的那樣，如果您將從其他頁面或應用程序中檢索此文檔，並且您使用相同的存儲過程，則可確保您不會繞過安全性。
但是，有些情況下專用安全驗證存儲過程是有意義的。如果除了文檔之外還有其他資源需要保護，並且您的驗證代碼不是微不足道的，則可能不希望在數據庫中的每個存儲過程中複製驗證代碼。在這種情況下，將安全性基礎架構移出到數據訪問層可能有意義，並且在檢索請求的資源之前讓數據訪問層調用db調用來授予訪問權限。如果採取這種方式，您不希望依賴開發人員在請求資源之前始終要記住進行授權數據庫調用。
userID應該是一個會話變量。對。在查詢字符串中傳遞documentID。對。
假設文檔存儲在數據庫中，我將擁有一個權限表：recordID userID和documentID。調用文檔時，您會與此表進行連接。如果你沒有得到結果，你不會得到文件。索引一切很好，它會很快。
我建議加載該文件採取 用戶ID作爲參數的存儲過程 驗證 權限的文件。
我覺得這是要走的路。如果沒有其他原因而不是安全。如果你重新使用這個過程，然後忘記檢查訪問 - 你已經打開了一個大洞。這種方式很明顯，因爲除非有權訪問，否則無法訪問文檔。