kayx23 commented on code in PR #14168: URL: https://github.com/apache/apisix/pull/14168#discussion_r4490537250
########## CHANGELOG.md: ########## @@ -87,6 +88,67 @@ title: Changelog - [0.7.0](#070) - [0.6.0](#060) +## 3.20.0 + +**The changes marked with :warning: are not backward compatible.** + +### Change + +- :warning: feat!: remove the `mcp-bridge` plugin, which was deprecated in 3.18.0 with a note that it would be removed in a future release. A configuration that still lists `mcp-bridge` under `plugins` has to drop the entry, and `openapi-to-mcp` is the MCP plugin going forward [#14019](https://github.com/apache/apisix/pull/14019) +- :warning: refactor(wolf-rbac): move `header_prefix` to the Route or Service configuration, where it defaults to `X-`, so a Route owns its identity headers and clears `{prefix}UserId`, `{prefix}Username` and `{prefix}Nickname` before any authenticator runs. Move a custom `header_prefix` from each Consumer to every Route or Service using `wolf-rbac` (including inside `multi-auth`) before upgrading, because a Consumer carrying a custom value is now rejected; a Consumer that only carries the old schema default `X-` keeps validating and has the field dropped for compatibility. `appid` (now required), `server` and `ssl_verify` stay on the Consumer [#13929](https://github.com/apache/apisix/pull/13929) +- :warning: fix(oas-validator): verify the TLS certificate of the `spec_url` host. `ssl_verify` now defaults to `true`, so an `https` spec served with a certificate outside the trust store fails the fetch and the route answers 500; set `ssl_verify: false` to keep the old behavior, which is now logged as an opt-out [#14146](https://github.com/apache/apisix/pull/14146) +- :warning: fix(authz-keycloak): require every requested permission to be granted. The plugin asks Keycloak for `response_mode=permissions` and checks each requested resource and scope against the granted list, so a route listing several permissions, a permission with several scopes, or `http_method_as_scope` on a scoped permission answers 403 unless all of them are granted. Each permission is also sent as `resource#scope1,scope2` with every scope trimmed, so a permission written as `res#view, delete` asks for `delete`, where the untrimmed `" delete"` used to be dropped by Keycloak and never enforced. A token endpoint response that is not a permissions list now returns 503 instead of being read as an allow [#14098](https://github.com/apache/apisix/pull/14098) +- :warning: feat(openid-connect): upgrade `lua-resty-openidc` to 1.9.3 and `lua-resty-session` to 4.2.0, so an introspection failure is reported for what it is: a confirmed inactive token returns 401, an endpoint, transport or response failure returns 503, and a configuration failure returns 500. An introspection response whose `active` claim is missing or is not a boolean is now rejected as an invalid upstream response instead of being read as truthy [#14088](https://github.com/apache/apisix/pull/14088) +- :warning: feat(prometheus): add `service` and `service_id` to all four stream metrics, so `apisix_stream_connection_total`, `apisix_stream_active_connections`, `apisix_stream_status` and `apisix_stream_bandwidth` gain two labels. Update PromQL selectors, recording rules, dashboards and alerts that match those series exactly; both labels are empty for a session that never reached a Stream Route with a Service, so aggregating both of them away, for example `sum without (service, service_id) (...)`, reproduces the previous values [#13992](https://github.com/apache/apisix/pull/13992) +- :warning: fix(cli): don't capture openresty stdout in `apisix start`. With `access_log: /dev/stdout`, `apisix start` used to block forever while swallowing the logs, and it now returns once openresty has daemonized. A container whose only command is `apisix start` therefore exits, and should run openresty in the foreground with `daemon off;`, the way the official image entrypoint does [#14087](https://github.com/apache/apisix/pull/14087) +- :warning: fix: return 421 for SNI and Host mismatches on mTLS requests, so an HTTP/2 client that reused a connection opened for another origin can retry on a new connection with the target origin's SNI and client certificate. The mismatch check also moves ahead of the client certificate verification result; other verification failures keep returning 400 [#14013](https://github.com/apache/apisix/pull/14013) +- :warning: fix(router): forward the path the route was matched on whenever nginx normalized the request path, so the upstream receives the path the router matched rather than the raw request line. Because that path is the decoded `$uri`, an encoded delimiter in a request nginx normalized is forwarded decoded: `/a/./b%2Fc` reaches the upstream as `/a/b/c`. A request that differs from `$uri` only by percent-encoding or repeated slashes still forwards the original request line, and a plugin that sets `$upstream_uri` still takes precedence [#14035](https://github.com/apache/apisix/pull/14035) +- :warning: fix(ssl): match `skip_mtls_uri_regex` against the encoded-slash route URI as well, so with `match_uri_encoded_slash: true` an exemption applies only when it matches both the decoded URI and the URI that keeps `%2F` inside a path segment. An exemption written for the decoded form alone stops applying to a path with an encoded slash; extend it to cover the encoded form to keep skipping the check [#14108](https://github.com/apache/apisix/pull/14108) +- :warning: fix(jwe-decrypt, forward-auth): clear the forwarded headers on the paths that skip writing them, so `jwe-decrypt`'s `forward_header` on a `strict: false` route without a token, and `forward-auth`'s `upstream_headers` while the auth service is unavailable with `allow_degradation: true`, reach the upstream unset, the way the normal paths already handle a header they have no value for [#14096](https://github.com/apache/apisix/pull/14096) +- :warning: fix(ai-prompt-guard): inspect embeddings string arrays. The strings of a batch input are joined and checked together, so `allow_patterns` applies to the combined text and a `deny_patterns` match rejects the batch. Token-ID arrays are left as they are, and a recognized request with no selected text keeps being processed [#14073](https://github.com/apache/apisix/pull/14073) +- :warning: fix(openapi-to-mcp): tighten what a tool call can put into the upstream request. Tool arguments are filtered to the parameters the operation declares, so an undeclared header or query key is dropped; the Route's own `headers` are applied last and take precedence; and a header name or value that cannot appear in a request header is dropped with a warning. A Route `headers` entry whose name carries `:` or whitespace, or whose value carries CR or LF, is now rejected by the schema, so a stored Route with such a header fails to load. New defaults also apply without any configuration change: `max_response_body_size` 1 MiB and `max_document_size` 4 MiB (a larger upstream response or document fails), `max_expanded_nodes` 50000 (past it a `$ref` degrades to a generic object), an http(s) `$ref` may only leave the origin of `openapi_url` when `allowed_ref_hosts` permits it, a request carrying `Origin` is validated against `allowed_origins`, and an SSE session is bound to the Route and Consumer that opened it [#13959](https://github.com/apache/apisix/pull/13959) Review Comment: One branch is missing from that accept rule. The loopback exception runs only when `literal_route_hosts` returns nothing: the Route has no `host`/`hosts`, or every host is a wildcard. If the Route has any literal host, a non-matching Origin is rejected there, including a loopback Origin (`origin_rejected` returns before the loopback check). So with `allowed_origins` unset: an Origin is accepted when it matches a literal Route host with the same scheme and effective port; only a Route with no literal host falls through to loopback-to-loopback (`localhost`, `127.0.0.1`, `::1`). A wildcard-only host does not count as literal. -- 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]
