mirror of
https://github.com/bitechdev/ResolveSpec.git
synced 2026-08-28 12:02:35 +00:00
warkanum
dab4940ace
Tests / Unit Tests (push) Failing after 13s
Tests / Integration Tests (push) Failing after 27s
Build , Vet Test, and Lint / Run Vet Tests (1.24.x) (push) Successful in 33s
Build , Vet Test, and Lint / Run Vet Tests (1.23.x) (push) Successful in 35s
Build , Vet Test, and Lint / Build (push) Successful in 35s
Build , Vet Test, and Lint / Lint Code (push) Successful in 39s
RefreshToken() hardcoded LoginResponse{Token: userCtx.SessionID, ExpiresIn: 24h}
and silently discarded anything else resolvespec_refresh_token returned. An
implementation that issues its own independent, rotating refresh token (not
just reusing the session/access token as its own refresh token) has nowhere
else to put the new refresh token and real access-token expiry than
UserContext.Claims, since UserContext has no dedicated fields for either.
Now reads claims.refresh_token/claims.expires_in when present and surfaces
them into LoginResponse.RefreshToken/ExpiresIn. Implementations that don't
set these claims keep today's behavior unchanged (empty RefreshToken, 24h
ExpiresIn default) — purely additive, no breaking change.