feat(auth): GET /api/auth/me/permissions + wire frontend canAccess

[cristim]

Summary

• Adds GET /api/auth/me/permissions (AuthUser level) that returns the current user's effective permission set derived from the union of their group permissions via the same GetUserPermissions path the backend enforces with
• Rewrites canAccess(action, resource) in frontend/src/permissions.ts to consult the server-provided set when available; removes the void action; void resource; return isAdmin() stub that was blocking every non-admin user
• Fetches the permissions on login/bootstrap in app.ts and caches them on the current-user state; best-effort so a failure does not block app loading

Closes #917

Test plan

• Backend: 6 new handler tests in handler_auth_test.go covering multi-group user gets union, admin gets wildcard, unauthenticated gets 401
• Frontend: expanded permissions.test.ts with canAccess tests for the effective-permissions path (explicit grants, admin wildcard, multi-group union, empty set) and kept fallback-path tests
• go test ./internal/... passes (4273 tests)
• npm test passes (2213 tests, 65 suites)
• npm run build compiles cleanly
• npm run lint skipped - pre-existing broken ESLint config (no .eslintrc)

🤖 Generated with claude-flow

Summary by CodeRabbit

• New Features

  • Added a permissions endpoint and app startup fetch so the UI uses each user’s effective permission set for more accurate access gating; admins are still allowed during initial loading as a fallback.
  • Runtime validation of permissions responses to ensure malformed data is rejected.

• Tests

  • Expanded test coverage for the permissions endpoint and client-side permission-checking across auth scenarios, wildcards, group unions, empty/absent permissions, and error cases.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: f5bc45f3-2b94-4a97-b6c6-136c4bb31b3b

📥 Commits

Reviewing files that changed from the base of the PR and between 4ee652e and 90fb7f6.

📒 Files selected for processing (4)

• frontend/src/__tests__/api-permissions.test.ts
• frontend/src/api/auth.ts
• internal/api/handler_auth.go
• internal/api/handler_auth_test.go

🚧 Files skipped from review as they are similar to previous changes (1)

• frontend/src/api/auth.ts

---

📝 Walkthrough

Walkthrough

Adds GET /api/auth/me/permissions; backend returns the authenticated user’s effective permissions. Frontend fetches and caches that set at bootstrap and updates canAccess() to consult effectivePermissions (admin:* still grants all; fallback to isAdmin() while loading).

Changes

Permissions Endpoint and Frontend Gating

Layer / File(s)	Summary
Backend API contract internal/api/types.go	AuthServiceInterface gains GetUserPermissionsAPI(ctx, userID); new PermissionEntry and UserPermissionsResponse DTOs model the endpoint response.
Backend service adapter internal/auth/service_api.go, internal/server/app.go	Auth service adapter implements GetUserPermissionsAPI by converting internal permissions to wire format; server app adapter exposes the call.
Handler and auth resolution internal/api/handler_auth.go	Handler authenticates caller (session or API key), resolves user ID, calls GetUserPermissionsAPI, validates and serializes the payload, computes IsAdmin, and returns UserPermissionsResponse.
Router wiring internal/api/router.go	Register authenticated GET /api/auth/me/permissions route and add wrapper handler forwarding to the implementation.
Backend tests and mocks internal/api/handler_auth_test.go, internal/api/mocks_test.go, internal/api/handler_ri_exchange_test.go	Add handler tests covering missing/invalid auth, regular/admin success cases, unexpected payload regression, API-key auth; mocks implement GetUserPermissionsAPI.
Frontend API types and client function frontend/src/api/types.ts, frontend/src/api/auth.ts, frontend/src/api/index.ts	Add PermissionEntry and UserPermissionsResponse types; extend User with optional effectivePermissions; implement getUserPermissions() with runtime shape validation and export via barrel.
Frontend permission fetch on bootstrap frontend/src/app.ts	After loading current user, call getUserPermissions() and merge effectivePermissions into user state; log and ignore failures.
Frontend permission checking logic frontend/src/permissions.ts	canAccess() consults user.effectivePermissions for admin:* or action/resource matches (resource may be *); while undefined, it falls back to isAdmin().
Frontend permission tests frontend/src/__tests__/permissions.test.ts	Restructured tests cover loading-race fallback, effective-permissions grants/denials, wildcard admin behavior, empty-array denial, multi-group union behavior, and null-user denial; mockUserWithGroups extended.
Frontend getUserPermissions() tests frontend/src/__tests__/api-permissions.test.ts	Jest tests validate success parsing and detailed rejection messages for malformed API responses.

Sequence Diagram(s)

sequenceDiagram
  participant Client as Authenticated Client
  participant Handler as Handler
  participant Service as Auth Service

  Client->>Handler: GET /api/auth/me/permissions
  Handler->>Handler: Extract credentials (bearer/X-API-Key)
  Handler->>Handler: Validate session or validate API key
  Handler->>Service: GetUserPermissionsAPI(userID)
  Service-->>Handler: []APIPermission
  Handler->>Handler: Convert to PermissionEntry / Compute IsAdmin
  Handler-->>Client: UserPermissionsResponse{permissions, is_admin}

Loading

sequenceDiagram
  participant App as Frontend App
  participant API as API Client
  participant Backend as Backend
  participant State as User State

  App->>API: getUserPermissions()
  API->>Backend: GET /api/auth/me/permissions
  Backend-->>API: UserPermissionsResponse
  API-->>App: {permissions, is_admin}
  App->>State: store effectivePermissions
  Note over State: Later...
  rect rgba(100, 150, 200, 0.5)
  App->>App: canAccess(action, resource)
  App->>State: check effectivePermissions
  State-->>App: PermissionEntry[] or undefined
  App->>App: match admin:* or action/resource (resource may be '*') or fallback isAdmin()
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• LeanerCloud/CUDly#452: Original permissions test coverage for canAccess() and isAdmin() behavior; this PR restructures and extends that test suite to validate permission-based gating instead of stub admin-only checks.
• LeanerCloud/CUDly#726: Changes related to frontend permission expectations and router/handler-level gating that overlap with permission checks and tests.

Suggested labels

type/feat

Poem

🐰 Hoppity hooray — permissions now flow,
The frontend fetches what backends bestow.
Admins keep their star; groups grant the rest,
Buttons reappear for each rightful guest.
A rabbit cheers softly — the UI's refreshed, at best! 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 76.47% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'feat(auth): GET /api/auth/me/permissions + wire frontend canAccess' clearly and concisely summarizes the main changes: adding a new auth endpoint and wiring frontend permission logic.
Linked Issues check	✅ Passed	The PR fully implements all core requirements from #917: adds GET /api/auth/me/permissions endpoint returning effective permissions, fetches/caches permissions on frontend login, updates canAccess() to consult server permissions with fallback, includes comprehensive tests for union behavior and validation.
Out of Scope Changes check	✅ Passed	All changes are directly aligned with #917 requirements: backend permission endpoint, frontend permission fetching, canAccess() logic, type definitions, route registration, and related tests—no unrelated refactoring or scope creep detected.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/me-permissions-endpoint

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@frontend/src/api/auth.ts`:
- Around line 114-124: getUserPermissions currently returns
apiRequest<UserPermissionsResponse> without runtime validation which can let
malformed responses (non-array permissions, nulls, or wrong types) crash
canAccess; update getUserPermissions to perform shape checks following the
existing pattern used by getResetTokenStatus/setupMFA/etc.: verify the response
is an object, that response.permissions is an array, every entry has string
action and resource, and response.is_admin is a boolean, and throw a descriptive
error if any check fails so the caller (app.ts) falls back to the safe gating
logic.

In `@internal/api/handler_auth.go`:
- Around line 115-123: The handler currently forces a bearer session by calling
extractBearerToken and h.auth.ValidateSession even for requests already
authenticated via the router's AuthUser mode; change the logic so that if
extractBearerToken(req) returns empty you resolve the authenticated user from
the request/auth context (instead of returning a 401) and only call
h.auth.ValidateSession(ctx, token) when a bearer token is present; update the
code paths that relied on the returned session to accept the resolved
user/session object from the request context so AuthUser and API-key callers are
honored.
- Around line 130-146: The unchecked type assertion of raw to
[]auth.APIPermission should fail loudly instead of silently returning empty
permissions; update the code around the GetUserPermissionsAPI handling to
perform a checked assertion (apiPerms, ok := raw.([]auth.APIPermission)) and if
ok is false return an error (wrapped with context) rather than continuing, so
callers of UserPermissionsResponse can surface the server-side type mismatch;
keep building PermissionEntry and IsAdmin only after a successful assertion and
reference PermissionEntry, UserPermissionsResponse, and auth.APIPermission in
your fix.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: dce2af26-d554-4f76-b8fd-176b01849f58

📥 Commits

Reviewing files that changed from the base of the PR and between 1dbeef7 and 4ee652e.

📒 Files selected for processing (14)

• frontend/src/__tests__/permissions.test.ts
• frontend/src/api/auth.ts
• frontend/src/api/index.ts
• frontend/src/api/types.ts
• frontend/src/app.ts
• frontend/src/permissions.ts
• internal/api/handler_auth.go
• internal/api/handler_auth_test.go
• internal/api/handler_ri_exchange_test.go
• internal/api/mocks_test.go
• internal/api/router.go
• internal/api/types.go
• internal/auth/service_api.go
• internal/server/app.go

[cristim]

Addressed all 3 CR findings:

• F1 (handler_auth.go:146): checked type-assert on GetUserPermissionsAPI's any payload; unexpected shape now returns 500 with a logged returned %T, want []auth.APIPermission line instead of silently degrading to empty permissions.
• F2 (handler_auth.go:123): handler now honors AuthUser auth (admin API key, user API key, or bearer session) via a new resolveAuthenticatedUserID helper; admin-API-key short-circuits to {admin, *}+is_admin=true.
• F3 (auth.ts:124): getUserPermissions() now runtime-validates the response shape (response is object, permissions is array of {action:string, resource:string}, is_admin is boolean) mirroring setupMFA/getResetTokenStatus, so canAccess() can't crash on a malformed payload.

Regression tests added for each (3 Go tests in handler_auth_test.go, 10 TS tests in new api-permissions.test.ts).

@coderabbitai review

[coderabbitai]

@cristim Thanks for the thorough summary! All three fixes look well-handled:

• F1 — Failing loudly with a 500 + log on unexpected type is much safer than silently returning empty permissions.
• F2 — Centralizing auth resolution in resolveAuthenticatedUserID and short-circuiting admin API keys to {admin,*} is the right approach.
• F3 — Runtime shape validation mirrors the existing patterns in the codebase and prevents canAccess() from blowing up on a malformed payload.

Triggering a fresh review now to cover the new changes.

(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.