[Beta Support]: /api/profiles returns 403 for non-admin users — missing from EXEMPT_PATHS in require_admin_by_default()

[TCS-UK]

Describe the problem you are having

Frigate Dev Build — Auth Bug Report

Date: 2026-04-09
Frigate version: 0.18.0-8f13932c (dev branch)
Access path: Cloudflare → Traefik → Frigate (nginx:8971 → FastAPI:5001)

---

Issue A — /api/profiles returns 403 for non-admin users

Severity

Medium. Prevents the profile switcher UI from functioning for viewer/limited/guest users. Produces continuous console errors in the browser.

Symptom

GET https://frigate.my-domain.com/api/profiles 403 (Forbidden)

Repeats on a polling interval. Occurs for any authenticated user whose Authelia group maps to a role other than admin.

Root cause

The global FastAPI dependency require_admin_by_default() in frigate/api/auth.py maintains a hardcoded set of paths that are exempt from the admin role check:

EXEMPT_PATHS = {
    "/auth",
    "/auth/first_time_login",
    "/login",
    "/logout",
    "/profile",      # ← /profile (singular) is exempt
    "/metrics",
    "/stats",
    ...
}

The /profiles (plural) endpoint was added to frigate/api/app.py at line 254 with allow_any_authenticated() — meaning it is intentionally accessible to any logged-in user regardless of role:

@router.get("/profiles", dependencies=[Depends(allow_any_authenticated())])
def get_profiles(request: Request):
    """List all available profiles and the currently active profile."""

However, allow_any_authenticated() is a route-level dependency. In FastAPI, app-level dependencies run alongside route-level dependencies — they are not overridden. The global require_admin_by_default() runs first, finds /profiles not in EXEMPT_PATHS, checks that remote-role != "admin", and raises HTTPException(403) before the route handler is ever reached.

Why /profile (singular) is not affected

/profile is in EXEMPT_PATHS and serves the currently authenticated user's own profile object. It was present when the auth refactor was done. /profiles (the profile switcher list) is a newer addition and was not added to the exempt list.

Affected users

All non-admin roles: viewer, limited, guest, and any custom role. Admin users are unaffected (they pass the global check).

Fix (upstream code change required)

Add /profiles to EXEMPT_PATHS in frigate/api/auth.py:

EXEMPT_PATHS = {
    ...
    "/profile",
    "/profiles",    # ← add this line
    ...
}

File: frigate/api/auth.py
Location in source: Inside require_admin_by_default(), the EXEMPT_PATHS set definition.

Workaround (no code change)

None available without modifying the running container. The path check is inside compiled Python running in the container. The Traefik/nginx layers cannot intercept this — it is a FastAPI application-level rejection.

If patching the running container is acceptable (change will not survive image recreation):

# Inside the container, find and edit auth.py
docker exec -it frigate bash
# File location (approximate — verify with: find / -path "*/frigate/api/auth.py" 2>/dev/null)
# Edit EXEMPT_PATHS to add "/profiles"
# Then: kill -HUP $(pgrep -f "uvicorn")  -- may not work; container restart likely needed

Status

Bug: The fix is a one-line addition. Low risk of regression.

---

Issue B — /api/debug_replay/status returns 403 for non-admin users

Severity

Low / expected behaviour. The debug replay feature is intentionally admin-only. Console errors are noise but do not indicate a broken configuration.

Symptom

GET https://frigate.my-domain.com/api/debug_replay/status 403 (Forbidden)

Repeats on a polling interval when logged in as a non-admin user.

Root cause

The endpoint is explicitly gated with require_role(["admin"]) in frigate/api/debug_replay.py at line 108:

@router.get(
    "/debug_replay/status",
    response_model=DebugReplayStatusResponse,
    dependencies=[Depends(require_role(["admin"]))],
    ...
)
def get_debug_replay_status(request: Request):

This is by design. The debug replay feature allows replaying camera recordings through the detection pipeline — a destructive/diagnostic operation that should only be available to administrators.

Is this a bug?

No. The 403 is the correct and intended response for non-admin users.

Why does the UI poll it for non-admin users?

The Frigate frontend does not yet check the user's role before initiating the polling request. The UI sends the request optimistically and handles the 403 silently (the feature simply remains unavailable). This is a minor UX issue in the frontend — the poll should be skipped entirely if the user lacks admin role — but it is not a security or functional problem.

Fix (upstream — optional UX improvement)

The frontend should check remote-role before polling debug_replay/status and skip the poll entirely for non-admin users. This would eliminate the console noise.

No server-side fix needed or appropriate.

Workaround

None required. The feature is correctly unavailable to limited users. The console error can be ignored.

---

Summary table

Endpoint	Status for non-admin	Expected?	Fix needed
GET /api/profiles	403	No — bug	Add /profiles to EXEMPT_PATHS in auth.py
GET /api/debug_replay/status	403	Yes — by design	Optional: skip poll in frontend if role ≠ admin

---

Environment context

• Auth mode: auth.enabled: false — all auth delegated to Authelia via Traefik proxy headers
• Role resolution: Remote-Groups header from Authelia → mapped via proxy.header_map.role_map
• Admin group: Authelia group frigate-admin → Frigate role admin
• Limited group: Authelia group frigate-limited → Frigate role limited
• Viewer group: Authelia group frigate-viewer → Frigate role viewer
• Guest group: Authelia group frigate-guest → Frigate role guest
• Confirmed working: Auth endpoint correctly returns remote-role: admin when Remote-Groups: frigate-admin is presented (tested directly against FastAPI port 5001)

Beta Version

0.18.0-8f13932c

Issue Category

WebUI / Frontend

Frigate config file

na

Relevant Frigate log output

na

Relevant go2rtc log output (if applicable)

No response

Install method

Docker Compose

docker-compose file or Docker CLI command

na

Operating system

Debian

CPU / GPU / Hardware

No response

Screenshots

No response

Steps to reproduce

No response

Any other information that may be helpful

No response

[hawkeye217]

Thanks, this is fixed in #22828