Skip to content

tdfs4ds.utils.vector_store_auth

tdfs4ds.utils.vector_store_auth

Auth configuration for the Teradata Enterprise Vector Store REST API.

This is a DIFFERENT auth channel than teradataml.create_context() — it authenticates against the Vector Store REST gateway used by VECTOR_STORE_BACKEND='teradata' (see tdfs4ds.agent.vector_store_teradata), not the regular database session.

Credentials are read directly from os.environ (pass-through vars, same tier as TDFS4DS_TD_*), not tdfs4ds.<ATTR> module config, because this must run immediately after create_context() succeeds — independent of tdfs4ds/config.py's module-attr load ordering.

Four mechanisms are tried in this priority order (first fully-configured group wins):

  1. JWT: BASE_URL + AUTH_TOKEN
  2. PAT: BASE_URL + PAT_TOKEN + PEM_FILE (+ optional USERNAME)
  3. Basic: BASE_URL + USERNAME + PASSWORD
  4. OAuth: BASE_URL + CLIENT_ID

JWT is tried first because it supplies a token the caller already holds — the other three make teradataml generate one, so an explicitly-provided token must never be silently ignored in favour of a generated one.

Every variable read here is TDFS4DS_-prefixed, deliberately. An in-cluster deployment whose platform injects a token under a generic name (OAUTH_ACCESS_TOKEN and the like) must map it explicitly::

TDFS4DS_VECTOR_STORE_AUTH_AUTH_TOKEN=$OAUTH_ACCESS_TOKEN

Reading such a name directly would let a token another component owns be sent to the Vector Store endpoint without anything in the configuration naming it.

If none is fully configured, this is a silent no-op (info log only) — most installs don't use the Teradata vector store backend at all. Any exception from teradataml.set_auth_token itself is caught, logged, and treated as non-fatal, mirroring every other best-effort step in lifecycle.setup().

logger module-attribute 

logger = getLogger('tdfs4ds')

_PREFIX module-attribute 

_PREFIX = 'TDFS4DS_VECTOR_STORE_AUTH_'

NOT_CONFIGURED_HINT module-attribute 

NOT_CONFIGURED_HINT = "Set TDFS4DS_VECTOR_STORE_AUTH_BASE_URL plus one of: AUTH_TOKEN (JWT — a token you already hold; in-cluster, map the platform's injected token onto it, e.g. TDFS4DS_VECTOR_STORE_AUTH_AUTH_TOKEN=$OAUTH_ACCESS_TOKEN), PAT_TOKEN+PEM_FILE (PAT), USERNAME+PASSWORD (Basic), or CLIENT_ID (OAuth)."

_env 

_env(name)

resolve_auth_mechanism 

resolve_auth_mechanism()

Resolve which set_auth_token mechanism the environment selects, without calling it — no token generation, no network, no side effect.

Returns (mechanism, kwargs, log_detail); (None, None, None) when no group is fully configured. This is the single definition of the mechanism table: configure_vector_store_auth executes it, and tdfs4ds.check_configuration inspects it in live=False mode.

kwargs carries secrets — pass it to set_auth_token and nothing else. log_detail is secret-free by construction (URLs, usernames and variable names only) and is the string safe to show a user.

configured_auth_variables 

configured_auth_variables()

Return the NAMES of the auth variables that are set — never the values.

Used by check_configuration to tell a user which half of a group they filled in ("BASE_URL is set but PAT_TOKEN is not").

configure_vector_store_auth 

configure_vector_store_auth()

Attempt to configure teradataml.set_auth_token from TDFS4DS_VECTOR_STORE_AUTH_* environment variables.

Must be called AFTER teradataml.create_context() has succeeded — PAT/ Basic/OAuth all derive username from the active DB session when it is omitted, and raise if there is no context and no username given.

Returns the mechanism name used — one of "JWT", "PAT", "Basic", "OAuth" — or None if no mechanism was fully configured. Never raises: any failure from set_auth_token itself is caught, logged as a warning, and reported as None.