Release v2.11.0

Summary

An application surface served without a session is now reachable through AuthProxy, and a refusal is no longer delivered as a success. Upgrading changes response codes for unauthenticated non-browser callers, and breaks HTTP health probes pointed at / — see the first two entries under Changed before deploying.

Added

• AnonymousPaths on a service declares path prefixes served to unauthenticated callers, which is what makes a health endpoint or a public page reachable now that the provider-selection page is no longer served to everyone. Prefixes match on whole segments, and an entry that cannot be expressed as plain literal segments is discarded rather than matched, so a declaration can never mean one thing to the middleware and another to the router
• WithAnonymousPaths Aspire builder for declaring those paths from the app host, so the declaration lives with the service definition instead of in separate configuration
• Documentation for anonymous paths, and a page describing how AuthProxy answers unauthenticated callers

Changed

• HTTP liveness and readiness probes pointed at AuthProxy on / now receive 401 and must be repointed at a declared anonymous path or switched to a TCP socket probe. A Kubernetes httpGet probe on / previously got 200 because the provider-selection page was served to anyone; it now fails, and a failing liveness probe restarts the pod, so this needs changing as part of the upgrade rather than after it
• Unauthenticated callers that are not browsers navigating to a page are refused with 401 instead of receiving the provider-selection page at 200, and tenant selection refuses them with 403 instead of serving the tenant chooser at 200. A page has to carry a success status to render, which meant every non-browser caller was told its request succeeded: a webhook sender recorded delivery and never retried, and a frontend's fetch() passed the conventional response.ok check and failed later on parsing, far from the cause
• A wildcard Accept: */* no longer counts as asking for HTML, so fetch(), curl and webhook senders receive a status they can act on. */* is what a client sends when it will take whatever it is given, and reading it as a request for a page is what turned a refusal into a recorded success; Sec-Fetch-Dest decides when present, since it is the only signal separating a document navigation from a scripted request issued by the same browser. A caller sending text/html;q=0 is likewise taken at its word
• The refusal carries a WWW-Authenticate: Bearer challenge when a bearer token is accepted, so a caller is told which credential would work rather than having to infer it from a bare 401
• Requests are still forwarded unchanged when no identity providers are configured, so a deployment that has not opted into authentication is unaffected by any of the above

Fixed

• select-provider.html is now shipped. It was documented as a default page but absent from the package, so a multi-provider deployment without a custom PagesPath rendered a bare "Error 200" heading where the sign-in chooser should have been
• The sign-in chooser returns the user to the page they requested rather than the site root, so a deep link survives signing in