權限系統怎麼設計提示詞（RBAC 角色權限表結構、選單與按鈕權限、數據權限）
做管理後台、SaaS 或內部系統需要設計權限模組時用：讓 AI 根據組織結構和權限需求設計 RBAC 模型，覆蓋功能權限（選單、按鈕、接口）和數據權限（只能看本部門、只能看自己的），給出表結構、鑑權流程和常見越權漏洞的檢查清單。
通用大模型 對話模型通用
你是一名做過多個企業級後台權限系統的架構師。請幫我設計權限模組。 需求： - 系統類型：[如內部運營後台、多租戶 SaaS] - 組織結構：[如公司、部門、小組三級；有沒有多租戶] - 角色舉例：[如超級管理員、部門經理、客服、財務] - 需要控制的功能：[如選單可見、按鈕可點、接口可調用] - 數據範圍的要求：[數據範圍的要求]（例：客服只能看自己負責的客戶、經理能看本部門及下級） - 特殊需求：[如臨時授權、權限審批、操作審計] - 技術棧：[技術棧]（例：Spring Boot + MySQL + Vue） 請輸出： 1. 模型選擇：基礎 RBAC 是否夠用；什麼情況下需要角色繼承、用戶組、基於屬性的規則（ABAC）作為補充；不要為了「完整」引入用不到的複雜度。 2. 功能權限設計：權限點的粒度與命名規則（如「模組:資源:操作」），選單、按鈕、接口三類權限如何對應；前端只負責顯示隱藏，真正的攔截必須在後端。 3. 數據權限設計：數據範圍的幾種類型（全部、本部門、本部門及下級、僅本人、自定義），如何在查詢中統一注入過濾條件，而不是在每個接口裏手寫。 4. 表結構：建表語句，包括用戶、角色、權限、用戶角色關聯、角色權限關聯、數據範圍配置；多租戶時每張表如何隔離。 5. 鑑權流程：一次請求從認證到功能鑑權、數據過濾的完整流程；權限緩存在哪裏、修改權限後如何及時生效。 6. 管理功能：角色的增刪改、權限分配介面的交互建議、防止管理員把自己鎖在門外。 7. 安全檢查清單：水平越權（改 URL 裏的 ID 訪問別人的數據）、垂直越權（普通用戶調用管理員接口）、批量接口和導出接口的數據範圍、權限修改本身的審計日誌。 每個設計決定附一句理由。
高亮處換成你自己的內容：[如內部運營後台、多租戶 SaaS]、[如公司、部門、小組三級；有沒有多租戶]、[如超級管理員、部門經理、客服、財務]、[如選單可見、按鈕可點、接口可調用]、[數據範圍的要求]、[如臨時授權、權限審批、操作審計]、[技術棧]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[數據範圍的要求] 是權限系統裏最容易被低估的部分。功能權限（能不能點這個按鈕）大家都會想到，但「能看到哪些數據」往往到開發後期才發現需要，到時候每個查詢都要返工。
常見坑：
- 只在前端隱藏按鈕，後端接口不做校驗。任何人用接口調試工具都能直接調用。
- 數據權限在每個接口裏手寫過濾條件，總會有遺漏，尤其是導出、統計、批量操作這些「非主流程」接口。
- 權限放在登入令牌裏且有效期很長，管理員撤銷了某人的權限，對方在令牌過期前仍能操作。
追問技巧：設計完成後追問「列出 10 個具體的越權測試用例（包括導出接口和批量接口）」，交給測試同學執行。也可以追問「如果以後要支持某個用戶臨時代理另一個人的權限，現有設計要怎麼擴展」。
示例輸出
示例，僅供參考（節選）
權限點命名：customer:list:view、customer:detail:edit、order:refund:approve
sql
CREATE TABLE role_data_scope (
role_id BIGINT NOT NULL,
resource VARCHAR(64) NOT NULL, -- 如 customer
scope_type VARCHAR(32) NOT NULL, -- ALL / DEPT / DEPT_AND_CHILDREN / SELF / CUSTOM
PRIMARY KEY (role_id, resource)
);| 角色 | 客戶數據範圍 | 說明 |
|---|---|---|
| 客服 | SELF | 只看負責人是自己的客戶 |
| 部門經理 | DEPT_AND_CHILDREN | 通過部門路徑字段做前綴匹配查詢 |
| 財務 | ALL（只讀） | 沒有編輯權限點 |
數據過濾：在數據訪問層統一攔截查詢，根據當前用戶角色的 scope_type 拼接過濾條件；導出接口複用同一套邏輯。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～