Remote-SSH: browser sign-in on every query; prefer VS Code authentication before native auth

src/Server/Connections/ConnectionManager.cs と src/Server/Server.cs から始め、次に issue で説明されている対象を絞った ConnectionManagerTests コマンドを実行します。提案されたリモートホスト用のパスを評価する前に、既存のフォールバックと明示的な認証の動作を確認します。対象を絞ったテストが通り、明示的な資格情報とローカルルートが変更されず、連続するリモートクエリで認証が再利用されてブラウザーのプロンプトが繰り返し表示されなければ完了です。

Summary

On a Linux Remote-SSH host, Microsoft Kusto Explorer 1.0.1 opened the browser for interactive authentication on every query, including two consecutive executions of a trivial query. Both queries succeeded after sign-in.

A local server-side change to prefer the existing VS Code authentication provider for remote, HTTPS, federated connections stopped the repeated browser prompts. This is a locally verified workaround/proposed fix, not a claim that the underlying native authentication cache failure has been fully diagnosed.

Environment and baseline

• Microsoft Kusto Explorer: ms-kusto.kusto-explorer-vscode, version 1.0.1.
• Server assembly version: 1.0.1+fae8b0964f259fa72352bd736597a7cc64120645, matching tag v1.0.1.
• Extension host: Linux, Debian 13, connected through Remote-SSH.
• Language-server runtime: .NET 10.0.12, x64.
• Standard Azure Data Explorer connection using interactive user authentication.

Baseline qualification: The installed TypeScript client already contained an earlier local token-cache customization. That customization was unchanged during the server-only before/after comparison. A completely clean VSIX baseline has not been tested, so please treat this as a report of the observed environment rather than a universal reproduction for all stock installations.

Reproduction in the affected environment

1. Open VS Code connected to the Linux remote host.

2. Connect a KQL document to an accessible Kusto cluster and database.

3. Run:

   print AuthenticationCheck = 1
   

4. Complete the browser sign-in.

5. Immediately run the same query again.

Actual: A browser sign-in is required for both runs, although both queries eventually succeed. Reloading and signing in again did not resolve the original behavior.

Expected: Once signed in, subsequent queries reuse the authenticated session, subject to token expiry, MFA, and organizational sign-in policies.

Authentication-path analysis

In ConnectionManager.cs at v1.0.1:

• The primary connection builder uses native Kusto.Data authentication.
• ShouldUseFallback only checks whether the cluster has been marked as requiring fallback.
• ExecuteAsync promotes the cluster after a KustoClientAuthenticationException, then retries through the host-supplied authentication provider.

Consequently, native authentication that succeeds after prompting every time does not trigger the fallback. Client-side VS Code token caching cannot help that native route.

The host bridge is already registered by Server.cs for the vscode launch argument. The proposal is to select that existing bridge proactively on remote hosts, not to introduce another credential store.

Related implementation history: Add fallback connection authentication via vscode when primary fails.

Exact locally tested server changes

1. Make host-authentication preference optional in ConnectionManager

Add this field:

private readonly bool _preferHostAuthentication;

Replace the constructor with:

public ConnectionManager(
    IAuthenticationProvider? authProvider = null,
    bool preferHostAuthentication = false)
{
    _authProvider = authProvider;
    _preferHostAuthentication = preferHostAuthentication && authProvider != null;
}

Replace ShouldUseFallback with:

internal bool ShouldUseFallback(KustoConnectionStringBuilder builder)
    => _fallbackRequiredByCluster.ContainsKey(builder.Hostname)
        || (_preferHostAuthentication
            && builder.FederatedSecurity
            && !HasExplicitAuthentication(builder)
            && Uri.TryCreate(builder.DataSource, UriKind.Absolute, out var uri)
            && uri.Scheme == Uri.UriSchemeHttps);

Update the nested KustoConnection.UseFallback property to pass the builder:

private bool UseFallback => _manager.ShouldUseFallback(_primaryBuilder);

Leave CreateFallbackBuilder, the existing explicit-authentication checks, and the native-authentication failure/retry path intact.

2. Enable the preference for the remote VS Code server

In the stream-based Server constructor, replace the existing ConnectionManager initialization with:

var tokenProvider = _args.Contains("vscode")
    ? (IAuthenticationProvider)this
    : null;
var preferHostAuthentication = !string.IsNullOrEmpty(
    Environment.GetEnvironmentVariable("VSCODE_AGENT_FOLDER"));
_connectionManager = new ConnectionManager(
    tokenProvider, preferHostAuthentication);

VSCODE_AGENT_FOLDER was present in the affected remote server process. For an upstream implementation, maintainers may prefer an explicit signal from the client's vscode.env.remoteName rather than relying on this environment variable. The code above describes the exact locally validated approach, not a guarantee that this environment marker covers every remote-host type.

3. Build and reload

The local workaround was built from tag v1.0.1 with these server changes:

dotnet build src/Server/Server.csproj -c Release

After backing up the installed assembly and confirming all dependency versions matched, only the extension's server/Server.dll was replaced with the rebuilt assembly. A full Developer: Reload Window was needed: restarting only the language-server child process did not resend the saved connections in this session.

This describes a local development workaround, not a recommendation for general users to replace packaged binaries. An official extension release is the appropriate distribution mechanism.

Validation

• Added regression cases to ConnectionManagerTests for:

  • Selecting the host token-provider callback before any native failure.
  • Two consecutive token requests using that callback.
  • Preserving the preference in derived cluster/database connections.
  • Preserving application credentials, user tokens, and explicit user IDs.
  • Leaving HTTP and non-federated connections on their original route.
  • Keeping native authentication when no host provider is registered.

• 34 focused connection/authentication tests passed, including existing tests and the added regression cases, using the project's native MSTest runner:

  dotnet run --project src/ServerTests/ServerTests.csproj -c Release -- \
    --filter FullyQualifiedName~Tests.Features.ConnectionManagerTests
  

• All 40 dependency names/versions matched the installed server.

• Schema loading succeeded after reloading.

• The affected user confirmed two consecutive query executions succeeded without opening a browser after the server-only change.

The full token-expiry/refresh lifecycle, sign-out/account switching, Windows desktop SSO, and other remote-host types have not been validated by this local test. These should be covered before adopting an upstream change.

Request

Could the maintainers investigate this successful-but-repeatedly-interactive native-authentication case and consider preferring the existing VS Code authentication provider on remote hosts, while preserving explicit credentials and local desktop SSO?