Allow selecting HTTP transport in DBSQLClient.connect()
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 72/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- node.js, typescript
- Bereich
- api, networking
Rechercherichtung
Beginne mit lib/contracts/IDBSQLClient.ts und lib/DBSQLClient.ts und untersuche anschließend die vorhandenen HTTP-Transporttests sowie den HTTP-Proxy-E2E-Test. Bestätige, dass die öffentlichen Verbindungsoptionen die vereinbarte Transporteinstellung bereitstellen, HTTPS weiterhin der Standard ist und eine explizite HTTP-Auswahl die bestehende Verbindungsimplementierung ohne den Workaround über eine private Methode erreicht.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Summary
Please expose the existing HTTP transport support through the public DBSQLClient.connect() options.
I would be happy to submit a PR implementing this change if the maintainers agree with the proposed direction and public API.
The lower-level connection implementation supports both HTTP and HTTPS, but DBSQLClient currently hardcodes HTTPS.
Motivation
Some deployments connect to Databricks through a trusted local or internal reverse proxy, sidecar, or gateway:
Application --HTTP--> Internal proxy --HTTPS--> Databricks
In our concrete setup, authentication is also handled at the proxy level. The proxy injects the Databricks bearer token, while the application intentionally provides no authorization header.
This authentication arrangement is only one use case. The general issue is that callers cannot select the transport protocol for the endpoint supplied to DBSQLClient.
The existing proxy option does not address this scenario because it represents a forward proxy using CONNECT semantics, rather than a reverse proxy exposed as the Databricks endpoint.
Current behavior
The public ConnectionOptions type in lib/contracts/IDBSQLClient.ts does not expose an HTTP/HTTPS option.
Additionally, DBSQLClient.getConnectionOptions() in lib/DBSQLClient.ts hardcodes:
https: true,
Consequently, passing an untyped https: false value does not work: it is discarded and the client still connects using an https:// URL.
The internal implementation already appears to support the requested behavior:
IConnectionOptionsincludeshttps?: booleanHttpConnectionselects eitherhttp.Agentorhttps.AgentHttpConnectionconstructs either anhttp://orhttps://URL- existing tests exercise the HTTP behavior
- the HTTP proxy E2E test overrides
getConnectionOptions()to sethttps = false
Proposed API
Expose the existing option publicly while preserving HTTPS as the default:
await client.connect({
host: 'localhost',
port: 3015,
path: '/proxy/databricks/sql/1.0/warehouses/<warehouse-id>',
https: false,
authType: 'custom',
provider: {
async authenticate() {
return {};
},
},
});
The implementation could map it as follows:
https: options.https ?? true,
Alternatively, a more explicit public option could be introduced:
protocol?: 'http' | 'https';
HTTPS should remain the default, and HTTP should require explicit opt-in.
Current workaround
We currently override the private connection-options mapper:
type PublicConnectionOptions = Parameters<DBSQLClient['connect']>[0];
type InternalConnectionOptions = {
https?: boolean;
[key: string]: unknown;
};
type ClientConnectionOptionsFactory = {
getConnectionOptions(
options: PublicConnectionOptions,
): InternalConnectionOptions;
};
const client = new DBSQLClient();
const internalClient =
client as unknown as ClientConnectionOptionsFactory;
const getConnectionOptions =
internalClient.getConnectionOptions.bind(client);
internalClient.getConnectionOptions = (options) => ({
...getConnectionOptions(options),
https: false,
});
This works end to end and preserves the driver's normal connection handling, but it relies on a private method and may break between releases.
Security considerations
Plain HTTP should be documented as appropriate only for trusted local or private-network connections.
In our setup:
- the application-to-proxy connection is local/internal
- the proxy injects the Databricks token at the proxy layer
- the application does not send Databricks credentials over HTTP
- the proxy-to-Databricks connection uses HTTPS
Environment
@databricks/sql: 2.0.0
- Vorherrschende Sprache
- TypeScript
- Sterne
- 36
- Forks
- 50
- Ø Merge
- 13 Std. 46 Min.
- Gemergte PRs (30 T.)
- 9
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus databricks/databricks-sql-nodejs
-
engineer-bot
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
databricks/databricks-sql-nodejs#274 · 1 Kommentar · 1 Reaktion ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100
Alle Issues in databricks/databricks-sql-nodejs
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
calcite-components needs triage refactor
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Esri/calcite-design-system#15203 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 78/100
fullcalendar/fullcalendar#8106 ·