This is an automated email from the ASF dual-hosted git repository. cgivre pushed a commit to branch feat/drill-mcp-server in repository https://gitbox.apache.org/repos/asf/drill-mcp.git
commit 1b5dabeef025e14a36070722edd77425d247bab7 Author: cgivre <[email protected]> AuthorDate: Tue Aug 11 19:03:15 2026 -0400 docs: record the login body check and the reference-implementation decision Drill's j_security_check returns 200 with an HTML error page on bad credentials, so a status-only check accepts a wrong password. Records the two-part check and the evidence from sqlalchemy-drill. Also records why PyDrill was evaluated and rejected as a dependency: no form login, no Kerberos, last release 2018. --- .gitignore | 4 ++++ .../specs/2026-08-11-drill-mcp-design.md | 25 ++++++++++++++++++++++ 2 files changed, 29 insertions(+) diff --git a/.gitignore b/.gitignore index b733d78..de2b5c7 100644 --- a/.gitignore +++ b/.gitignore @@ -5,3 +5,7 @@ __pycache__/ dist/ build/ .venv/ + +# IDEs +.idea/ +.vscode/ diff --git a/docs/superpowers/specs/2026-08-11-drill-mcp-design.md b/docs/superpowers/specs/2026-08-11-drill-mcp-design.md index 56f5b75..75ec7b2 100644 --- a/docs/superpowers/specs/2026-08-11-drill-mcp-design.md +++ b/docs/superpowers/specs/2026-08-11-drill-mcp-design.md @@ -11,6 +11,24 @@ management state. Intended to be donated as the official Drill MCP server, so it must be conservative by default: a misbehaving model must not be able to mutate cluster configuration or write data into a store nobody authorized. +## Reference implementations + +Consult these for Drill wire behavior rather than reasoning from first +principles — REST auth, INFORMATION_SCHEMA query shapes, identifier quoting, +JDBC connection strings, type mapping: + +- **`sqlalchemy-drill`** — the actively maintained Drill dialect for SQLAlchemy, + covering both the REST and JDBC paths. The authority used here. +- **PyDrill** — a Python client for Drill's REST API. + +Neither is a runtime dependency. PyDrill was evaluated and rejected as one: its +last release was April 2018, and it supports only HTTP basic auth via a +`requests` session, with no `j_security_check` form login and no Kerberos — +precisely the two auth modes this server requires. It would have saved a handful +of GET wrappers while adding a stale dependency to a project intended for ASF +donation, and it exposes `storage_enable`, a mutation this design never +implements. + ## Non-goals - Storage plugin creation, update, or deletion. These REST endpoints are never @@ -194,6 +212,13 @@ Three modes, selected by config: - `basic` — Drill's HTTP form login (`/j_security_check`); the resulting session cookie is held on the httpx client and reused. On a 401 mid-session the client re-authenticates once and retries. + + **A login is successful only when the status is 200 *and* the body does not + contain Drill's `Invalid username/password credentials` marker.** Drill + returns 200 with an HTML error page on bad credentials, so a status-only check + accepts a wrong password as a successful login. `sqlalchemy-drill` does the + same two-part check (`sqlalchemy_drill/drilldbapi/_drilldbapi.py`), treating a + non-200 as a connection failure and the body marker as an auth failure. - `kerberos` — SPNEGO via `requests-kerberos`/`httpx-gssapi` for REST; the JDBC backend uses the driver's own Kerberos support.
