Merge branch 'main' into patch-2

.mvn/extensions.xml

@@ -17,6 +17,6 @@
     <extension>
         <groupId>io.quarkus.develocity</groupId>
         <artifactId>quarkus-project-develocity-extension</artifactId>
-        <version>1.1.8</version>
+        <version>1.1.9</version>
     </extension>
 </extensions>

build-parent/pom.xml

@@ -39,7 +39,7 @@
         <subethasmtp.version>6.0.1</subethasmtp.version>
 
         <!-- Dev tools -->
-        <freemarker.version>2.3.33</freemarker.version>
+        <freemarker.version>2.3.34</freemarker.version>
         <commonmark.version>0.24.0</commonmark.version>
 
         <!-- Arquillian BOM -->

docs/src/main/asciidoc/deploying-to-openshift.adoc

@@ -417,7 +417,7 @@ You can provide the arguments that will be used by the Kubernetes Job via the pr
 
 Finally, the Kubernetes job will be launched every time that is installed in OpenShift. You can know more about how to run Kubernetes jobs in this https://kubernetes.io/docs/concepts/workloads/controllers/job/#running-an-example-job[link].
 
-You can configure the rest of the Kubernetes Job configuration using the properties under `quarkus.openshift.job.xxx` (see xref:deploying-to-openshift#quarkus-kubernetes_quarkus-openshift-job-parallelism[link]).
+You can configure the rest of the Kubernetes Job configuration using the properties under `quarkus.openshift.job.xxx` (see xref:deploying-to-openshift.adoc#quarkus-kubernetes_quarkus-openshift-job-parallelism[link]).
 
 ===== Generating CronJob resources
 

docs/src/main/asciidoc/extension-maturity-matrix.adoc

@@ -27,7 +27,7 @@ It's completely OK to publish a first version of an extension that doesn't handl
 Also note that this list only includes the technical features of your extension.
 You might also want to think about how you share your extension, and how it presents itself to the world.
 The link:https://hub.quarkiverse.io/checklistfornewprojects/[new extension checklist] on the Quarkiverse Hub has a useful list of ways extensions can participate in the ecosystem.
-It's also a good idea to spend some time on the metadata in the xref:extension-metadata#quarkus-extension-yaml[`quarkus-extension.yaml` file], which is used by Quarkus tooling.
+It's also a good idea to spend some time on the metadata in the xref:extension-metadata.adoc#quarkus-extension-yaml[`quarkus-extension.yaml` file], which is used by Quarkus tooling.
 
 Here are some pointers on how to achieve those capabilities.
 
@@ -66,7 +66,7 @@ The Writing Extensions guide has more guidance on xref:writing-extensions.adoc#h
 === CDI Beans
 
 Quarkus extensions should aim to xref:writing-extensions.adoc#expose-your-components-via-cdi[expose components via CDI], so that they can be consumed in a frictionless way by user applications.
-Having everything injectable as CDI beans also helps testing, especially xref:getting-started-testing#mock-support[mocking].
+Having everything injectable as CDI beans also helps testing, especially xref:getting-started-testing.adoc#mock-support[mocking].
 
 === Dev Service
 
@@ -95,7 +95,7 @@ A good starting point is usually to use
 Although providing new, joyful, ways to do things is good,
 it's important to not break the normal patterns that users may be familiar with.
 
-For some inspiration in this area, have a look at xref:logging#simplified-logging[simplified logging], xref:hibernate-orm-panache.adoc[simplified Hibernate ORM with Panache], the xref:rest-client.adoc#query-parameters[`@RestQuery` annotation], or the way Quarkus allows test containers to be used xref:getting-started-dev-services.adoc[without any configuration].
+For some inspiration in this area, have a look at xref:logging.adoc#simplified-logging[simplified logging], xref:hibernate-orm-panache.adoc[simplified Hibernate ORM with Panache], the xref:rest-client.adoc#query-parameters[`@RestQuery` annotation], or the way Quarkus allows test containers to be used xref:getting-started-dev-services.adoc[without any configuration].
 
 === Codestart application template
 
@@ -124,7 +124,7 @@ For a case study of how to eliminate reflection and what the performance benefit
 === Virtual thread support
 
 Not every library is suitable for using with virtual threads, out of the box.
-xref:virtual-threads#why-not["Why not virtual threads everywhere?"] explains why.
+xref:virtual-threads.adoc#why-not["Why not virtual threads everywhere?"] explains why.
 
 To get your library working properly with virtual threads, you should make sure the library is not pinning the carrier thread.
  Quarkus has xref:virtual-threads.adoc#testing-virtual-thread-applications[test helpers to do these checks in an automated way].
@@ -157,7 +157,7 @@ Avoid using errors and warnings for conditions that will not affect normal opera
 
 === Define health endpoints
 
-Extensions may wish to xref:writing-extensions#extension-defined-endpoints[define library-specific endpoints] for health criteria which are specific to that extension. To add a new endpoint, extensions should produce a `NonApplicationRootPathBuildItem`.
+Extensions may wish to xref:writing-extensions.adoc#extension-defined-endpoints[define library-specific endpoints] for health criteria which are specific to that extension. To add a new endpoint, extensions should produce a `NonApplicationRootPathBuildItem`.
 
 === Tracing context
 
@@ -175,4 +175,4 @@ Being Kubernetes-native implies being container-native. At a minimum, extensions
 
 - xref:writing-extensions.adoc[Writing your own extension] guide
 - xref:building-my-first-extension.adoc[Building your first extension]
-- link:https://hub.quarkiverse.io.adoc[The Quarkiverse Hub documentation]
+- link:https://hub.quarkiverse.io.adoc[The Quarkiverse Hub documentation]

docs/src/main/asciidoc/security-oidc-auth0-tutorial.adoc

@@ -928,7 +928,7 @@ Press `r` and notice this test failing with `403` which is expected because the
 
 image::auth0-test-failure-403.png[Auth0 test failure 403]
 
-Before fixing the test, let's review the options available for testing Quarkus endpoints secured by OIDC. These options might vary, depending on which flow your application supports and how you prefer to test. Endpoints which use OIDC authorization code flow can be tested using xref:security-oidc-code-flow-authentication#code-flow-integration-testing[one of these options] and endpoints which use Bearer token authentication can be tested using xref:security-oidc-bearer-token-authentication#bearer-token-integration-testing[one of these options].
+Before fixing the test, let's review the options available for testing Quarkus endpoints secured by OIDC. These options might vary, depending on which flow your application supports and how you prefer to test. Endpoints which use OIDC authorization code flow can be tested using xref:security-oidc-code-flow-authentication.adoc#code-flow-integration-testing[one of these options] and endpoints which use Bearer token authentication can be tested using xref:security-oidc-bearer-token-authentication.adoc#bearer-token-integration-testing[one of these options].
 
 As you can see, testing of the endpoints secured with Auth0 can be done with the help of `Wiremock`, or `@TestSecurity` annotation. Experiment with writing such tests on your own and reach out if you encounter any problems.
 
@@ -956,7 +956,7 @@ image::auth0-password-grant.png[Auth0 password grant]
 It is important to clarify that we do not recommend using the deprecated OAuth2 `password` token grant in production. However using it can help testing the endpoint with tokens acquired from the live dev Auth0 tenant.
 ====
 
-`OidcTestClient` should be used to test applications accepting bearer tokens which will work for the endpoint developed in this tutorial as it supports both authorization code flow and bearer token authentication. You would need to use OIDC WireMock or `HtmlUnit` directly against the Auth0 dev tenant if only the authorization code flow was supported - in the latter case `HtmlUnit` test code would have to be aligned with how Auth0 challenges users to enter their credentials. If you like, you can copy the xref:security-oidc-code-flow-authentication#code-flow-integration-testing-wiremock[HtmlUnit test fragment] from the documentation and experiment with it.
+`OidcTestClient` should be used to test applications accepting bearer tokens which will work for the endpoint developed in this tutorial as it supports both authorization code flow and bearer token authentication. You would need to use OIDC WireMock or `HtmlUnit` directly against the Auth0 dev tenant if only the authorization code flow was supported - in the latter case `HtmlUnit` test code would have to be aligned with how Auth0 challenges users to enter their credentials. If you like, you can copy the xref:security-oidc-code-flow-authentication.adoc#code-flow-integration-testing-wiremock[HtmlUnit test fragment] from the documentation and experiment with it.
 
 In meantime we will now proceed with fixing the currently failing test using `OidcTestClient`.
 

docs/src/main/asciidoc/security-oidc-bearer-token-authentication.adoc

@@ -1280,7 +1280,7 @@ quarkus.tls.oidc-server-mtls.trust-store.p12.password=password
 
 The above configuration is sufficient to require that OIDC bearer tokens are bound to the client certificates.
 
-Next, if you need to access both mTLS and OIDC bearer security identities, consider enabling xref:security-authentication-mechanisms#combining-authentication-mechanisms[Inclusive authentication] with `quarkus.http.auth.inclusive=true`.
+Next, if you need to access both mTLS and OIDC bearer security identities, consider enabling xref:security-authentication-mechanisms.adoc#combining-authentication-mechanisms[Inclusive authentication] with `quarkus.http.auth.inclusive=true`.
 
 Now you can access both MTLS and OIDC security identities as follows:
 
@@ -1419,7 +1419,7 @@ Authentication that requires a dynamic tenant will fail.
 == OIDC request filters
 
 You can filter OIDC requests made by Quarkus to the OIDC provider by registering one or more `OidcRequestFilter` implementations, which can update or add new request headers, and log requests.
-For more information, see xref:security-oidc-code-flow-authentication#code-flow-oidc-request-filters[OIDC request filters].
+For more information, see xref:security-oidc-code-flow-authentication.adoc#code-flow-oidc-request-filters[OIDC request filters].
 
 [[bearer-token-oidc-response-filters]]
 === OIDC response filters

docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc

@@ -300,7 +300,7 @@ quarkus.tls.oidc.trust-store.p12.password=${trust-store-password}
 
 ==== POST query
 
-Some providers, such as the xref:security-openid-connect-providers#strava[Strava OAuth2 provider], require client credentials be posted as HTTP POST query parameters:
+Some providers, such as the xref:security-openid-connect-providers.adoc#strava[Strava OAuth2 provider], require client credentials be posted as HTTP POST query parameters:
 
 [source,properties]
 ----
@@ -416,7 +416,7 @@ import io.quarkus.oidc.runtime.OidcUtils;
 @Unremovable
 @OidcEndpoint(value = Type.TOKEN) <1>
 public class TokenEndpointResponseFilter implements OidcResponseFilter {
-    
+
     @Override
     public void filter(OidcResponseContext rc) {
         String contentType = rc.responseHeaders().get("Content-Type"); <2>
@@ -1853,7 +1853,7 @@ To import a custom realm file into Keycloak before running the tests, configure
 quarkus.keycloak.devservices.realm-path=quarkus-realm.json
 ----
 
-Finally, write the test code as described in the <<code-flow-integration-testing-wiremock,Wiremock>> section.  
+Finally, write the test code as described in the <<code-flow-integration-testing-wiremock,Wiremock>> section.
 The only difference is that `@QuarkusTestResource` is no longer required:
 
 [source, java]

docs/src/main/asciidoc/security-openid-connect-client-registration.adoc

@@ -19,12 +19,12 @@ You can read more about it in the https://openid.net/specs/openid-connect-regist
 
 You can use Quarkus `quarkus-oidc-client-registration` extension to register one or more clients using OIDC client registration configurations and read, update and delete metadata of the registered clients.
 
-xref:security-openid-connect-multitenancy#tenant-config-resolver[OIDC TenantConfigResolver] can be used to create OIDC tenant configurations using the metadata of the registered clients.
+xref:security-openid-connect-multitenancy.adoc#tenant-config-resolver[OIDC TenantConfigResolver] can be used to create OIDC tenant configurations using the metadata of the registered clients.
 
 [IMPORTANT]
 ====
 Currently, Quarkus `quarkus-oidc-client-registration` extension has an `experimental` status.
-Dynamic client registration API provided by this extension may change while this extension has an experiemental status. 
+Dynamic client registration API provided by this extension may change while this extension has an experiemental status.
 ====
 
 == OIDC Client Registration
@@ -41,7 +41,7 @@ Add the following dependency:
 
 The `quarkus-oidc-client-registration` extension allows register one or more clients using OIDC client registration configurations, either on start-up or on demand, and read, update and delete metadata of the registered clients.
 
-You can register and manage client registrations from the custom xref:security-openid-connect-multitenancy#tenant-config-resolver[OIDC TenantConfigResolver].
+You can register and manage client registrations from the custom xref:security-openid-connect-multitenancy.adoc#tenant-config-resolver[OIDC TenantConfigResolver].
 
 Alternatively, you can register clients without even using OIDC. For example, it can be a command line tool which registers clients and passes metadata of the registered clients to Quarkus services which require them.
 
@@ -61,7 +61,7 @@ quarkus.oidc-client-registration.auth-server-url=${quarkus.oidc.auth-server-url}
 quarkus.oidc-client-registration.metadata.client-name=Default Client
 quarkus.oidc-client-registration.metadata.redirect-uri=http://localhost:8081/protected
 
-# Named OIDC client registration which configures a registration endpoint path: 
+# Named OIDC client registration which configures a registration endpoint path:
 # It require an initial registration token for a client registration to succeed.
 
 quarkus.oidc-client-registration.tenant-client.registration-path=${quarkus.oidc.auth-server-url}/clients-registrations/openid-connect
@@ -72,7 +72,7 @@ quarkus.oidc-client-registration.initial-token=${initial-registration-token}
 
 The above configuration will lead to two new client registrations created in your OIDC provider.
 
-You or may not need to acquire an initial registration access token. If you don't, then you will have to enable one or more client registration policies in your OIDC provider's dashboard. For example, see https://www.keycloak.org/docs/latest/securing_apps/#_client_registration_policies[Keycloak client registration policies].   
+You or may not need to acquire an initial registration access token. If you don't, then you will have to enable one or more client registration policies in your OIDC provider's dashboard. For example, see https://www.keycloak.org/docs/latest/securing_apps/#_client_registration_policies[Keycloak client registration policies].
 
 The next step is to inject either `quarkus.oidc.client.registration.OidcClientRegistration` if only a single default client registration is done, or `quarkus.oidc.client.registration.OidcClientRegistrations` if more than one registration is configured, and use metadata of the clients registered with these configurations.
 
@@ -114,7 +114,7 @@ public class CustomTenantConfigResolver implements TenantConfigResolver {
     @Override
     public Uni<OidcTenantConfig> resolve(RoutingContext routingContext,
             OidcRequestContext<OidcTenantConfig> requestContext) {
-            
+
         if (routingContext.request().path().endsWith("/protected")) {
             // Use the registered client created from the default OIDC client registration
             return clientReg.registeredClient().onItem().transform(client -> createTenantConfig("registered-client", client));
@@ -148,7 +148,7 @@ public class CustomTenantConfigResolver implements TenantConfigResolver {
 [[register-clients-on-demand]]
 === Register clients on demand
 
-You can register new clients on demand. 
+You can register new clients on demand.
 You can add new clients to the existing, already configured `OidcClientConfiguration` or to a newly created `OidcClientConfiguration`.
 
 Start from configuring one or more OIDC client registrations:
@@ -201,7 +201,7 @@ public class CustomTenantConfigResolver implements TenantConfigResolver {
             ClientMetadata metadata = createMetadata("http://localhost:8081/protected/dynamic-tenant",
                     "Dynamic Tenant Client");
 
-            return clientReg.registerClient(metadata).onItem().transform(r -> 
+            return clientReg.registerClient(metadata).onItem().transform(r ->
                   createTenantConfig("registered-client-dynamically", r));
         }
         return null;
@@ -280,7 +280,7 @@ public class CustomTenantConfigResolver implements TenantConfigResolver {
                     .build();
 
             return clientRegs.newClientRegistration(clientRegConfig)
-                    .onItem().transform(reg -> 
+                    .onItem().transform(reg ->
                     createTenantConfig("registered-client-dynamically", reg.registeredClient());
         }
 

docs/src/main/asciidoc/security-openid-connect-providers.adoc

@@ -771,7 +771,7 @@ It may not be a problem when Quarkus fetches public verification keys from OIDC-
 
 Therefore, UserInfo is embedded in an internally generated ID token and is encrypted in the session cookie. You can disable it with `quarkus.oidc.cache-user-info-in-idtoken=false`.
 
-Alternatively, use a default or custom UserInfo cache provider, please see the xref:security-oidc-bearer-token-authentication#bearer-token-token-introspection-userinfo-cache[Token Introspection and UserInfo cache] section of the "OpenID Connect (OIDC) Bearer token authentication" guide.
+Alternatively, use a default or custom UserInfo cache provider, please see the xref:security-oidc-bearer-token-authentication.adoc#bearer-token-token-introspection-userinfo-cache[Token Introspection and UserInfo cache] section of the "OpenID Connect (OIDC) Bearer token authentication" guide.
 
 == References
 

docs/src/main/asciidoc/web.adoc

@@ -21,7 +21,7 @@ Quarkus provides several extensions to create web applications, this document ai
 
 Let's assume you have a Quarkus backend, and you want to serve static files. This is the most basic case, it is supported out of the box with all our Vert.x based extensions, you must place them in the `META-INF/resources` directory of your application.
 
-You can find more information in the xref:http-reference#serving-static-resources[HTTP reference guide].
+You can find more information in the xref:http-reference.adoc#serving-static-resources[HTTP reference guide].
 
 === Serving scripts, styles, and web libraries
 
@@ -266,4 +266,4 @@ You could also split it in two services: one for the backend and one for the fro
 
 If your application involves a substantial number of static resources, consider using a CDN. Both the Web Bundler and Quinoa can be configured to work seamlessly with a CDN, providing improved performance and distribution of assets.
 
-// It would be nice to have a blog article and benchmark about this topic.
+// It would be nice to have a blog article and benchmark about this topic.

extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/ProxyConfig.java

@@ -35,7 +35,7 @@ public class ProxyConfig {
      * the precedence.
      * Activating this together with {@code quarkus.http.proxy.allow-x-forwarded} has security implications as clients can forge
      * requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected
-     * `X-Forwarded` or `X-Forwarded-*` headers from the client.
+     * `Forwarded` or `X-Forwarded-*` headers from the client.
      */
     @ConfigItem
     public boolean allowForwarded;
@@ -47,7 +47,7 @@ public class ProxyConfig {
      * precedence.
      * Activating this together with {@code quarkus.http.proxy.allow-forwarded} has security implications as clients can forge
      * requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected
-     * `X-Forwarded` or `X-Forwarded-*` headers from the client.
+     * `Forwarded` or `X-Forwarded-*` headers from the client.
      */
     @ConfigItem
     public Optional<Boolean> allowXForwarded;