讀完這一章，你會完成第二個端到端專案：一個會員制內容平台。它包含公開首頁、註冊登入、受保護 dashboard（儀表板）、內容列表、內容編輯器、使用者自己的資料、角色感知 UI（使用者介面）、RLS（Row Level Security，列層級安全） 權限檢查，以及發布前的安全與測試流程。
這章不是再教一次「Add login」。登入只是入口。真正的重點是：
使用者登入後，只能看到自己有權限看的內容，也只能修改自己有權限修改的資料。
如果 Chapter 18 的 Project（專案） 1 是最小收件產品，Chapter 19 就是第一個真正有產品狀態的 app。它開始有使用者、有 private data、有 CRUD、有權限、有測試矩陣。這也是 Lovable 從「做頁面」進入「做系統」的分水嶺。
我們要做的產品叫做 MemberPress Lite。
它是一個會員制知識內容平台，給小型團隊發布內部教學、客戶 onboarding 文章或付費會員內容。第一版不做付款，因為付款已經在 Chapter 11 用 Paddle 主線處理過。這章先把會員內容平台的核心資料與權限做對。
第一版目標：
暫時不做：
這些都可以變成後續版本。第一版先把會員、內容和資料隔離做好。
Landing page 的主要風險是表單能不能送出、資料有沒有存、SEO 是否設定好。
會員平台的風險多很多：
這就是為什麼我們要把它拆成多個小步驟，不要一次叫 Lovable 做完整平台。
MemberPress Lite 的第一版包含兩種訪客狀態：
第一版包含兩種內容狀態：
資料模型：
profiles
- id
- user_id
- display_name
- role
- created_at
articles
- id
- owner_id
- title
- slug
- excerpt
- content
- status
- published_at
- created_at
- updated_at
角色先保持簡單：
member = 一般會員，可以管理自己的文章
admin = 管理者，第一版只在 UI 留位置，不先做完整後台
第一版要做到 member path 穩定。admin 可以作為 V2，不要在第一版硬做完整 RBAC。
圖 19-1：把 MemberPress Lite 的產品與權限規格貼入 Lovable 後，右側產生公開首頁，對話區保留 prompt 與完成摘要。
請先把產品規格講清楚。不要從「Add auth（驗證）」開始，因為 Lovable 需要知道登入後要保護什麼。
提示詞：
請建立新的 Lovable 應用程式，名稱為 MemberPress Lite。
產品：
MemberPress Lite 是讓小型團隊發布私密和公開知識文章的會員內容平台。
使用者：
- 匿名訪客可以查看公開產品介紹頁和已發布的公開文章。
- 通過身分驗證的會員可以存取受保護的儀表板。
- 會員可以建立、編輯、發布、取消發布和刪除自己的文章草稿。
- 會員不能讀取或修改其他會員的文章草稿。
- 會員不能編輯其他使用者擁有的文章。
第一版：
- 公開產品介紹頁。
- 註冊和登入。
- 受保護的儀表板。
- 我的文章清單。
- 文章編輯器。
- 已發布文章的公開文章頁面。
不要加入：
- 付款。
- AI 寫作。
- 團隊工作區。
- 留言。
- 檔案上傳。
- 管理員數據分析。
請先建置前端結構。
暫時不要建立資料庫 Schema。
和前一章一樣，先做 frontend（前端）structure。這能讓你先檢查 navigation、routes、頁面關係和使用者流程。
會員平台一定要先畫 route map。否則 Lovable 很容易把 public page、auth（驗證）page 和 dashboard（儀表板） 混在一起。
建議 route：
| Route | Access | Purpose |
|---|---|---|
/ |
public | Landing page |
/login |
public only | Login |
/signup |
public only | Signup |
/dashboard |
authenticated | Member dashboard（儀表板） |
/articles |
authenticated | My articles list |
/articles/new |
authenticated | Create article |
/articles/:id/edit |
authenticated owner | Edit article |
/p/:slug |
public if published | Public article page |
提示詞：
請檢查並實作 MemberPress Lite 的路由圖。
路由：
- /：公開產品介紹頁。
- /login：公開登入頁面。
- /signup：公開註冊頁面。
- /dashboard：需身分驗證的儀表板。
- /articles：需身分驗證，目前使用者的文章清單。
- /articles/new：需身分驗證的新文章編輯器。
- /articles/:id/edit：需身分驗證且僅擁有者可用的文章編輯器。
- /p/:slug：公開文章頁面，只顯示已發布文章。
規則：
- 匿名使用者造訪受保護路由時，重新導向 /login。
- 已登入使用者造訪 /login 或 /signup 時，重新導向 /dashboard。
- 公開文章頁面只顯示已發布文章。
- 草稿文章不得公開。
不要加入付款、AI、留言或檔案上傳。
這一步的驗收重點不是資料，而是路由行為。
圖 19-2：送出 Email／Password Auth prompt 並啟用 Lovable Cloud 後，右側實際生成繁體中文註冊頁與受保護路由流程。
現在加入登入。對第一版，email/password 最容易測。Google sign-in 可以是 extension，先不要讓 OAuth redirect 設定干擾核心內容 CRUD。
提示詞：
請為 MemberPress Lite 新增電子郵件和密碼驗證。
需求：
- 註冊頁面。
- 登入頁面。
- 登出操作。
- 能感知 Session 狀態的導覽列。
- 把已登入使用者重新導向 /dashboard。
- 把未登入使用者從受保護路由重新導向 /login。
- 顯示友善的繁體中文錯誤訊息。
- 不要向使用者暴露原始身分驗證錯誤。
- 使用者介面風格與產品介紹頁一致。
實作後，請說明：
- 如何建立測試使用者。
- 如何驗證登入。
- 如何驗證登出。
- 哪些路由受到保護。
測試階段可以暫時關閉 email confirmation，讓測試帳號能立即登入。正式上線前要重新檢查 email confirmation 和 email template。
如果要加入 Google sign-in，請在 email/password 穩定後再做：
請新增 Google 登入作為選用的登入方式。
如果可用，請使用 Lovable 代管的 Google 驗證。
請驗證：
- Google 按鈕會顯示。
- 使用者回到應用程式後維持登入狀態。
- 登出仍可正常運作。
- 既有電子郵件和密碼流程沒有損壞。
不要修改受保護路由的行為。
如果你使用自己的 Google credentials，redirect URI 必須和正式 domain 完全一致。這通常比較適合 production（正式上線）或有合規要求的團隊。
登入系統只能告訴你 user 是誰。產品通常還需要自己的 profile table。
第一版 profile 很簡單：
profiles
- id uuid primary key
- user_id uuid unique not null
- display_name text
- role text default member
- created_at timestamp with time zone default now()
提示詞：
請為 MemberPress Lite 建立 profiles 資料表。
欄位：
- id：UUID 主鍵。
- user_id：必填且唯一的 UUID。
- display_name：選填文字。
- role：文字，預設值為 member。
- created_at：含時區的時間戳記，預設值為 now()。
行為：
- 使用者註冊時，為該使用者建立一筆個人資料。
- 目前使用者可以讀取和更新自己的個人資料。
- 使用者不能讀取或更新其他使用者的個人資料。
- 暫時不要建置管理員個人資料管理工具。
實作後，請說明：
- 個人資料建立方式。
- 如何驗證個人資料列存在。
- 新增了哪些 RLS Policy。
Profile 是之後做 roles、teams、billing、preferences 的基礎。第一版不要過度設計，但一定要和 auth（驗證）user 對得起來。
內容平台的核心資料是 articles。第一版先做單一 author，不做多人協作。
建議 schema：
articles
- id uuid primary key
- owner_id uuid not null
- title text not null
- slug text unique not null
- excerpt text
- content text not null
- status text default draft
- published_at timestamp with time zone
- created_at timestamp with time zone default now()
- updated_at timestamp with time zone default now()
Status 只允許：
draft
published
提示詞：
請為 MemberPress Lite 建立 articles 資料表。
欄位：
- id：UUID 主鍵。
- owner_id：必填 UUID，連結到通過身分驗證的使用者。
- title：必填文字。
- slug：必填且唯一的文字。
- excerpt：選填文字。
- content：必填文字。
- status：文字，預設值為 draft，只允許 draft 和 published。
- published_at：可為空的時間戳記。
- created_at：含時區的時間戳記，預設值為 now()。
- updated_at：含時區的時間戳記，預設值為 now()。
存取規則：
- 通過身分驗證的使用者可以建立 owner_id 等於自己 User ID 的文章。
- 擁有者可以讀取自己的草稿和已發布文章。
- 擁有者可以更新自己的文章。
- 擁有者可以刪除自己的文章草稿。
- 任何人都可以透過公開文章頁面讀取已發布文章。
- 任何人都不能讀取其他使用者的文章草稿。
- 使用者不能更新或刪除其他人擁有的文章。
不要加入留言、團隊、檔案上傳、付款或 AI。
這裡要非常明確。因為「public read for published」和「private draft」是兩種不同 access pattern。
不要一開始就做完整 editor。先讓使用者看到自己的內容列表。
列表需要：
提示詞：
請為 MemberPress Lite 建置「我的文章」頁面。
路由：
- /articles
需求：
- 受保護路由。
- 只顯示目前使用者擁有的文章。
- 顯示標題、狀態、更新日期和操作。
- 使用者沒有文章時顯示空白狀態。
- 新增連到 /articles/new 的「新增文章」按鈕。
- 已發布文章顯示「查看公開頁面」操作。
- 草稿文章不要顯示公開連結。
不要顯示其他使用者的文章。
不要加入管理員功能。
測試這一步時，你需要至少兩個測試帳號。只有單一帳號無法證明資料隔離。
Editor 第一版不要太 fancy。不要做 rich text editor、拖拉 blocks、Markdown preview（預覽）、AI rewrite。先做可用的 CRUD。
欄位：
行為：
提示詞：
請為 MemberPress Lite 建置文章編輯器。
路由：
- /articles/new：建立新文章。
- /articles/:id/edit：編輯既有文章。
欄位：
- title：必填。
- slug：必填。
- excerpt：選填。
- content：必填。
- status：draft 或 published。
行為：
- 新文章預設為 draft。
- 儲存時建立或更新目前使用者的文章。
- 發布時把 status 設為 published，並設定 published_at。
- 取消發布時把 status 設為 draft，並取消公開可見性。
- 擁有者可以刪除文章草稿。
- 第一版中，已發布文章不顯示破壞性的刪除操作。
- 使用者不能編輯自己不擁有的文章。
使用者體驗：
- 載入狀態。
- 儲存成功狀態。
- 友善的驗證錯誤。
- 友善的權限不足狀態。
- 返回「我的文章」連結。
關於 delete，第一版只允許刪 draft 是保守設計。Published content 可能已被分享或被搜尋引擎收錄，刪除要有更完整的產品決策。
公開文章頁只顯示 published content。
Route：
/p/:slug
行為：
提示詞：
請為 MemberPress Lite 建置公開文章頁面。
路由：
- /p/:slug
規則：
- 任何人都可以讀取 status 為 published 的文章。
- 草稿文章不得透過公開 URL 顯示。
- 未知的 slug 顯示乾淨的找不到內容狀態。
- 目前登入使用者擁有該文章時，顯示「編輯文章」連結。
- 目前使用者不擁有該文章時，不顯示編輯操作。
- 匿名訪客只會看到公開導覽列。
SEO：
- 使用文章標題作為頁面標題。
- 如有摘要，使用摘要作為 Meta Description。
- 不要為草稿文章建立索引。
這一步會把 Chapter 16 的 SEO 概念拉回來：公開內容才需要 metadata（中繼資料），private draft 不該被 index。
第一版可以加簡單 role-aware UI（使用者介面），例如 dashboard（儀表板） 上顯示：
但你要一直提醒自己：
UI 只改善體驗，不提供安全性。
如果 admin 按鈕被隱藏，但 API 或 database policy 仍允許普通 member 操作，那就是漏洞。
提示詞：
請為 MemberPress Lite 新增簡單的角色感知使用者介面。
需求：
- 在儀表板顯示目前使用者的顯示名稱和角色。
- member 角色顯示「我的文章」和「個人資料」。
- admin 角色顯示管理後台暫用區塊，但暫時不要實作管理員功能。
- 不要依賴前端角色檢查保障資料安全。
- 所有資料存取都由後端 Policy 和 RLS 強制執行。
實作後，請說明哪些部分只屬於使用者介面，哪些部分由資料 Policy 強制執行。
這個提示詞的最後一句很重要。你要逼 Lovable 說清楚：哪些只是 UI（使用者介面），哪些是真的權限。
這章最重要的驗收點是 RLS（Row Level Security，列層級安全）。
對 profiles：
對 articles：
提示詞：
請檢查 MemberPress Lite 的 RLS 和資料存取 Policy。
資料表：
- profiles.
- articles.
預期規則：
- 使用者可以讀取和更新自己的個人資料顯示名稱。
- 使用者不能透過前端變更自己的角色。
- 使用者不能讀取其他使用者的私密個人資料。
- 通過身分驗證的使用者可以建立自己擁有的文章。
- 擁有者可以讀取、更新、發布、取消發布和刪除自己的文章草稿。
- 任何人都可以讀取已發布文章。
- 任何人都不能讀取其他使用者的文章草稿。
- 任何人都不能更新或刪除其他使用者的文章。
請回傳：
- 目前 Policy 摘要。
- 任何過度寬鬆的 Policy。
- 任何缺少的 Policy。
- 所需的精確修正。
- 證明每項規則的手動測試。
如果 Basic scan 或 Deep scan 指出 RLS（Row Level Security，列層級安全） policy 問題，先修 critical findings。不要把它當成「之後再說」。
圖 19-3：把 Alice、Bob 與匿名訪客的 Browser Testing prompt 送入 Lovable，產生包含註冊、登入、草稿隔離與公開閱讀的測試矩陣。
會員平台不能只用一個帳號測。
建立三種測試身份：
可選：
測試矩陣：
| Scenario | Anonymous | Alice | Bob |
|---|---|---|---|
Visit /dashboard |
redirect | allowed | allowed |
| Visit Alice draft edit URL | redirect | allowed | denied |
| Visit Alice published URL | allowed | allowed | allowed |
| Edit Alice published article | no | allowed | denied |
| View Bob draft in list | no | no | yes |
| Create article | no | yes | yes |
| Delete Alice draft | no | yes | denied |
提示詞：
請為 MemberPress Lite 建立 Browser Testing 計畫。
測試身分：
- 匿名訪客。
- Alice，通過身分驗證的會員。
- Bob，通過身分驗證的會員。
測試：
- 受保護路由重新導向。
- 註冊。
- 登入。
- 登出。
- Alice 建立草稿。
- Alice 在「我的文章」看到自己的草稿。
- Bob 看不到 Alice 的草稿。
- Alice 發布文章。
- 匿名訪客可以讀取 Alice 已發布的文章。
- Bob 可以讀取 Alice 已發布的文章，但不能編輯。
- Alice 取消發布文章。
- 匿名訪客不再能讀取該文章。
- 錯誤和權限不足狀態。
針對每個測試，請列出：
- 步驟。
- 預期結果。
- 證明了哪項資料存取規則。
- 失敗是否阻擋發布。
Browser testing（瀏覽器測試） 很適合這種跨 route、跨 session、跨 UI（使用者介面）狀態的流程。若某個 backend（後端）rule 很細，也可以請 Lovable 用 backend（後端）verification 或 SQL 檢查輔助。
不是每件事都需要自動化測試，但會員平台有幾個值得鎖住：
提示詞：
請為 MemberPress Lite 文章使用者介面撰寫前端測試。
涵蓋：
- 文章編輯器要求 title、slug 和 content。
- 沒有文章時顯示「我的文章」空白狀態。
- 草稿文章不顯示公開連結。
- 已發布文章顯示公開連結。
- 存取遭拒時顯示權限不足狀態。
請使用既有測試技術組合。
請執行測試並摘要結果。
UI（使用者介面）tests 不會取代 RLS（Row Level Security，列層級安全） 測試。它們只保證 UI（使用者介面）規則不容易被改壞。
MemberPress Lite 已經處理使用者資料和 private content，所以發布前至少要跑 Basic scan。若有 critical findings，先修。
建議再跑一次 conversational security review：
發布前，請為 MemberPress Lite 執行安全審查。
重點：
- 身分驗證路由保護。
- 個人資料存取。
- 文章所有權。
- 草稿和已發布狀態的可見性差異。
- RLS Policy。
- 僅在前端執行的權限檢查。
- 錯誤訊息。
- 暴露的 Secrets。
- 公開文章的 SEO 行為。
請回傳：
- 重大阻礙。
- 高優先修正。
- 中優先修正。
- 低優先改善。
- 發布前所需的測試。
如果 app 有真實會員資料，Deep scan 也值得跑。Basic scan 偏向配置和資料庫常見問題，Deep scan 會更完整看 access control、backend（後端）endpoint 和 code-level vulnerabilities。
發布流程沿用 Chapter 17。
Live smoke test：
/dashboard blocks anonymous visitor。提示詞：
請為 MemberPress Lite 建立正式環境冒煙測試檢查清單。
請包含：
- 公開產品介紹頁。
- 註冊。
- 登入。
- 登出。
- 受保護路由。
- 建立文章。
- 編輯文章。
- 草稿隱私。
- 已發布文章的公開可見性。
- 僅擁有者可用的編輯操作。
- 取消發布行為。
- 行動版版面。
- 安全掃描發現。
記住：editor 裡修好之後，要 Publish Update，live site 才會更新。
建議你照這個順序做，不要跳：
1. 產品規格。
2. 路由圖。
3. 前端框架。
4. 電子郵件和密碼驗證。
5. 受保護路由。
6. profiles 資料表。
7. articles 資料表。
8. 我的文章清單。
9. 文章編輯器。
10. 公開文章頁面。
11. 角色感知使用者介面。
12. RLS 審查。
13. 多使用者 Browser Testing。
14. 安全掃描。
15. 發布和正式環境冒煙測試。
每一步都要能驗證。不能驗證的功能等於只是看起來完成。
登入只是知道 user 是誰。真正的安全來自 route protection、backend（後端）authorization 和 RLS（Row Level Security，列層級安全）。
Frontend（前端） 可以隱藏按鈕，但不能當成權限邊界。使用者可以繞過 UI（使用者介面）。
一個帳號只能證明自己看得到自己的資料，不能證明別人看不到。
Draft 是 private。Published 是 public readable。這兩種狀態要在 query、UI（使用者介面）、RLS（Row Level Security，列層級安全）、SEO 都分清楚。
Role 是權限資料，不能讓普通 member 從 profile form 修改。
Edit action 只能給 owner。非 owner 即使登入也不能看到或使用。
Session 過期時，dashboard（儀表板） 和 editor 應該乾淨地導回 login 或顯示重新登入，不應該卡在 loading。
會員平台有 private data。發布前一定要看 Basic scan，重要版本要跑 Deep scan。
/dashboard？/dashboard？/login 是否會把已登入者導向 dashboard（儀表板）？profiles table 是否建立？articles table 是否建立？讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術