Antalya 26.3: add --jwt-command to client#1809
Conversation
zvonand
added
port-antalya
CI report: https://altinity-build-artifacts.s3.amazonaws.com/json.html?PR=1809&sha=02d52acedc65b24bf011bc1171266ea1ff8a5907&name_0=PR&name_1=Stateless+tests+%28amd_debug%2C+distributed+plan%2C+s3+storage%2C+parallel%29&name_2=Tests Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…e-token-in-client
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 38da1d22e8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…of github.com:Altinity/ClickHouse into feature/antalya-26.3/oauth-executable-token-in-client
…e-token-in-client
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
ClickHouse/programs/client/Client.cpp
Line 992 in d0ccc64
Reject --login when jwt-command is configured
This guard only checks config().has("jwt"), so a jwt-command coming from config.xml is not treated as conflicting with --login. In that case the --login path can run the interactive OAuth flow and set a JWT, and only later main fails with "jwt-command and jwt cannot both be specified". The conflict should be detected here as well (checking jwt-command too) so users get an immediate BAD_ARGUMENTS error without side effects.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Remove `goto` from `--login` handling, wrap conflict check in `#if USE_JWT_CPP && USE_SSL` (fixes fast_test build), unbuffer `--jwt-command` stderr so interactive prompts surface live, and trim verbose comments. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 45a1975f20
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| else if (jwt_provider && JWTProvider::isJWT(jwt)) | ||
| { | ||
| const Poco::Timestamp expiry = JWTProvider::getJwtExpiry(jwt); | ||
| const Poco::Timestamp refresh_threshold = Poco::Timestamp() + Poco::Timespan(30, 0); | ||
| if (expiry > Poco::Timestamp(0) && expiry < refresh_threshold) | ||
| jwt = jwt_provider->getJWT(); |
There was a problem hiding this comment.
When a client stays connected past a JWT's exp, this refresh path is never revisited because it only runs from Connection::connect; sendQuery now just reuses the already-open connection. The server records token expiry in the session and Session::checkIfUserIsStillValid throws USER_EXPIRED once it passes, so long-lived --login / --jwt-command sessions will start failing queries instead of fetching a fresh token and reconnecting as the removed sendQuery refresh did.
Useful? React with 👍 / 👎.
`Session::checkIfUserIsStillValid` ran on every query and terminated an already-established session once the authenticating token passed its `exp` (or once its token processor was removed by a config reload, M-28). For TCP sessions this killed a live `clickhouse-client` connection mid-session, which contradicts how password sessions behave: a session is validated only when it is established (initial connect or reconnect), never re-checked per query. Token expiry is still enforced where it belongs -- at `Session::authenticate`, so an expired token can never establish or re-establish a session. This only drops the per-query re-validation on a connection that is already up. Revert the H-05 token-expiry binding and the M-28 processor-removal recheck, keeping only the upstream `VALID UNTIL` enforcement (an explicit, opt-in admin policy that applies to password sessions too). Removes the now-dead `auth_token_expires_at` session field and the `hasTokenProcessor` helper. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Left over after removing the M-28 processor recheck. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 participants
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
clickhouse-client: added--jwt-commandand --jwt-command-timeout, which invokes an external script to obtain a JWT for authentication; the script is re-invoked on every reconnect.CI/CD Options
Exclude tests:
Regression jobs to run: