chore(openspec): 補歸檔 2026-06-11-audit-remediation change
Run Tests / test (pull_request) Successful in 2m2s
Run Tests / test (pull_request) Successful in 2m2s
事後補齊本次稽核修補的 OpenSpec 歷史紀錄（proposal / design / tasks / 規格增量），主規格已於實作時直接更新，本 archive 僅為 變更軌跡。design.md 記錄 5 項關鍵決策（artisan command 取代 HTTP 端點、10/min 為基準、列表過濾而非禁止上架等）。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,29 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 管理員帳號建立途徑
|
||||
管理員帳號 SHALL 僅能透過主機端 `php artisan app:create-admin` command 或資料庫 seeder 建立。系統 MUST NOT 提供任何公開的管理員註冊 HTTP 端點（原 `POST /api/admin/register` 已於 2026-06-11 因 P0 安全漏洞移除）。command 建立的密碼門檻為至少 8 碼，高於一般使用者。
|
||||
|
||||
#### Scenario: 公開註冊端點保持關閉
|
||||
- **WHEN** 任何人（含未認證請求）送出 `POST /api/admin/register`
|
||||
- **THEN** 回傳 HTTP 404，且不建立任何帳號
|
||||
|
||||
#### Scenario: 主機端建立管理員成功
|
||||
- **WHEN** 操作者於主機執行 `php artisan app:create-admin {name} {email} --password={password}` 且資料合法
|
||||
- **THEN** 建立 role=admin 的 User 與對應 AdminProfile
|
||||
|
||||
#### Scenario: 密碼過弱或 email 重複
|
||||
- **WHEN** command 收到少於 8 碼的密碼或已存在的 email
|
||||
- **THEN** command 以失敗結束，不建立任何帳號
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 管理員查詢指定用戶資料
|
||||
後端 SHALL 提供 `GET /api/admin/check-member/{id}` 與 `GET /api/admin/check-provider/{id}`（需 Bearer token，role=admin），依角色查詢指定用戶的基本資料與對應 profile。
|
||||
|
||||
#### Scenario: 查詢存在的用戶
|
||||
- **WHEN** 管理員以有效 id 查詢對應角色的用戶
|
||||
- **THEN** 回傳 HTTP 200 與該用戶資料
|
||||
|
||||
#### Scenario: id 不存在或角色不符
|
||||
- **WHEN** 查詢的 id 不存在，或該用戶角色與端點不符（如以 check-member 查 provider）
|
||||
- **THEN** 回傳 HTTP 404
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Auth 登入／註冊／登出測試覆蓋（三角色）
|
||||
（僅列出本次變更的 scenario；其餘 scenario 不變）
|
||||
|
||||
原「Admin 註冊成功」與「Admin 重複 Email 註冊失敗」兩個 scenario 移除（端點已刪），改為：
|
||||
|
||||
#### Scenario: Admin 公開註冊端點保持關閉
|
||||
- **WHEN** 任何人送出 `POST /api/admin/register`（該端點已於 2026-06-11 因 P0 漏洞移除，見 admin-auth 規格「管理員帳號建立途徑」）
|
||||
- **THEN** 回傳 HTTP 404，且不建立任何帳號；帳號建立改由 `app:create-admin` command 覆蓋測試
|
||||
|
||||
另補主規格歸檔時遺留的 TBD Purpose：
|
||||
|
||||
> 驗證三角色（member / provider / admin）認證流程的測試覆蓋契約：登入／註冊／登出、帳號鎖定（P2）、OAuth state 驗證、token refresh 與登入頻率限制。此規格定義測試套件必須覆蓋的場景，任何認證行為變更時，對應測試必須同步失敗以攔截回歸。
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: 登入頻率限制
|
||||
後端 SHALL 對所有登入端點套用 IP-based 頻率限制，超過限制時回傳 HTTP 429。Member 與 Provider 每 IP 每分鐘最多 10 次（原定 5 次；帳號鎖定機制上線後已涵蓋暴力破解防護，放寬以容納共享 IP 場景，與實作 `throttle:10,1` 一致）；Admin 因影響範圍更廣，限制為每 IP 每分鐘最多 3 次。
|
||||
|
||||
#### Scenario: Member / Provider 正常登入不受影響
|
||||
- **WHEN** 同一 IP 在 1 分鐘內對 `/api/member/login` 或 `/api/provider/login` 送出 10 次以內的請求
|
||||
- **THEN** 請求正常處理，回傳對應的登入結果（200 成功或 401 失敗）
|
||||
|
||||
#### Scenario: Member / Provider 超過頻率限制
|
||||
- **WHEN** 同一 IP 在 1 分鐘內送出第 11 次 member 或 provider 登入請求
|
||||
- **THEN** 回傳 HTTP 429，並帶有 `Retry-After` header 指示等待時間
|
||||
@@ -0,0 +1,12 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: 專案基礎建設
|
||||
前端 SHALL 建立於本 repo 的 `frontend/` 目錄（原規劃獨立 repo，後併入主 repo 以簡化版控與部署），使用 Vue 3 + Vite + Tailwind CSS + Vue Router 4 + Pinia + Axios，並設定 `.env` 指定後端 API base URL。
|
||||
|
||||
#### Scenario: 開發環境啟動
|
||||
- **WHEN** 開發者執行 `npm run dev`
|
||||
- **THEN** 應用在 `http://localhost:5173` 啟動，無編譯錯誤
|
||||
|
||||
#### Scenario: API base URL 設定
|
||||
- **WHEN** `.env` 中設定 `VITE_API_URL=http://localhost:80`
|
||||
- **THEN** 所有 Axios 請求以此為 base URL
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
# provider-verification Specification
|
||||
|
||||
## Purpose
|
||||
|
||||
定義 `provider_profiles.is_verified` 的最小業務語意：未通過平台驗證的教練，其課程不對公開端點曝光。在完整教練審核流程（證照上傳、審核佇列、駁回原因）實作前，先以此約束堵住「未審核教練可公開曝光」的風險。
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 未驗證教練的課程不對公開端點曝光
|
||||
公開課程端點（`GET /api/diving-offers`、`GET /api/diving-offers/{id}`）SHALL 僅回傳符合以下任一條件的課程：(a) `provider_id` 為 null（平台自有資料）；(b) 課程所屬 Provider 的 `provider_profiles.is_verified = true`。未驗證教練的課程在列表中 SHALL 被排除，在詳情端點 SHALL 回傳 404。
|
||||
|
||||
#### Scenario: 已驗證教練的課程正常曝光
|
||||
- **WHEN** 匿名使用者請求 `GET /api/diving-offers`
|
||||
- **THEN** 已驗證教練（is_verified=true）的課程出現在結果中
|
||||
|
||||
#### Scenario: 未驗證教練的課程從列表排除
|
||||
- **WHEN** 匿名使用者請求 `GET /api/diving-offers`
|
||||
- **THEN** 未驗證教練（is_verified=false 或無 ProviderProfile）的課程不出現在結果中
|
||||
|
||||
#### Scenario: 未驗證教練的課程詳情回 404
|
||||
- **WHEN** 匿名使用者請求 `GET /api/diving-offers/{id}`，該課程屬於未驗證教練
|
||||
- **THEN** 回傳 HTTP 404
|
||||
|
||||
#### Scenario: provider_id 為 null 的課程不受限
|
||||
- **WHEN** 匿名使用者請求公開課程端點，課程的 `provider_id` 為 null
|
||||
- **THEN** 課程正常曝光
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 驗證狀態切換立即生效
|
||||
管理員透過 `PUT /api/admin/providers/{id}/toggle-verified` 切換驗證狀態後，公開課程列表的快取（`diving_offers` cache tag）SHALL 立即失效，下次請求反映最新可見性。
|
||||
|
||||
#### Scenario: 取消驗證後課程立即從公開列表消失
|
||||
- **WHEN** 管理員將教練 is_verified 由 true 切為 false
|
||||
- **THEN** 下一次 `GET /api/diving-offers` 請求不包含該教練的課程（不受 180 秒快取影響）
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 教練自有管理端點不受可見性限制
|
||||
Provider 對自己課程的管理端點（`/api/provider/offers*`）與 Admin 管理端點（`/api/admin/offers*`）SHALL 不受公開可見性過濾影響，未驗證教練仍可登入、編輯與管理自己的課程。
|
||||
|
||||
#### Scenario: 未驗證教練仍可管理自己的課程
|
||||
- **WHEN** 未驗證教練以有效 token 請求 `GET /api/provider/offers`
|
||||
- **THEN** 回傳該教練的全部課程
|
||||
|
||||
## Notes
|
||||
|
||||
已知限制（留待完整教練審核流程處理）：`GET /api/diving-offers/{id}/schedules`、`GET /api/diving-offers/{id}/reviews` 與預約建立流程尚未套用相同過濾，知道課程 id 的使用者仍可間接互動。完整審核流程（verification_status enum、證照上傳、審核佇列）見 `docs/analysis/2026-06-11-future-roadmap-feasibility.md` §2.1。
|
||||
Reference in New Issue
Block a user