共用帳號，分開資料存取權限

多個應用共用登入，可以簡化使用體驗；每個應用、員工與客戶仍有不同的資料責任。

我為電商平台的員工與客戶流程實作分層存取邊界。本文以通用名稱說明設計，省略部署配置與客戶資料。

三種檢查回答不同問題

隱藏按鈕不會保護伺服器端點。Server action 必須先驗證登入與操作權限，再呼叫共用邏輯。資料庫授權則獨立限制應用連線能做的事，不受畫面是否顯示某個功能影響。

對於屬於個別客戶的紀錄，PostgreSQL 列級安全性依已驗證的身分限制資料。查詢本身仍會加上適當條件；列級政策提供另一層邊界，處理呼叫端漏掉條件的情況。

身分只存在於當次交易

連線池會重用資料庫連線。如果把使用者身分設在整個 session 上，該設定可能在原始請求結束後繼續存在。

客戶資料包裝層先開啟交易，將已驗證的帳號設為 transaction-local 設定，再讓共用資料函式使用同一個交易。簡化流程如下：

已驗證的登入狀態
  → 開始資料庫交易
  → 設定當次交易的帳號身分
  → 執行受限資料查詢
  → 提交或回滾

列級政策比對紀錄擁有者與當次身分。沒有身分時，不會匹配任何客戶資料列；包裝層也拒絕意外繞過範圍設定的呼叫。

身分必須來自已驗證的登入資訊。若直接接受請求傳來的帳號 ID，只是把資料歸屬問題搬到資料庫設定裡。

使用受限角色測試

Superuser 可以繞過列級安全性，因此用該角色通過測試，不能證明應用實際使用的邊界成立。

整合測試建立不同客戶，並以受限角色連線，驗證客戶可以讀寫自己的紀錄、無法存取其他人的紀錄，以及缺少身分時讀不到資料。測試也檢查無關應用不能存取受保護資料。

員工的存取範圍不同。相關檢視與匯出會先寫入存取紀錄，再回傳資料；員工使用的資料庫角色無法修改或刪除該紀錄。這讓系統除了拒絕未授權操作，也能追查已授權能力由誰使用。