markhoerth opened a new pull request, #12439: URL: https://github.com/apache/gravitino/pull/12439
### What changes were proposed in this pull request? `--token` accepts a credential of any authorization scheme, not only an OAuth2 Bearer token. A value that starts with a scheme is sent as-is. A value with no scheme is prefixed with `Bearer`, as before. ``` --token "abc" sends Authorization: Bearer abc --token "Basic dXNlcjpwYXNz" sends Authorization: Basic dXNlcjpwYXNz --token "" sends no header ``` | File | Change | | --- | --- | | `mcp-server/mcp_server/core/context.py` | `startup_authorization` checks for a scheme before prefixing | | `mcp-server/mcp_server/core/setting.py` | Field comment describes both forms | | `mcp-server/mcp_server/main.py` | `--token` help text describes both forms | | `mcp-server/tests/unit/test_auth_flow.py` | New `TestStartupAuthorization`, seven cases | Recognised schemes are `basic`, `bearer`, `negotiate` and `digest`, matched case-insensitively, and only when a credential follows. ### Why are the changes needed? The MCP server does not authenticate anyone. It attaches a credential to each call it makes to Gravitino, and Gravitino decides. The credential comes from one of two places: 1. The `Authorization` header on the incoming request, forwarded unchanged. 2. `--token`, when the incoming request has no such header. The first accepts any scheme. The second was OAuth2 only. That leaves one combination broken: a Gravitino server running `authenticators: basic`, reached by a client that cannot set its own header. Anonymous fails, because the server wants a credential. `--token` fails too, because whatever you put there is sent as `Bearer`, which the server does not accept. Both return: ``` Error code: 1011, Error type: UnauthorizedException, Error message: The provided credentials did not support ``` There is no third option, so those clients cannot reach the server at all. They are also the clients `--token` exists for. An MCP client is typically configured with a URL and nothing else, has no browser for an OAuth flow, and often cannot attach a header. `--token` is how an operator gives that client an identity, and it could not express the identity the server was asking for. Nothing is protected by the restriction. The forwarding path already sends `Basic` credentials to the same server on the same connection. Fix: #(issue) ### Does this PR introduce _any_ user-facing change? No new or changed CLI arguments or environment variables. `--token` and `GRAVITINO_TOKEN` accept the same values as before, plus values that carry a scheme. One existing behaviour changes: a value already beginning with `Bearer ` was sent as `Bearer Bearer <token>` and is now sent once. That form was always rejected by the server, so nothing that worked before stops working. ### How was this patch tested? ```shell cd mcp-server python -m pytest tests/unit/test_auth_flow.py -v python -m pytest tests/unit -q ``` 19 tests pass in `test_auth_flow.py`, 179 across `tests/unit`, no regressions in `test_per_request_token.py`. `black` and `isort` clean, `pylint` 10.00 on the changed files. The new cases: a bare token is prefixed; a `Bearer` value is not double-wrapped; a `Basic` value passes through; a lower-case scheme matches; an empty token stays empty; whitespace is stripped before prefixing; and a bare `Bearer` with nothing after it is treated as a token, not a scheme. Found on Kubernetes, running Gravitino 1.3 with `authenticators: basic`. Before this change an MCP `tools/call` returned the error above, both anonymously and with `--token` holding a `Basic` credential. After it, the same call succeeds. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
