讀完這一章，你會知道如何把第 9 章的資料模型接上使用者系統。你會學會用 Lovable 建立 email/password login、Google sign-in、受保護頁面、使用者角色、membership table 與 RLS（Row Level Security，列層級安全） 測試流程，並分清楚 project（專案）access、website access 和 app user access 這三種完全不同的權限。
這章的重點不是「加登入」。登入只是入口。真正重要的是：誰可以進入產品、誰可以看到哪些資料、誰可以修改哪些資料，以及你怎麼證明這些規則真的有效。
第 9 章已經讓 LaunchNote 有資料表、dashboard（儀表板）、public changelog、Storage 和初步 RLS（Row Level Security，列層級安全） plan。但只要沒有使用者系統，就還有幾個大問題：
很多 AI app prototype（原型）看起來可以用，但一上線就出事，原因通常不是畫面不漂亮，而是權限沒有被設計清楚。
對 Lovable 來說，auth（驗證）是一個很容易 提示詞的功能。你可以說 Add login，Lovable 就能產生登入頁和狀態管理。但對產品來說，auth（驗證）只是開始。你還需要 user model、role model、page protection、database access policy 和測試帳號。
做 Lovable 專案時，請把 access 分成三層：
專案存取權限 = 誰能進 Lovable 編輯器查看原始碼、聊天紀錄和未發布修改
網站存取權限 = 誰能訪問已發布的 URL
應用程式使用者權限 = 你的產品內部誰能查看或修改資料
這三層不要混在一起。
Project（專案） access 是 Lovable 專案本身的協作權限。它控制誰能在 editor 裡查看或編輯 project（專案）。它不是你的 app 內部登入系統。
Website access 是 published app 的訪問範圍。它控制誰能開 live URL。它也不是 database row-level permission。
App user access 才是你產品裡的登入、角色、會員、團隊、RLS（Row Level Security，列層級安全） 和 protected pages。
最常見的誤會是：
我的 Lovable 專案是私密的，所以已發布應用程式裡的資料也是私密的。
這是錯的。Lovable 文件明確區分 project（專案）access 和 published website access。發布不會讓別人看到你的 editor，也不代表你的 app 資料權限已經安全。
開始前，請先確認：
projects 和 changelog_entries。LaunchNote 的 app access 規則如下：
公開訪客：
- 可以讀取已發布的更新日誌項目。
- 不能讀取草稿。
- 不能存取儀表板。
通過身分驗證的使用者：
- 可以存取儀表板。
- 可以建立專案。
- 可以建立和編輯自己所屬專案的項目。
- 不能存取其他團隊的專案。
專案管理員：
- 可以管理團隊成員。
- 可以發布項目。
專案編輯者：
- 可以建立和編輯草稿。
- 不能管理帳務或團隊設定。
你不需要第一版就做完所有角色，但你必須先把規則寫出來。
不要直接說：
請新增登入功能。
這可以當最小測試，但不適合產品實作。比較好的做法，是先定義 auth（驗證）scope：
請規劃 LaunchNote 的身分驗證和授權模型。
產品背景：
LaunchNote 讓 SaaS 團隊管理更新日誌項目，並發布公開更新日誌。
存取規則：
- 公開訪客可以查看已發布的更新日誌項目。
- 公開訪客不能存取儀表板。
- 通過身分驗證的使用者可以存取儀表板。
- 使用者只能存取自己所屬的專案。
- 專案管理員可以管理成員和發布項目。
- 專案編輯者可以建立和編輯項目，但不能管理成員。
請提出：
- 必要的身分驗證頁面。
- 個人資料、專案成員關係和角色所需的資料表。
- 應受保護的頁面。
- RLS Policy 設計。
- 至少包含兩位使用者和兩個專案的測試案例。
先不要實作。
這個提示詞的目標，是先把 auth（驗證）從「畫面功能」提升成「產品規則」。
Supabase integration 文件提到，連接 Supabase 後可以用簡單 提示詞建立 login flow。開發時可以從 app signup form 建立測試帳號，也可以到 Supabase Dashboard（儀表板） 的 Authentication > Users 手動新增。
實作時可以這樣 提示詞：
請為 LaunchNote 新增電子郵件和密碼驗證。
需求：
- 建立登入和註冊頁面。
- 新增登出功能。
- 在儀表板頁首顯示目前使用者的電子郵件。
- 存取任何儀表板路由前都必須通過身分驗證。
- 把未登入的使用者重新導向登入頁面。
- 公開更新日誌頁面不需登入即可存取。
- 檢查身分驗證狀態時，加入載入狀態。
- 登入資料無效或註冊失敗時，顯示容易理解的錯誤訊息。
暫時不要加入 Google 登入。
不要修改公開首頁設計。
完成後要測：
最後一點很重要。有些 app 會在 auth（驗證）state 尚未確認時短暫顯示私有頁面，這是體驗和安全上的壞味道。
Supabase 文件建議，開發時可以暫時關閉 email confirmation，讓測試帳號可以立即登入。這對開發很方便。
但這不是 production（正式上線）設定。
你可以在章節練習時這樣做：
為了在本機測試，我會在 Supabase 關閉電子郵件確認，讓測試使用者可以立即登入。
請在正式環境檢查清單提醒我，上線前要重新啟用適當的電子郵件驗證設定。
這裡要建立一個習慣：開發便利設定要被記錄，不能讓它默默進 production（正式上線）。
圖 10-1：Lovable Cloud 可使用代管 Google OAuth 或自備 credentials；兩者的使用者登入體驗相同，但 credential ownership 與維護責任不同。
Google sign-in 有兩種常見情境。
如果你使用 Lovable Cloud，Lovable 文件提供 Google authentication flow。預設建議使用 Managed by Lovable，Lovable 管理 OAuth client、credentials、redirect handling 和安全更新。你也可以選擇使用自己的 Google Cloud credentials，這時候你要自己管理 OAuth consent screen、Client ID、Client secret 和 redirect URIs。
如果你不是 Lovable Cloud app，也可以做 Google auth（驗證），但需要在外部手動設定，例如透過 Supabase Authentication Providers 設定 Google OAuth，然後請 Lovable 更新 UI（使用者介面）。
Lovable Cloud managed flow 的 提示詞可以是：
請使用 Lovable Cloud 代管的 Google 驗證，為 LaunchNote 新增 Google 登入。
需求：
- 在登入頁面新增「使用 Google 登入」按鈕。
- 保留電子郵件和密碼登入。
- 登入後，把使用者重新導向儀表板。
- 新增登出功能。
- 測試使用者回到應用程式時仍維持登入狀態。
使用自己的 Google credentials 時，提示詞要更明確：
請使用我自己的 Google OAuth 憑證新增 Google 登入。
我會在 Google Cloud 設定 OAuth 同意畫面和網頁應用程式憑證。
請引導我完成：
- 必須新增哪些重新導向 URI。
- 在 Lovable 的哪裡輸入 Client ID 和 Client Secret。
- 如何在 Lovable 預設網域和自訂網域驗證登入流程。
不要把 Client Secret 儲存在前端程式碼中。
Google OAuth 最常見錯誤是 redirect URI mismatch。scheme、domain、path、trailing slash 都要完全一致。
圖 10-2：Auth 設定與 database 操作是不同權限面向；高風險操作可設為 Ask each time，避免把 UI 登入誤當成資料安全。
把 dashboard（儀表板） route 加上登入保護，只是第一層。
你還要保護 data access。
錯誤的想法：
使用者看不到儀表板，所以資料安全了。
正確的想法：
使用者介面的路由保護可防止一般未授權存取。
RLS 可防止未授權的資料庫存取。
兩者都不可缺少。
Route protection 讓未登入者不能進內部頁面。RLS（Row Level Security，列層級安全） 讓即使有人直接打 API，也只能讀寫被允許的資料。
請 Lovable 做 route protection 時，要同時要求 data access plan：
請保護儀表板路由，並審查資料庫存取權限。
需求：
- 未登入使用者會被重新導向登入頁面。
- 通過身分驗證的使用者可以存取儀表板路由。
- 公開更新日誌維持公開。
- 儀表板查詢只能讀取目前使用者所屬的專案。
- 項目異動只能作用於目前使用者所屬的專案。
實作 RLS 變更前，請先顯示 Policy 計畫和測試案例。
Supabase Auth（驗證） 會有 user identity，但產品通常還需要自己的 profile 和 membership model。
以 LaunchNote 來說，建議至少有：
profiles
- id
- user_id
- display_name
- avatar_url
- created_at
- updated_at
project_memberships
- id
- project_id
- user_id
- role
- created_at
role 可以先簡化成：
admin
editor
viewer
你可以這樣 提示詞：
請新增產品層級的使用者個人資料和專案成員關係。
資料表：
- profiles：儲存每位已驗證使用者的顯示名稱和頭像。
- project_memberships：以角色連結使用者和專案。
角色：
- admin：可以管理成員和發布項目。
- editor：可以建立和編輯項目。
- viewer：可以讀取內部儀表板內容，但不能編輯。
行為：
- 使用者註冊時，建立個人資料。
- 使用者建立專案時，把他以 admin 角色加入 project_memberships。
- 儀表板只顯示目前使用者具有成員關係的專案。
套用前，請先顯示 SQL 和 RLS 變更。
這裡的重點是 multi-tenant isolation。每個 team 或 project（專案）的資料都要有 membership 規則，不然使用者可能看到別人的資料。
Role 不應該只是一個字串。你要知道每個 role 能做什麼。
範例：
能力 admin editor viewer public
查看公開更新日誌 是 是 是 是
查看儀表板項目 是 是 是 否
建立草稿項目 是 是 否 否
編輯草稿項目 是 是 否 否
發布項目 是 否 否 否
管理成員 是 否 否 否
刪除專案 是 否 否 否
你可以請 Lovable 先做 capability review：
請為 LaunchNote 建立角色能力矩陣。
角色：
- 公開訪客
- 沒有專案成員關係的已驗證使用者
- 專案檢視者
- 專案編輯者
- 專案管理員
功能：
- 查看公開更新日誌。
- 查看儀表板。
- 建立草稿項目。
- 編輯草稿項目。
- 發布項目。
- 刪除項目。
- 管理標籤。
- 邀請成員。
- 移除成員。
- 變更專案設定。
請使用這份矩陣找出必要的使用者介面限制和 RLS Policy。
先不要實作。
這份 matrix 可以保存到 project（專案）knowledge，讓 Lovable 之後改功能時不要忘記角色邊界。
圖 10-3：使用 Supabase 時，登入帳號、資料表與 RLS policies 必須一起設計；每張表都應限制哪些角色能讀寫哪些 row。
RLS（Row Level Security，列層級安全） policy 不能只靠看 SQL。你要用測試案例驗證。
最少要有：
測試矩陣：
公開訪客：
- 可以讀取專案 A 的已發布項目。
- 不能讀取專案 A 的草稿。
使用者 A：
- 可以讀取專案 A 的草稿。
- 可以編輯專案 A 的項目。
- 不能讀取專案 B 的草稿。
- 不能編輯專案 B 的項目。
使用者 B：
- 可以讀取專案 B 的草稿。
- 不能編輯專案 A 的項目。
使用者 C：
- 不能存取專案 A 的儀表板。
- 不能存取專案 B 的儀表板。
提示詞：
請為 LaunchNote 的成員關係建立 RLS Policy 和測試。
使用以下角色：
- 使用者 A：專案 A 的管理員。
- 使用者 B：專案 B 的管理員。
- 使用者 C：沒有任何成員關係的已驗證使用者。
- 公開訪客：未通過身分驗證。
規則：
- 公開訪客只能讀取已發布項目。
- 公開訪客不能讀取草稿。
- 成員可以讀取自己所屬專案的項目。
- 編輯者和管理員可以建立及編輯項目。
- 只有管理員可以發布項目和管理成員。
- 任何使用者都不能存取其他專案的草稿。
請提供：
- SQL Policy。
- 測試資料設定。
- 手動測試檢查清單。
- 所有限制或假設。
在我核准前不要套用。
這章先教你設計與驗證，實際 production（正式上線）security review 會在第 15 章再完整展開。
RLS（Row Level Security，列層級安全） 是資料層安全。UI（使用者介面）權限是產品體驗。兩者都需要。
如果 viewer 不能 publish，UI（使用者介面）就不應該顯示 publish button。即使 RLS（Row Level Security，列層級安全） 會擋掉，顯示不能用的操作也會造成困惑。
提示詞：
請更新儀表板使用者介面，讓它遵守專案角色規則。
規則：
- 管理員可以看到成員管理和發布控制項。
- 編輯者可以建立和編輯草稿。
- 檢視者可以讀取項目，但不能編輯或發布。
- 沒有成員關係的使用者不能存取儀表板。
針對隱藏或停用的控制項：
- 使用者永遠不能使用的操作，優先直接隱藏。
- 只有在有助於解釋缺少權限時，才顯示清楚的停用狀態。
底層 RLS Policy 應維持為權限判斷的唯一依據。
好的權限設計是：
使用者介面避免使用者困惑。
RLS 防止未授權存取。
測試證明兩者都有效。
做完 app user access 後，別忘了 Lovable 平台層級的 access。
Project（專案） access 控制 editor。你要決定：
Website access 控制 published URL。你要決定：
對 LaunchNote 這種 SaaS：
專案存取權限：依團隊工作流程設為 Workspace 或 Restricted。
網站存取權限：設為 Anyone，因為公開更新日誌需要公開訪問。
應用程式使用者權限：使用身分驗證和 RLS，因為儀表板是私密的。
對企業內部工具：
專案存取權限：Workspace 或 Restricted。
網站存取權限：Workspace。
應用程式使用者權限：身分驗證加上角色規則。
這三層分清楚，才不會用錯開關。
實作前，請先規劃身分驗證與授權。
產品：
LaunchNote 是給 SaaS 團隊使用的更新日誌工具。
存取規則：
- 公開訪客可以讀取已發布的更新日誌項目。
- 儀表板需要登入。
- 使用者只能存取自己所屬的專案。
- 管理員可以管理成員並發布項目。
- 編輯者可以建立和編輯草稿。
- 檢視者可以讀取內部內容，但不能編輯。
請提出：
- 身分驗證頁面。
- 受保護路由。
- 必要的個人資料與成員關係資料表。
- 角色能力矩陣。
- RLS Policy 計畫。
- 測試案例。
先不要實作。
為什麼有效：
請新增電子郵件和密碼登入。
需求：
- 登入頁面。
- 註冊頁面。
- 登出功能。
- 身分驗證狀態載入畫面。
- 把未登入的儀表板訪客重新導向登入頁面。
- 把已登入使用者重新導向儀表板。
- 保持公開更新日誌可供存取。
- 登入或註冊失敗時，顯示容易理解的錯誤訊息。
暫時不要加入社群帳號登入。
不要修改公開首頁。
為什麼有效：
請新增 Google 登入。
背景：
這是 Lovable Cloud 應用程式。除非有明確理由，請使用代管的 Google 驗證。
需求：
- 在登入頁面新增「使用 Google 登入」。
- 保持電子郵件和密碼登入可用。
- 把已登入使用者重新導向儀表板。
- 如果缺少登出功能，請新增。
- 驗證使用者從 Google 回來後維持登入狀態。
請回報我需要審查的 OAuth 重新導向 URI 或網域設定。
為什麼有效：
請新增專案成員關係和角色。
資料表：
- profiles
- project_memberships
角色：
- admin
- editor
- viewer
行為：
- 新使用者會取得個人資料。
- 專案建立者會成為自己專案的 admin。
- 儀表板只列出目前使用者具有成員關係的專案。
- 管理員可以管理成員並發布項目。
- 編輯者可以建立和編輯項目。
- 檢視者可以讀取但不能編輯。
套用前，請先顯示 SQL 和 RLS 變更。
為什麼有效：
請建立權限測試計畫。
角色：
- 使用者 A：專案 A 的管理員。
- 使用者 B：專案 B 的管理員。
- 使用者 C：沒有成員關係的已驗證使用者。
- 公開訪客。
測試：
- 公開訪客只能讀取已發布項目。
- 公開訪客不能讀取草稿。
- 使用者 A 可以管理專案 A。
- 使用者 A 不能存取專案 B 的草稿。
- 使用者 B 不能編輯專案 A。
- 使用者 C 不能存取任何儀表板。
請包含：
- 測試資料。
- 手動瀏覽器測試步驟。
- 資料庫檢查。
- 每個案例的預期結果。
為什麼有效：
替第 9 章的 LaunchNote 加上登入與權限。
使用 Pattern 1 產生 auth（驗證）plan。
預期結果：
使用 Pattern 2 加上 email/password login。
預期結果：
依你的後端路線加入 Google sign-in。
預期結果：
使用 Pattern 4 和 Pattern 5 建立 membership 與測試。
預期結果：
Lovable project（專案）private 不代表你的 app data private。Project（專案） access 只控制 editor。
Route protection 是必要的，但不夠。RLS（Row Level Security，列層級安全） 才是資料層防線。
只靠 user id 很難做 team SaaS。只要產品有 project（專案）、team、workspace（工作區），就應該考慮 membership model。
Role 沒有 capability matrix，之後一定會混亂。先寫清楚每個 role 能做什麼。
很多人只測已登入使用者。Public visitor 才是最容易看見不該公開資料的角色。
例如關閉 email confirmation 可以方便測試，但 production（正式上線）前要重新檢查。
有些階段不需要完整 auth（驗證）：
但只要你開始保存使用者資料、團隊資料、付款資料或私有內容，就不要再用「之後再補權限」當策略。
讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術