{{ message }}
Fix bogus authentication error for unquoted user name in remote() table function#104465
Merged
Conversation
Previously a bare identifier in the user-name position of `remote` and
`remoteSecure` was silently treated as a sharding key, so a query like
SELECT count() FROM remoteSecure('host', default, github_events, explorer)
attempted to authenticate as `default` (with no password) and failed
with the misleading error
default: Authentication failed: password is incorrect, or there is
no user with such name.
The user name now also accepts unquoted identifiers, consistent with
how the database and table arguments work. The password still must be
a string literal.
Closes #33816.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
The previous commit changes parsing in the `remote` and `remoteSecure` table functions so that a bare identifier in the user-name position is interpreted as the user name (rather than silently treated as a sharding key). Existing tests that relied on the old behaviour were passing a bare column name as the sharding key, which now collides with that position and causes `AUTHENTICATION_FAILED`. Wrap those sharding-key arguments in `identity` to match the convention already used in `01932_remote_sharding_key_column.sql`. Affected fast-test failures: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=104465&sha=87611b6c25445b8e512ed7f863bfb69b357c845d&name_0=PR&name_1=Fast%20test Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Master picked up another `04212_*` test, so rename ours to `04213_*` to keep test numbering unique. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 10, 2026
Member
Author
|
Let's not break the compatibility. |
Per review feedback, accept an unquoted identifier as the user name only
when it is followed by a string-literal password. This preserves the
historical behavior of `remote('host', db.table, sharding_key)`, where a
bare identifier at the same position is silently treated as a sharding
key (e.g. `remote('127.1', system.one, identity(dummy))` or, more
importantly, code passing a column reference there).
The previous version of this PR accepted a bare identifier as the user
name unconditionally, which would have changed the meaning of existing
queries that relied on a single trailing identifier being parsed as a
sharding key.
With this change:
- `remote('host', db.table, 'user', 'password')` -- unchanged
- `remote('host', db.table, user, 'password')` -- now also valid
- `remote('host', db.table, sharding_key_ident)` -- unchanged (identifier
with no subsequent literal password still falls through to the
sharding-key slot)
This reverts the unrelated `identity(...)` wrappings introduced in the
previous revision of this PR, since they are no longer required.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
LLVM Coverage ReportChanged lines: 100.00% (15/15) · Uncovered code |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Closes #33816.
Previously a bare identifier in the user-name position of
remoteandremoteSecurewas silently treated as a sharding key, so a query likeattempted to authenticate as
default(with no password) and failed with the misleadingThe user name now also accepts unquoted identifiers, consistent with how the database and table arguments work. The password still must be a string literal.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
Allow an unquoted identifier as the user name in the
remoteandremoteSecuretable functions, mirroring how the database and table arguments accept unquoted identifiers. Previously such a query failed with a misleading authentication error referring to thedefaultuser.Documentation entry for user-facing changes
Version info
26.5.1.540