Skip to content

mcp-data-platform-v0.33.1

Choose a tag to compare

View all tags
@github-actions github-actions released this 06 Mar 06:00
· 302 commits to main since this release
v0.33.1
151e680
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Highlights

v0.33.1 fixes two portal authentication bugs that prevented the browser-based portal from working correctly when OIDC authentication is enabled. Users hitting the root path (/) in a browser were getting a 401 instead of being redirected to the portal, and once inside the portal, admin API calls failed because browser sessions produced different role names than the MCP auth path.

Portal Role Prefix Consistency (#190)

The browser session OIDC flow and the MCP OAuth/OIDC flow handled role_prefix differently, making it impossible for persona role matching to work across both paths.

Root cause: extractRoles in the browser session path used strings.CutPrefix to strip the configured prefix (e.g., dp_admin became admin), while filterByPrefix in the MCP auth path used strings.HasPrefix and kept the full role name (dp_admin stayed dp_admin). Since persona definitions use a single roles list that must match both auth paths, the browser session's stripped roles never matched.

Fix: Changed extractRoles to filter-only behavior (keep the full role name), matching filterByPrefix. Both paths now produce identical role lists.

Before:  MCP → dp_admin, Browser → admin     (persona match fails for browser)
After:   MCP → dp_admin, Browser → dp_admin   (persona match works for both)

Root Path Redirect Ordering (#190)

When both portal UI and authentication are enabled, browser requests to / received a 401 instead of being redirected to /portal/.

Root cause: MCPAuthGateway wrapped outside browserRedirectMiddleware in the HTTP handler chain. Since the auth gateway is method-agnostic (rejects any request without credentials), browser GET requests hit the 401 before the redirect middleware could fire.

Fix: Moved browserRedirectMiddleware to wrap outside the auth gateway in mountRootHandler, so browsers are redirected before auth is evaluated. MCP clients (POST requests without Accept: text/html) still pass through to the auth gateway normally.

Before:  MCPAuthGateway → browserRedirect → handler   (browser GET → 401)
After:   browserRedirect → MCPAuthGateway → handler   (browser GET → 307 /portal/)

DOMPurify Security Update (#188)

Updated the portal UI's DOMPurify dependency from 3.3.1 to 3.3.2, which addresses:

  • A possible sanitization bypass caused by jsdom's faulty raw-text tag parsing
  • A prototype pollution issue when working with custom elements
  • Lenient config parsing in _isValidAttribute

Installation

Homebrew (macOS)

brew install txn2/tap/mcp-data-platform

Claude Code CLI

claude mcp add mcp-data-platform -- mcp-data-platform

Docker

docker pull ghcr.io/txn2/mcp-data-platform:v0.33.1

Verification

All release artifacts are signed with Cosign. Verify with:

cosign verify-blob --bundle mcp-data-platform_0.33.1_linux_amd64.tar.gz.sigstore.json \
  mcp-data-platform_0.33.1_linux_amd64.tar.gz
Assets 25
Loading