Bug #22228
closed
Report the correct upstream expires_at value for cached remote ApiClientAuthorizations
Added by Brett Smith 6 months ago.
Updated about 1 month ago.
Release relationship:
Auto
Description
Steps to reproduce:
- Log into Workbench on a Curii cluster.
- User menu→Get API token
- Note the token expires in 14 days, per cluster configuration.
- Close the dialog.
- User menu→Get API token
Expected behavior: The token still expires in 14 days.
Actual behavior: The dialog reports that the token expires in 5 minutes. This is apparently a Workbench display bug: fetching the API token with another client still reports the expected expires_at. This behavior appears across clients. You can replace step 5 with arv api_client_authorization current (using the token you got in step 2) and see a 5-minute expiry there too.
Proposed solution:
Add an internal column called refresh_at which determines when the token expires or must be refreshed. It is set to the earlier of expires_at or now + token refresh time (only if the token is federated).
Token validation only checks this new column.
This way, expires_at reflects the upstream value, but the actual API server behavior is what we want.
This inconsistency might be due to federation. The token is only valid on the satellite cluster for a certain amount of time (which I think defaults to 5m) before in needs to be re-validated. To get the true expiration time requires contacting the upstream cluster. It seems like controller isn't doing that, and neither is workbench.
- Target version set to Development 2025-01-29
- Target version changed from Development 2025-01-29 to Development 2025-02-12
- Target version changed from Development 2025-02-12 to Development 2025-02-26
- Target version changed from Development 2025-02-26 to Development 2025-03-19
- Description updated (diff)
- Description updated (diff)
- Category changed from Workbench2 to API
- Description updated (diff)
- Target version changed from Development 2025-03-19 to Development 2025-02-26
- Target version changed from Development 2025-02-26 to Development 2025-03-19
- Subject changed from Viewing API token a second time reports it expires in 5 minutes to Report the correct upstream expires_at value for cached remote ApiClientAuthorizations
Note that the Rails upgrade in progress on #22608 touches some of this code so there's a risk of merge conflicts if both are in development at once.
- Assigned To set to Tom Clegg
- Status changed from New to In Progress
22228-separate-expire-and-refresh @ d06efdb70673c4ae66bc6122e29a09416f703fd2 -- developer-run-tests: #4703 
- All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
- ✅ add internal column refreshes_at
- ✅ if refreshes_at is in the past, token is not accepted
- ✅ when caching a remote token, the cache assigns refreshes_at, and preserves the upstream expires_at
- ✅ when auto-deleting expired tokens, we also delete tokens with refreshes_at < now (in a separate statement, to make sure postgresql doesn't skip the indexes)
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- Code is tested and passing, both automated and manual, what manual testing was done is described.
- ✅ existing tests updated to use refreshes_at to "uncache"
- ✅ new test to check the OP issue is solved, i.e., expires_at is the value from upstream
- New or changed UX/UX and has gotten feedback from stakeholders.
- Documentation has been updated.
- Behaves appropriately at the intended scale (describe intended scale).
- no anticipated scaling issues
- Considered backwards and forwards compatibility issues between client and server.
- n/a - clients don't see the new field, they just see less-confusing values in the expires_at field
- Follows our coding standards and GUI style guidelines.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by