Sync web site with Quarkus documentation

Author: quarkusbot

_guides/_attributes.adoc

@@ -1,7 +1,7 @@
 // Common attributes.
 // --> No blank lines (it ends the document header)
 :project-name: Quarkus
-:quarkus-version: 3.17.7
+:quarkus-version: 3.17.8
 :quarkus-platform-groupid: io.quarkus.platform
 // .
 :maven-version: 3.9.9

_guides/cdi-reference.adoc

@@ -333,6 +333,7 @@ public class EagerAppBean {
 
 NOTE: Quarkus users are encouraged to always prefer the `@Observes StartupEvent` to `@Initialized(ApplicationScoped.class)` as explained in the xref:lifecycle.adoc[Application Initialization and Termination] guide.
 
+[[request-context-lifecycle]]
 === Request Context Lifecycle
 
 The request context is also active:

_guides/kotlin.adoc

@@ -221,8 +221,8 @@ group = '...' // set your group
 version = '1.0.0-SNAPSHOT'
 
 java {
-    sourceCompatibility = JavaVersion.VERSION_11
-    targetCompatibility = JavaVersion.VERSION_11
+    sourceCompatibility = JavaVersion.VERSION_21
+    targetCompatibility = JavaVersion.VERSION_21
 }
 
 allOpen { // <2>
@@ -233,12 +233,12 @@ allOpen { // <2>
 }
 
 compileKotlin {
-    kotlinOptions.jvmTarget = JavaVersion.VERSION_11
+    kotlinOptions.jvmTarget = JavaVersion.VERSION_21
     kotlinOptions.javaParameters = true
 }
 
 compileTestKotlin {
-    kotlinOptions.jvmTarget = JavaVersion.VERSION_11
+    kotlinOptions.jvmTarget = JavaVersion.VERSION_21
 }
 ----
 
@@ -290,8 +290,8 @@ group = '...' // set your group
 version = "1.0.0-SNAPSHOT"
 
 java {
-    sourceCompatibility = JavaVersion.VERSION_11
-    targetCompatibility = JavaVersion.VERSION_11
+    sourceCompatibility = JavaVersion.VERSION_21
+    targetCompatibility = JavaVersion.VERSION_21
 }
 
 allOpen { // <2>

_guides/security-authorize-web-endpoints-reference.adoc

@@ -123,9 +123,9 @@ public class CustomNamedHttpSecPolicy implements HttpSecurityPolicy {
     public Uni<CheckResult> checkPermission(RoutingContext event, Uni<SecurityIdentity> identity,
             AuthorizationRequestContext requestContext) {
         if (customRequestAuthorization(event)) {
-            return Uni.createFrom().item(CheckResult.PERMIT);
+            return CheckResult.permit();
         }
-        return Uni.createFrom().item(CheckResult.DENY);
+        return CheckResult.deny();
     }
 
     @Override
@@ -182,6 +182,17 @@ You can also create global `HttpSecurityPolicy` invoked on every request.
 Just do not implement the `io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy.name` method and leave the policy nameless.
 ====
 
+[[policy-active-cdi-request-context]]
+=== Inject `@RequestScoped` beans into `HttpSecurityPolicy`
+
+`@RequestScoped` beans can only be injected when the xref:cdi-reference.adoc#request-context-lifecycle[CDI request context] is active.
+The context can be activated by users, for example with the `@ActivateRequestContext`, however authorization happens before Quarkus prepares some `@RequestScoped` beans.
+We recommend to let Quarkus activate and prepare CDI request context for you.
+For example, consider a situation where you want to inject a bean from the Jakarta REST context, such as the `jakarta.ws.rs.core.UriInfo` bean.
+In this case, you must apply the `HttpSecurityPolicy` to Jakarta REST endpoints. This can be achieved in one of the following ways:
+* Use the `@AuthorizationPolicy` security annotation.
+* Set the `quarkus.http.auth.permission.custom1.applies-to=jaxrs` configuration property.
+
 === Matching on paths and methods
 
 Permission sets can also specify paths and methods as a comma-separated list.
@@ -494,7 +505,7 @@ s| `@PermitAll` | Specifies that all security roles are allowed to invoke the sp
 s| `@RolesAllowed` | Specifies the list of security roles allowed to access methods in an application.
 s| `@Authenticated` | {project-name} provides the `io.quarkus.security.Authenticated` annotation that permits any authenticated user to access the resource. It's equivalent to `@RolesAllowed("**")`.
 s| `@PermissionsAllowed` | Specifies the list of permissions that are allowed to invoke the specified methods.
-s| `@AuthorizationPolicy` | Specifies named `io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy` that should authorize access to the specified endpoints.HttpSecurityPolicy.
+s| `@AuthorizationPolicy` | Specifies named `io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy` that should authorize access to the specified Jakarta REST endpoints.
 Named HttpSecurityPolicy can be used for general authorization checks as demonstrated by <<authorization-policy-example>>.
 |===
 

_guides/security-customization.adoc

@@ -242,6 +242,8 @@ You can enforce the order by implementing a default `SecurityIdentityAugmentor#p
 By default, the request context is not activated when augmenting the security identity, this means that if you want to use for example Hibernate
 that mandates a request context, you will have a `jakarta.enterprise.context.ContextNotActiveException`.
 
+IMPORTANT: Please also review the xref:security-proactive-authentication.adoc#cdi-request-context-activation[Activating the CDI request context] section of the "Proactive authentication" guide.
+
 The solution is to activate the request context, the following example shows how to get the roles from an Hibernate with Panache `UserRoleEntity`.
 
 [source,java]

_guides/security-getting-started-tutorial.adoc

@@ -324,13 +324,16 @@ For example:
 ----
 quarkus.http.auth.basic=true
 
-quarkus.datasource.db-kind=postgresql
-quarkus.datasource.username=quarkus
-quarkus.datasource.password=quarkus
-quarkus.datasource.jdbc.url=jdbc:postgresql:security_jpa
+%prod.quarkus.datasource.db-kind=postgresql
+%prod.quarkus.datasource.username=quarkus
+%prod.quarkus.datasource.password=quarkus
+%prod.quarkus.datasource.jdbc.url=jdbc:postgresql:security_jpa
 
 quarkus.hibernate-orm.database.generation=drop-and-create
 ----
+
+By adding the `%prod.` profile prefix, you ensure that the data source properties are only observed by an application running in production mode.
+
 ====
 +
 . To initialize the database with users and roles, implement the `Startup` class, as outlined in the following code snippet:
@@ -384,7 +387,7 @@ In a production environment, do not store plain text passwords.
 As a result, the `quarkus-security-jpa` defaults to using bcrypt-hashed passwords.
 ====
 
-== Test your application by using Dev Services for PostgreSQL
+== Test your application in dev mode by using Dev Services for PostgreSQL
 
 Complete the integration testing of your application in JVM and native modes by using xref:dev-services.adoc#databases[Dev Services for PostgreSQL] before you run your application in production mode.
 
@@ -411,21 +414,8 @@ To run your application in dev mode:
 include::{includes}/devtools/dev.adoc[]
 
 
-The following properties configuration demonstrates how to enable PostgreSQL testing to run only in production (`prod`) mode.
 In this scenario, `Dev Services for PostgreSQL` launches and configures a `PostgreSQL` test container.
 
-[source,properties]
-----
-%prod.quarkus.datasource.db-kind=postgresql
-%prod.quarkus.datasource.username=quarkus
-%prod.quarkus.datasource.password=quarkus
-%prod.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus
-
-quarkus.hibernate-orm.database.generation=drop-and-create
-----
-
-If you add the `%prod.` profile prefix, data source properties are not visible to `Dev Services for PostgreSQL` and are only observed by an application running in production mode.
-
 To write the integration test, use the following code sample:
 
 [source,java]
@@ -503,7 +493,7 @@ While developing your application, you can add and run tests individually by usi
 Dev Services for PostgreSQL supports testing while you develop by providing a separate PostgreSQL test container that does not conflict with the dev mode container.
 ====
 
-== Test your application using Curl or browser
+== Test your application in production mode by using Curl or browser
 
 To test your application using Curl or the browser, you must first start a PostgreSQL server, then compile and run your application either in JVM or native mode.
 
@@ -513,7 +503,7 @@ To test your application using Curl or the browser, you must first start a Postg
 ----
 docker run --rm=true --name security-getting-started -e POSTGRES_USER=quarkus \
            -e POSTGRES_PASSWORD=quarkus -e POSTGRES_DB=quarkus \
-           -p 5432:5432 postgres:14.1
+           -p 5432:5432 postgres:17
 ----
 
 === Compile and run the application
@@ -576,11 +566,7 @@ public
 $ curl -i -X GET http://localhost:8080/api/admin
 
 HTTP/1.1 401 Unauthorized
-Content-Length: 14
-Content-Type: text/html;charset=UTF-8
 WWW-Authenticate: Basic
-
-Not authorized
 ----
 ====
 * Connect to a protected endpoint as an authorized user:
@@ -616,10 +602,6 @@ If a resource is protected with `@RolesAllowed("user")`, the user `admin` is not
 $ curl -i -X GET -u admin:admin http://localhost:8080/api/users/me
 
 HTTP/1.1 403 Forbidden
-Content-Length: 34
-Content-Type: text/html;charset=UTF-8
-
-Forbidden
 ----
 
 Finally, the user named `user` is authorized, and the security context contains the principal details, for example, the username.

_guides/security-openid-connect-client-registration.adoc

@@ -9,6 +9,9 @@ include::_attributes.adoc[]
 :categories: security
 :topics: security,oidc,client
 :extensions: io.quarkus:quarkus-oidc-client-registration
+:extension-status: experimental
+
+include::{includes}/extension-status.adoc[]
 
 Typically, you have to register an OIDC client (application) manually in your OIDC provider's dashboard.
 During this process, you specify the human readable application name, allowed redirect and post logout URLs, and other properties.

_guides/security-proactive-authentication.adoc

@@ -18,6 +18,7 @@ Gain practical insights and strategies for various application scenarios.
 Proactive authentication is enabled in Quarkus by default.
 It ensures that all incoming requests with credentials are authenticated, even if the target page does not require authentication.
 As a result, requests with invalid credentials are rejected, even if the target page is public.
+Requests without credentials are not rejected, because anonymous requests are allowed.
 
 You can turn off this default behavior if you want to authenticate only when the target page requires it.
 To turn off proactive authentication so that authentication occurs only when the target page requires it, modify the `application.properties` configuration file as follows:
@@ -30,7 +31,7 @@ quarkus.http.auth.proactive=false
 If you turn off proactive authentication, the authentication process runs only when an identity is requested.
 An identity can be requested because of security rules that require the user to authenticate or because programmatic access to the current identity is required.
 
-If proactive authentication is used, accessing `SecurityIdentity` is a blocking operation.
+If proactive authentication is not used, accessing `SecurityIdentity` is a blocking operation.
 This is because authentication might have yet to happen, and accessing `SecurityIdentity` might require calls to external systems, such as databases, that might block the operation.
 For blocking applications, this is not an issue.
 However, if you have disabled authentication in a reactive application, this fails because you cannot do blocking operations on the I/O thread.
@@ -96,6 +97,19 @@ public class HelloService {
 }
 ----
 
+[[cdi-request-context-activation]]
+== Activating the CDI request context
+
+You may need to inject `@RequestScoped` beans during authentication and authorization.
+A good example of this is accessing a database during a `SecurityIdentity` augmentation,
+which is described in the xref:security-customization.adoc#security-identity-customization[Security Identity Customization] section of the "Security Tips and Tricks" guide.
+If authentication or authorization fails with the `jakarta.enterprise.context.ContextNotActiveException`, disabling proactive authentication is most often the best solution.
+Users can also activate xref:cdi-reference.adoc#request-context-lifecycle[CDI request context], for example, by using the `@ActivateRequestContext` annotation.
+However, some CDI beans may not be ready for use.
+
+One exception to this solution is a situation when application endpoints are secured with the xref:security-authorize-web-endpoints-reference.adoc#authorization-using-configuration[Authorization using configuration].
+For more information, see the xref:security-authorize-web-endpoints-reference.adoc#policy-active-cdi-request-context[Inject RequestScoped beans into HttpSecurityPolicy] section of the "Authorization of Web endpoints" guide for more information.
+
 [[customize-auth-exception-responses]]
 == Customize authentication exception responses