From 3005ebd02d9164cad48497e6d25aa826374bd739 Mon Sep 17 00:00:00 2001
From: Asier Isayas <aisayas@microsoft.com>
Date: Wed, 19 Aug 2026 16:01:41 -0700
Subject: [PATCH] Add an E2E test that SQL connection string login skips the
 Portal Backend

Nothing asserted the defining behavior of the direct login path, so reverting the short-circuit in connectWithConnectionString would have gone unnoticed. The listener filters on the connectionstring route so it covers both generatetoken and accessinputmetadata, and leaves the account restriction check alone since that still runs for every API.
---
 src/HostedExplorer.tsx                        |  2 +-
 .../Helpers/ConnectionStringParser.test.ts    |  3 ---
 test/sql/connectionStringLogin.spec.ts        | 19 +++++++++++++++++++
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/src/HostedExplorer.tsx b/src/HostedExplorer.tsx
index 938f5ae95..14f2e88e8 100644
--- a/src/HostedExplorer.tsx
+++ b/src/HostedExplorer.tsx
@@ -36,7 +36,7 @@ const App: React.FunctionComponent = () => {
   // For handling encrypted portal tokens sent via query paramter
   const params = new URLSearchParams(window.location.search);
   const [encryptedToken, setEncryptedToken] = React.useState<string>(params && params.get("key"));
-  // Encrypted token logins resolve the account metadata through the Portal Backend, while SQL/Tables/Gremlin
+  // Encrypted token logins resolve the account metadata through the Portal Backend, while SQL/Table/Gremlin
   // connection-string logins derive it client-side, so both paths write to the same value.
   const [accountMetadata, setAccountMetadata] = React.useState<AccessInputMetadata>();
 
diff --git a/src/Platform/Hosted/Helpers/ConnectionStringParser.test.ts b/src/Platform/Hosted/Helpers/ConnectionStringParser.test.ts
index c35a571c8..4b30f7b69 100644
--- a/src/Platform/Hosted/Helpers/ConnectionStringParser.test.ts
+++ b/src/Platform/Hosted/Helpers/ConnectionStringParser.test.ts
@@ -85,9 +85,6 @@ describe("ConnectionStringParser", () => {
 
     expect(metadata.accountName).toBe(mockAccountName);
     expect(metadata.apiKind).toBe(DataModels.ApiKind.Cassandra);
-    // Cassandra still uses the Portal Backend proxy, so no client-side endpoints are constructed.
-    expect(metadata.documentEndpoint).toBeUndefined();
-    expect(metadata.apiEndpoint).toBeUndefined();
   });
 
   it("should fail to parse an invalid connection string", () => {
diff --git a/test/sql/connectionStringLogin.spec.ts b/test/sql/connectionStringLogin.spec.ts
index 50936a296..8359e6dee 100644
--- a/test/sql/connectionStringLogin.spec.ts
+++ b/test/sql/connectionStringLogin.spec.ts
@@ -83,6 +83,25 @@ test.describe("SQL account using connection string login", () => {
     expect(resultData?.id).toEqual(documentId);
   });
 
+  test("does not call the Portal Backend during login", async ({ page }) => {
+    // SQL derives the account metadata from the connection string and signs data-plane requests with the
+    // account key, so neither the encrypted token nor the access metadata endpoint should be hit.
+    const portalBackendCalls: string[] = [];
+    page.on("request", (request) => {
+      if (request.url().includes("/api/connectionstring/")) {
+        portalBackendCalls.push(request.url());
+      }
+    });
+
+    await loginWithConnectionString(page, connectionString);
+
+    const explorer = await DataExplorer.waitForExplorer(page);
+    const collectionNode = await explorer.waitForContainerNode(databaseId, containerId);
+    await expect(collectionNode.element).toBeAttached();
+
+    expect(portalBackendCalls).toEqual([]);
+  });
+
   test("opens Data Explorer when the connection string has the wrong account key", async ({ page }) => {
     // A well-formed but incorrect base64 account key. The login is accepted
     // without checking the key against the account, so the user gets into Data Explorer either way and