yasithdev opened a new pull request, #182:
URL: https://github.com/apache/airavata-portals/pull/182
## Summary
`KeycloakTokenAuthentication` derived a lightweight non-DB `KeycloakUser`
from the token for **every** request — including browser-session requests that
are bridged via the session-stored access token. That broke every view that
depends on the DB-backed user the session login establishes:
- `UserViewSet.current` does `redirect(... pk=request.user.id)` → **500**
`'KeycloakUser' object has no attribute 'id'`
- the user/profile serializers read `request.user.user_profile`, etc.
## Change
When the token comes from the **session** (no `Authorization: Bearer`
header), reuse the DB-backed user the Django session login already established.
A pure **Bearer** request (API / desktop client) has no session user, so it
still gets the non-DB `KeycloakUser` derived from the verified token claims.
The token is validated identically in both cases.
This keeps the interim session bridge behaving like the pre-pure-token
portal for browser users (so the still-DB-backed user/profile subsystem works),
while pure-token clients are unaffected. The eventual end state (frontend sends
Bearer; DB `User` removed) is unchanged.
## Testing
- `manage.py check` — green.
- Live, logged in via the browser session:
- `/auth/users/current/`: **500 → 302 → user-detail 200** (full
`UserSerializer` payload: `username`, `complete`, `email`, …)
- `/workspace/dashboard`: 200
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
