精通 Logto 中的 RBAC:一個全面的實際範例
本文提供了一個關於掌握 Logto 中基於角色的訪問控制 (RBAC) 的全面指南,使用一家線上書店的實際範例來探索主要的用戶角色、範圍,以及在前端和後端應用中整合 Logto 的 RBAC 功能以增強安全性和訪問控制。
介紹
訪問控制和安全性是現代應用程式的關鍵要素,確保用戶擁有適當的資源訪問權限。Logto 的基於角色的訪問控制 (RBAC) 提供給開發者一種高效管理應用程式中訪問控制和安全性的方法。在本文中,我們將通過一個實際的範例來探索 Logto 的 RBAC 實現的強大功能,幫助你理解和應用這些概念到你的專案中。
通過檢查前端和後端的程式碼片段,你將獲得整合 Logto 的 RBAC 到你的應用程式堆栈的全面視角。到本文結束時,你將能夠利用 Logto 的 RBAC 功能來增強你專案的安全性和訪問控制。
介紹 BookHarber:一個線上書店的用例
為了有效展示 Logto 的 RBAC 功能,我們將使用一個實際的範例:BookHarber,一家線上書店。BookHarber 為顧客和員工提供了廣泛的功能,確保無縫且安全的購物體驗。
BookHarber 的主要功能包括:
- 瀏覽和購買圖書:用戶可以輕鬆搜尋和購買來自不同類型和作者的廣泛書籍收藏。
- 訂單管理和物流跟踪:註冊用戶可以管理他們的訂單,追踪運送,並收到他們購買的更新。
- 特別優惠和假日活動:BookHarber 在特殊事件和假日期間提供獨家折扣和促銷活動,以吸引和獎勵其顧客群。
- 客戶支援:顧客可以開啟支援票據來解決他們可能遇到的任何問題或疑慮,並從 BookHarber 員工獲得迅速的協助。
- 客戶管理:具備不同角色的員工可以管理平台的各個方面,例如客戶賬戶,訂單處理和問題解決。
角色
在 BookHarber 生態系統中,我們可以識別出幾個主要的用戶角色,例如:
- 訪客:未註冊用戶,可以瀏覽網站、搜尋書籍和查看特別優惠。
- 顧客:註冊用戶,可以購買書籍、管理訂單、追踪物流及開啟支援票據。
- 商店管理員:負責監督平台整體管理與運營的員工。擁有完全的訪問權。
- 書籍管理員:負責書籍和類別管理的員工。
- 客戶服務代理:負責回應支援票據的員工。
- 第三方物流供應商:負責管理和跟踪訂單運送和交付的外部合作夥伴。
- 市場行銷人員:負責推廣 BookHarber,負責管理特別優惠和活動的員工。
設計 BookHarber REST API 的範圍
為了有效實現 Logto 的 RBAC 系統,我們需要設計與各個 REST API 對應的範圍。範圍是定義特定角色對每個 API 端點的訪問級別的權限。通過將適當的範圍分配給每個用戶角色,我們可以確保用戶只訪問與其角色相關的操作和資源。
讓我們為以下 REST API 設計範圍:
- Categories API:
create:categories
: POST /categorieswrite:categories
: PUT /categories/:iddelete:categories
: DELETE /categories/:idlist:categories
: GET /categories
- Books API:
create:books
: POST /bookswrite:books
: PUT /books/:iddelete:books
: DELETE /books/:idlist:books
: GET /booksread:books
: GET /books/:id
- Customers API:
list:customers
: GET /customerswrite:customers
: PUT /customers/:iddelete:customers
: DELETE /customers/:idread:customers
: GET /customers/:id
- Orders API:
create:orders
: POST /orderslist:orders
: GET /ordersread:orders
: GET /orders/:idwrite:orders
: PUT /orders/:id
- Events API:
create:events
: POST /eventswrite:events
: PUT /events/:idlist:events
: GET /eventsdelete:events
: DELETE /events/:id
- Order Tracks API:
read:orderTracks
: GET /orders/:id/trackscreate:orderTracks
: POST /orders/:id/trackswrite:orderTracks
: PUT /orders/:id/tracks/:trackId
- Tickets API:
create:tickets
: POST /ticketslist:tickets
: GET /ticketsread:tickets
: GET /tickets/:idwrite:tickets
: PUT /tickets/:id
為角色分配範圍
現在我們已經為每個 REST API 定義了適當的範圍,我們可以將這些範圍分配給 BookHarber 生態系統中的相應用戶角色:
Scopes | Guest | Customer | Store Admin | Books Manager | Customer Service Agent | Third-Party Logistics Provider | Marketing Staff |
---|---|---|---|---|---|---|---|
create:categories | ✓ | ✓ | |||||
write:categories | ✓ | ✓ | |||||
delete:categories | ✓ | ✓ | |||||
list:categories | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
create:books | ✓ | ✓ | |||||
write:books | ✓ | ✓ | |||||
delete:books | ✓ | ✓ | |||||
list:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
read:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
list:customers | ✓ | ✓ | |||||
write:customers | ✓ | ||||||
delete:customers | ✓ | ||||||
read:customers | ✓ | ✓ | |||||
create:orders | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
list:orders | ✓ | ||||||
read:orders | ✓ | ✓ | |||||
write:orders | ✓ | ||||||
create:events | ✓ | ✓ | |||||
write:events | ✓ | ✓ | |||||
list:events | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
delete:events | ✓ | ✓ | |||||
read:orderTracks | ✓ | ✓ | ✓ | ||||
create:orderTracks | ✓ | ✓ | |||||
write:orderTracks | ✓ | ✓ | |||||
create:tickets | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
list:tickets | ✓ | ✓ | |||||
read:tickets | ✓ | ✓ | |||||
write:tickets | ✓ | ✓ |
理解 "list" 和 "read" 範圍之間的區別
為了進一步說明在 REST API 設計和 RBAC 中 "list" 和 "read" 範圍之間的區別,讓我們考慮一個涉及線上書店 BookHarber 的實際範例。
假設 BookHarber 有兩種類型的用戶:顧客和客戶服務代理。顧客可以創建訂單,而客戶服務代理負責幫助顧客處理訂單。讓我們看看 "list" 和 "read" 範圍如何應用於 orders
API 資源中的這種情況。
- List 範圍:"list" 範圍允許用戶訪問系統中的實體集合。例如,
list:orders
範圍允許用戶檢索所有可用訂單的列表。在 BookHarber 的情境中,這個範圍可以對於需要了解系統中所有訂單概覽的商店管理員或其他員工有用。然而,客戶服務代理不應該能夠訪問所有訂單,因為他們的角色是協助個別顧客工作。 - Read 範圍:"read" 範圍授予用戶許可權以訪問具有特定 ID 的單個實體。例如,
read:orders
範圍允許用戶根據其 ID 查看特定訂單的詳細信息。在 BookHarber 的情境中,這個範圍對需要訪問特定顧客訂單信息的客戶服務代理非常理想。當顧客開啟一個支援票據時,客戶服務代理可以使用票據中提供的訂單 ID 來訪問和查看該特定訂單的詳細信息。