GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — [coverage] Conformance findings: AUTH-019 · Issue #1034 · databricks/databricks-sql-python

[coverage] Conformance findings: AUTH-019 #1034

New issue
Copy link
New issue
Copy link
Open
Open
[coverage] Conformance findings: AUTH-019#1034
Copy link

Description

@peco-engineer-bot
peco-engineer-bot
bot
opened on Nov 12, 2026
Issue body actions

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-python) is fixed, then flips green as a tripwire.

Findings

  • AUTH-019 [sea]: kernel/SEA OAuth M2M does not normalize oauth_scopes: list entries are forwarded verbatim, so a padded/duplicated entry sends a repeated scope token and a whitespace-only entry sends a blank scope the token endpoint rejects (HTTP 400 invalid_scope) instead of falling back to all-apis (backend/kernel/auth_bridge.py::_normalize_scopes)
    • failing test: test_oauth_m2m_token_request_uses_configured_scopes (see the coverage PR diff under tests/)
  • AUTH-019: kernel/SEA OAuth M2M does not normalize oauth_scopes: list entries are forwarded verbatim, so a padded/duplicated entry ([" sql sql "]) sends a repeated scope token and a whitespace-only entry ([" "]) sends a blank scope that the workspace token endpoint rejects with HTTP 400 invalid_scope instead of falling back to the all-apis default (backend/kernel/auth_bridge.py::_normalize_scopes)

Reproduce & Expected

AUTH-019 — Verifies that the driver's OAuth scopes option decides what the client-credentials (M2M) token request asks for, instead of always requesting all-apis, so a service principal whose secret is scoped…

Reproduce:

SELECT CURRENT_USER() AS user
SELECT CURRENT_USER() AS user
SELECT CURRENT_USER() AS user
SELECT CURRENT_USER() AS user

Expected (per the shared spec):

  • result has exactly 1 row(s)
  • result has exactly 1 row(s)
  • result has exactly 1 row(s)
  • result has exactly 1 row(s)
  • full assertion contract:
result:
- label: configured_scopes
  oauth_token_request_scope_tokens:
    grant_type: client_credentials
    equals:
    - sql
- label: configured_scopes
  row_count: 1
- label: sloppy_scopes
  oauth_token_request_scope_tokens:
    grant_type: client_credentials
    equals:
    - sql
- label: sloppy_scopes
  row_count: 1
- label: blank_scopes
  oauth_token_request_scope_tokens:
    grant_type: client_credentials
    equals:
    - all-apis
- label: blank_scopes
  row_count: 1
- label: unset_scopes
  oauth_token_request_scope_tokens:
    grant_type: client_credentials
    equals:
    - all-apis
- label: unset_scopes
  row_count: 1
protocol:
  thrift:
  - call_min:
      method: OpenSession
      min: 1
  sea:
  - call_min:
      operation: CreateSession
      min: 1

Context

  • The behavior was first fixed in a DIFFERENT driver — reference PR: fix: honor oauthScopes on OAuth M2M token requests databricks-sql-nodejs#583 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-python; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
  • Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/2020

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.