Repository navigation
fix(personality): save/create fails in SLM admin - JWT mismatch + add new personalities #1145
Description
Problem
- Saving personality settings at https://172.16.168.19/settings/admin/personality fails silently
- Admin cannot create new personalities via the SLM admin interface
Root Cause
The SLM frontend calls /autobot-api/personality/* which nginx proxies to the main backend (172.16.168.20:8443/api/personality/*).
The mutating endpoints (PUT, POST, DELETE) require check_admin_permission which validates a main backend JWT. But the SLM frontend sends its own SLM JWT (signed with SLM_SECRET_KEY), which the main backend cannot verify — returning 401.
GET requests work because they have no auth requirement.
Solution
- Add SLM backend personality proxy routes at
/api/personality/*that:- Validate the SLM JWT and require admin for mutations
- Forward all requests to the main backend using a shared
X-Internal-API-Keyheader
- Add
X-Internal-API-Keycheck to main backendcheck_admin_permission - Change frontend
API_BASEfrom/autobot-api/personalityto/api/personality(SLM backend)
Subtasks
- Add
AUTOBOT_INTERNAL_API_KEYto main backend auth_middlewarecheck_admin_permission - Add
AUTOBOT_INTERNAL_API_KEYandAUTOBOT_BACKEND_URLto SLM backend config - Create
autobot-slm-backend/api/personality_proxy.py(proxy router) - Register personality proxy router in SLM backend
main.py - Update SLM frontend
API_BASEinusePersonality.ts - Generate and deploy
AUTOBOT_INTERNAL_API_KEYto .env on both .19 and .20 - Rebuild SLM frontend and deploy to .19
Acceptance Criteria
- Save personality settings succeeds in SLM admin
- Create new personality succeeds in SLM admin
- Duplicate profile works
- Delete profile works
- No regressions in main frontend personality management
Activity
fix(personality): fix save/create in SLM admin via SLM backend proxy (#…
mrveiss commentedon Feb 23, 2026
✅ Implemented and deployed in commit 4e4ee87.
Root Cause
The SLM admin frontend was sending SLM JWT tokens (signed with
SLM_SECRET_KEY) directly to the main backend's personality API via the nginx/autobot-api/proxy. The main backend validates JWTs with its ownSECRET_KEYand uses different claim names (username/rolevssub/admin), so all mutating requests (PUT/POST/DELETE) were rejected with 401.Changes
autobot-slm-backend/api/personality_proxy.py(new): Catch-all proxy router at/api/personality/*. Validates SLM JWT for all requests; requiresadmin: trueclaim for mutations. Forwards to main backend withX-Internal-API-Keyheader.autobot-slm-backend/main.py: Register newpersonality_proxy_routerat/api.autobot-backend/auth_middleware.py: AddedX-Internal-API-Keycheck — if header matchesAUTOBOT_INTERNAL_API_KEYenv var, grant admin access without requiring a main-backend JWT.autobot-slm-frontend/src/composables/usePersonality.ts: ChangedAPI_BASEfrom/autobot-api/personalityto/api/personalityto route through the SLM backend proxy.Deployment
AUTOBOT_INTERNAL_API_KEYset on both .20 (main backend) and .19 (SLM backend via/etc/autobot/slm-secrets.env)AUTOBOT_BACKEND_URL=https://172.16.168.20:8443set on .19Verification: Both GET (profile list) and POST/PUT/DELETE (save, create, activate) now go through the SLM backend proxy, which validates the SLM admin JWT before forwarding.
fix(ansible): fix ownership of autobot-backend after unarchive (#1145)
fix(slm): restore agent control plane — internal-key gate on machine …
refactor(slm-frontend): migrate LLM/Personality/Settings domain onto …
security(settings): admin-gate the core /api/settings routes, and rec…
security(auth): admin-gate the open routers, settings, teams and user…