本文提供了一個全面指南，通過一個線上書店的實例，深入探討如何在 Logto 中掌握基於角色的訪問控制（RBAC），探索關鍵的用戶角色、範疇，以及在前端和後端應用中整合 Logto 的 RBAC 功能，以提升安全性和訪問控制。
訪問控制和安全性是現代應用程序的重要方面，確保用戶獲得適當的資源訪問權限。Logto 的基於角色的訪問控制（RBAC）為開發人員提供了一種有效的方式來管理應用程序中的訪問控制和安全性。在本文中，我們將通過一個現實世界的例子探索 Logto RBAC 的強大功能，幫助你理解並將這些概念應用到你的項目中。
通過分析前端和後端代碼片段，你將獲得將 Logto 的 RBAC 集成到你的應用程序堆棧中的全面視角。到本文結尾，你將能夠充分利用 Logto 的 RBAC 功能來增強你的項目的安全性和訪問控制。
為了有效展示 Logto 的 RBAC 功能，我們將使用一個線上書店的實例：BookHarber。BookHarber 為客戶和員工提供了一系列功能，確保流暢且安全的購物體驗。
BookHarber 的主要功能包括：
在 BookHarber 生態系統中，我們可以識別幾個關鍵用戶角色，例如：
為了有效實施 Logto 的 RBAC 系統，我們需要設計與各種 REST API 對應的範疇。範疇是定義特定角色對每個 API 接口的訪問級別的許可。通過將適當的範疇分配給每個用戶角色，我們可以確保用戶僅能訪問與其角色相關的操作和資源。
讓我們為以下 REST API 設計範疇：
create:categories: POST /categorieswrite:categories: PUT /categories/:iddelete:categories: DELETE /categories/:idlist:categories: GET /categoriescreate:books: POST /bookswrite:books: PUT /books/:iddelete:books: DELETE /books/:idlist:books: GET /booksread:books: GET /books/:idlist:customers: GET /customerswrite:customers: PUT /customers/:iddelete:customers: DELETE /customers/:idread:customers: GET /customers/:idcreate:orders: POST /orderslist:orders: GET /ordersread:orders: GET /orders/:idwrite:orders: PUT /orders/:idcreate:events: POST /eventswrite:events: PUT /events/:idlist:events: GET /eventsdelete:events: DELETE /events/:idread:orderTracks: GET /orders/:id/trackscreate:orderTracks: POST /orders/:id/trackswrite:orderTracks: PUT /orders/:id/tracks/:trackIdcreate:tickets: POST /ticketslist:tickets: GET /ticketsread:tickets: GET /tickets/:idwrite:tickets: PUT /tickets/:id現在我們已經為每個 REST API 定義了適當的範疇，我們可以將這些範疇分配給 BookHarber 生態系統中的相關用戶角色：
| 範疇 | 訪客 | 客戶 | 店鋪管理員 | 圖書管理員 | 客戶服務專員 | 第三方物流供應商 | 市場營銷員 |
|---|---|---|---|---|---|---|---|
| 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 | ✓ | ✓ |
為了進一步說明在 REST API 設計和 RBAC 中的 "list" 和 "read" 範疇之間的差異，讓我們考慮一個涉及線上書店 BookHarber 的實際示例。
假設 BookHarber 有兩類用戶：客戶和客戶服務專員。客戶可以創建訂單，而客戶服務專員則負責幫助客戶處理他們的訂單。讓我們看看在此場景中如何應用 orders API 資源的 "list" 和 "read" 範疇。
list:orders 範疇允許用戶檢索所有可用訂單的列表。在 BookHarber 中，這個範疇對於需要系統中所有訂單概覽的店鋪管理員或其他員工很有用。然而，客戶服務專員不應能夠訪問整個訂單列表，因為他們的角色是幫助個別客戶處理具體的訂單。read:orders 範疇允許用戶通過其 ID 查看特定訂單的詳細信息。對於 BookHarber 的情況，這個範疇非常適合需要訪問特定客戶訂單信息的客戶服務專員。當客戶開啟支持票據時，客戶服務專員可以使用票據中提供的訂單 ID 訪問並查看該特定訂單的詳情。在很多應用程序中，用戶通常能夠在未獲得相應的 "read" 或 "list" 範疇的情況下訪問自己的資源。這是因為用戶被視為這些資源的所有者，應自然能夠訪問它們。在我們的 BookHarber 例子中，客戶可以創建訂單但沒有 "read:orders" 或 "list:orders" 範疇。
所有權的概念在定義 REST API 特定資源的訪問控制中起著關鍵作用。通過承認用戶始終可以訪問自己的資源，我們可以實施更高效且安全的訪問控制，而無需授予不必要的許可。在 BookHarber 的情況中，這意味著客戶仍然可以查看和管理他們的訂單，而不需要任何附加的範疇。
為了演示這種工作原理，讓我們考慮 GET /orders Endpoint：
list:orders 範疇（例如，店鋪管理員或員工），他們將能夠查看系統中的所有訂單。這為他們提供了根據其角色所需的訂單數據全景。list:orders 範疇（例如，普通客戶），系統將僅返回屬於該用戶的訂單。這確保客戶能夠訪問他們的訂單信息，而不被授予不必要的許可。通過實施基於所有權的訪問控制，API 能夠向不同用戶角色提供合適的訪問級別，同時維持安全性和量身定制的用戶體驗。在 BookHarber 的情景中，所有權模型允許客戶訪問他們的訂單信息，而無需 "read:orders" 或 "list:orders" 範疇，簡化了訪問控制設計，並增強了整體用戶體驗。
要在 Logto 的 Console 完成配置，請按照以下步驟進行：
https://api.bookharber.com。在我們的示例項目 BookHarber 中，我們使用 Express 作為後端服務，React 作為前端網頁。本節將簡要介紹如何將 Logto 的 RBAC 功能集成到這些流行技術中，以保護我們的應用程序。
完整文檔：https://docs.logto.io/docs/recipes/rbac/protect-resource
要在你的 React 應用程序中初始化 Logto，請參考此處提供的文檔：https://docs.logto.io/docs/recipes/integrate-logto/react/
除了基本設置，你還需要在配置中指定 "resource" 和 "scopes"：
以下是如何使用 Logto 發送 API 請求的示例：
要保護 API，請參考：https://docs.logto.io/docs/recipes/protect-your-api/
除了示例代碼（https://docs.logto.io/docs/recipes/protect-your-api/node），我們需要添加範疇驗證：
Logto 的 RBAC 系統是現代應用程序中管理訪問控制和安全性的強大工具。通過利用 Logto 的 RBAC 功能，你可以確保用戶根據其角色獲得適當的資源訪問權限，從而保護敏感數據和功能免受未授權訪問。
在本文中，我們探索了一個線上書店 BookHarber 的真實案例，並演示了如何設計範疇、將其分配給用戶角色，以及在應用程序的前端和後端實施 Logto 的 RBAC 功能。
通過將這些概念和技術應用到你的項目中，你可以增強應用程序的安全性和訪問控制，提供流暢且安全的用戶體驗。無論你正在開發一個電子商務平台、內容管理系統，或任何其他需要角色訪問控制的項目，Logto 的 RBAC 系統都提供了一種靈活而高效的解決方案，以滿足你的訪問控制需求。