Allow selecting HTTP transport in DBSQLClient.connect()
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 72/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- node.js, typescript
- Lĩnh vực
- api, networking
Hướng nghiên cứu
Bắt đầu với lib/contracts/IDBSQLClient.ts và lib/DBSQLClient.ts, sau đó kiểm tra các bài kiểm thử HTTP transport hiện có và bài kiểm thử E2E của HTTP proxy. Xác nhận rằng các tùy chọn kết nối công khai expose thiết lập transport đã thống nhất, HTTPS vẫn là mặc định và việc chọn HTTP một cách tường minh sẽ đi tới implementation kết nối hiện có mà không cần workaround bằng private method.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- TypeScript
- Star
- 36
- Fork
- 50
- Merge trung bình
- 13 giờ 46 phút
- Pull request đã merge (30 ngày)
- 9
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của databricks/databricks-sql-nodejs
-
Docs folder deleted in 1.8.4 Đang mởengineer-bot
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
databricks/databricks-sql-nodejs#274 · 1 bình luận · 1 reaction ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
Tất cả issue của databricks/databricks-sql-nodejs
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
[Bug]: Matrix progress drafts fail with "Matrix runtime not initialized" during tool activity Đang mởbug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
Client support matrix inclusion Đang mởenhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
calcite-components needs triage refactor
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Esri/calcite-design-system#15203 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
fullcalendar/fullcalendar#8106 ·