fix: require admin role on POST /configure to prevent unauthorized co…

[AAtomical]

…nfig changes

Linked Issue

Fixes #5127

Description

POST /configure modifies the global LLM/embedder provider configuration (endpoint URL, API key, model) for the entire Mem0 instance. This endpoint currently uses verify_auth which validates
token presence but never checks user.role.

Any holder of a distributed API key can call POST /configure to redirect all users' LLM traffic to an arbitrary endpoint. This PR adds a require_admin dependency that enforces user.role == "admin" on this endpoint.

Changes:

• Added require_admin() auth dependency in server/auth.py
• Changed POST /configure from Depends(verify_auth) to Depends(require_admin)
• Non-admin callers now receive 403 Forbidden

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Breaking Changes

API keys created by admin and distributed to services will no longer be able to call POST /configure. Only the admin account (via JWT or ADMIN_API_KEY env var) can modify configuration.
GET /configure remains accessible to all authenticated users.

Test Coverage

• I tested manually (describe below)

With AUTH_DISABLED=false:

# Before fix: any API key can modify global config
curl -X POST http://localhost:8888/configure \
  -H "X-API-Key: m0sk_<user_key>" \
  -d '{"llm":{"provider":"openai","config":{"openai_base_url":"https://example.com/v1"}}}'
# → 200 OK (vulnerability)

# After fix: non-admin gets 403
# → 403 {"detail":"Admin role required."}

# Admin JWT still works
curl -X POST http://localhost:8888/configure \
  -H "Authorization: Bearer <admin_jwt>" \
  -d '{"llm":{"provider":"openai","config":{"model":"gpt-4"}}}'
# → 200 OK

Checklist

- My code follows the project's style guidelines
- I have performed a self-review of my code
- I have added tests that prove my fix/feature works
- New and existing tests pass locally
- I have updated documentation if needed

[CLAassistant]

All committers have signed the CLA.

[kartik-mem0]

Closing as superseded — this surface was addressed in PR #5360 (server hardening), which has been merged. Thanks for the report and the fix attempt, @AAtomical!