Skip to content

Feature/access token provider - #1498

Open
vmitsenko wants to merge 2 commits into
masterfrom
feature/access-token-provider
Open

vmitsenko wants to merge 2 commits into
masterfrom
feature/access-token-provider

Conversation

@vmitsenko

Copy link
Copy Markdown
Collaborator

Summary

access_token can now be a callable. TM1py attaches it to the session as a requests AuthBase (BearerTokenAuth) and calls it on every request, so a caller's token provider can refresh the token before it expires: no 401, no reconnect, no new TM1 session.

TM1py stays headless: getting, refreshing and storing tokens is left to the caller. This replaces the approach in #1488/#1494/#1495 (reconnect-based refresh, keep_authorization_header, browser sign-in, local listener, token storage inside TM1py).

String tokens behave as before. A callable that returns an empty token raises ValueError.

Changes

  • RestService: BearerTokenAuth, used when access_token is callable; docstring entry for access_token
  • Tests/RestService_access_token_test.py: offline tests with a patched adapter: per-request token, refresh without reconnect, 401 retry, async polling, threads, unchanged string-token behaviour
  • Tests/RestService_oauth_test.py: live tests, skipped without an [oauth] section in config.ini (either access_token, or refresh settings); documented in config.ini.template
  • README: "Accessing TM1 REST APIs through Planning Analytics Workspace"

Tested

PAaaS, TM1 12.6.4, via https://<PawHost>/api/v1/tm1/<db>:

  • all live tests pass;
  • the token refreshed mid-session is sent on the next request, with the same TM1 session and no reconnect.

Observed:

  • no tenant ID needed;
  • PAW sets no cookies and keeps one TM1 session per user;
  • refresh tokens are single-use.

🤖 Generated with Claude Code

A callable access_token is now attached to the session as a requests
AuthBase (BearerTokenAuth) and called on every outgoing request,
instead of being sent once at session start. A token provider (e.g. an
OAuth client) can refresh the token before it expires, without a 401
or a new TM1 session. TM1py stays headless: obtaining, refreshing and
storing the token is left to the caller.

String tokens behave as before (sent at session start, then dropped).
A callable that returns an empty token raises ValueError.

Tested against PAaaS (TM1 12.6.4) through PAW's /api/v1/tm1/<db>
route: refreshing the token mid-run needs no reconnect and keeps the
same TM1 session.
@vmitsenko
vmitsenko requested a review from MariusWirtz October 21, 2026 10:10

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants