# API Regression Testing Plan (Environment -> Workspace Migration)
## Goal
Validate that API key authorization and returned data stay behaviorally identical after moving from environment-centric access to workspace-centric access.
This plan is based on current route/auth logic in:
| `/api/v1/auth` | `GET` | API key itself | All 4 keys: `200`; returns API key + linked env permissions |
| `/api/v1/management/me` | `GET` | API key itself | `200` only if key has exactly one env permission (these 4 should); payload must match that env/project |
| `/api/v1/management/surveys` | `GET` | all key envs | 200, only W1 Dev surveys | 200, only W1 Prod surveys | 200, only W2 Dev surveys | 200, only W2 Prod surveys |
| `/api/v1/management/surveys` | `POST` | `body.environmentId` | 200 on W1 Dev, deny others | 401 | 200 on W2 Dev, deny others | 200 on W2 Prod, deny others |
| `/api/v1/management/surveys/{surveyId}` | `GET` | survey env | allow own env | allow own env | allow own env | allow own env |
| `/api/v1/management/surveys/{surveyId}` | `PUT` | survey env | allow own env | 401 | allow own env | allow own env |
| `/api/v1/management/surveys/{surveyId}` | `DELETE` | survey env | allow own env | 401 | allow own env | 401 |
| `/api/v1/management/surveys/{surveyId}/singleUseIds` | `GET` | survey env | allow own env link survey | allow own env link survey | allow own env link survey | allow own env link survey |
| `/api/v1/management/contact-attribute-keys` | `POST` | `body.environmentId` | allow own env | 401 | allow own env | allow own env |
| `/api/v1/management/contact-attribute-keys/{id}` | `GET` | key env | allow own env | allow own env | allow own env | allow own env |
| `/api/v1/management/contact-attribute-keys/{id}` | `PUT` | key env | allow own env | 401 | allow own env | allow own env |
| `/api/v1/management/contact-attribute-keys/{id}` | `DELETE` | key env | allow own env | 401 | allow own env | 401 |
---
## Endpoint Matrix: v2
### Global / Org-Level
| Endpoint | Method | Expected |
|---|---|---|
| `/api/v2/health` | `GET` | 200 if healthy (no API key required) |
| `/api/v2/roles` | `GET` | All 4 keys should get 200 with same role list |
| `/api/v2/me` | `GET` | 200 only when key has organization access (`read`/`write`), otherwise 401 |
> Note: v2 org endpoints (`/api/v2/organizations/{organizationId}/teams`, `/project-teams`, `/users`) require `organizationAccess` and matching organizationId param. If your four keys only have env permissions, expected result is unauthorized for all methods.
| `/api/v3/surveys?workspaceId={ws}` | `GET` | workspaceId -> environment via resolver | 200 for W1 Dev workspace; 403 for others | 200 for W1 Prod workspace; 403 for others | 200 for W2 Dev workspace; 403 for others | 200 for W2 Prod workspace; 403 for others |
Regression-critical checks for v3:
- No workspace can be accessed via key from another workspace.
- Returned survey list/count/cursor must match legacy env-scoped survey visibility.
- Response always includes `X-Request-Id`.
---
## Concrete Regression Test Cases (Execute For Every Endpoint Family)
For each endpoint/method:
1.**Positive Same-Scope**
- Use key with sufficient permission against its own env/workspace resource.
- Assert success status and payload shape.
2.**Negative Cross-Workspace**
- Use same key against a resource in another workspace.
- Assert auth failure and no data leakage.
3.**Negative Insufficient Method Permission**
-`K2` (`read`) on write endpoints -> deny.
-`K4` (`write`) on delete endpoints -> deny.
4.**Collection Leakage Test**
- Call list endpoint with each key.
- Assert every returned row belongs only to that key’s allowed env(s).
5.**ID Enumeration Safety**
- Try valid IDs from unauthorized envs.
- Assert deny response, no foreign resource details.
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Johannes