gupta-sahil01 opened a new issue, #7045:
URL: https://github.com/apache/texera/issues/7045
### Task Summary
`agent-service/src/api/` currently has no test coverage — none of its four
modules (`auth-api.ts`, `backend-api.ts`, `workflow-api.ts`,
`execution-api.ts`)
has a corresponding `.spec.ts`. It is the only directory in the service
without
any tests; `src/agent/tools/` and `src/agent/util/` are both covered.
This task covers `auth-api.ts` only, so the change stays small. The remaining
three modules are HTTP clients that need a stubbed `fetch`, and are better
handled as a follow-up.
`auth-api.ts` is the authentication gate for the whole service. Every request
that asks the agent to act on a user's behalf passes through it in
`server.ts:187-195`:
const userToken = extractBearerToken(headers.authorization);
if (!userToken) throw new Error("Authorization header ... is required");
if (!validateToken(userToken)) throw new Error("Invalid or expired
token");
const userInfo = extractUserFromToken(userToken);
The exported functions are pure and dependency-free, so they can be tested
directly with no mocking or network access.
### Proposed cases
`extractBearerToken`
- returns the token from a well-formed `Bearer <token>` header
- accepts any casing of the scheme (`bearer`, `BEARER`)
- returns `undefined` for a missing header, a non-Bearer scheme, and a
`Bearer` header with no token
`extractUserFromToken`
- maps the backend claim names (`userId`, `sub`, `email`, `role`, set in
`JwtAuth.jwtClaims`) onto `UserInfo`
- applies the empty-email and `REGULAR`-role fallbacks when those claims are
absent
- throws on a token that is not three segments, and on a non-JSON payload
`validateToken`
- accepts an `exp` in the future, rejects one in the past
- rejects a malformed token
- pins current behaviour for a token carrying no `exp` claim (see question
below)
### Open question
`validateToken` only checks expiry — it never verifies the signature, and
`isTokenExpired` (`auth-api.ts:49`) treats a token with no `exp` claim as
never expiring. Both look intentional, since the Scala backend verifies the
signature properly and `JwtAuth.jwtClaims` always sets an expiry. I plan to
write the tests against current behaviour and flag it here rather than change
anything. Happy to be corrected if either is actually a gap.
### Notes
Tests run with `bun test` from `agent-service/`, following the existing style
in `src/agent/util/context-utils.spec.ts`. No production code changes.
### Task Type
- [ ] Refactor / Cleanup
- [ ] DevOps / Deployment / CI
- [x] Testing / QA
- [ ] Documentation
- [ ] Performance
- [ ] Other
--
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]
