Merge branch 'main' into replace-jdbc-pgsql-never-inline

bom/application/pom.xml

@@ -163,7 +163,7 @@
         <osgi.version>6.0.0</osgi.version>
         <mongo-client.version>4.7.1</mongo-client.version>
         <mongo-crypt.version>1.5.2</mongo-crypt.version>
-        <proton-j.version>0.33.10</proton-j.version>
+        <proton-j.version>0.34.0</proton-j.version>
         <javaparser.version>3.24.2</javaparser.version>
         <okhttp.version>3.14.9</okhttp.version><!-- keep in sync with okio -->
         <okio.version>1.17.2</okio.version><!-- keep in sync with okhttp -->
@@ -201,7 +201,7 @@
         <aesh.version>2.6</aesh.version>
         <!-- these two artifacts needs to be compatible together -->
         <strimzi-oauth.version>0.10.0</strimzi-oauth.version>
-        <strimzi-oauth.nimbus.version>9.24.4</strimzi-oauth.nimbus.version>
+        <strimzi-oauth.nimbus.version>9.25</strimzi-oauth.nimbus.version>
         <java-buildpack-client.version>0.0.6</java-buildpack-client.version>
         <org-crac.version>0.1.1</org-crac.version>
     </properties>

core/runtime/src/main/java/io/quarkus/runtime/logging/LoggingSetupRecorder.java

@@ -55,7 +55,6 @@
 public class LoggingSetupRecorder {
 
     private static final org.jboss.logging.Logger log = org.jboss.logging.Logger.getLogger(LoggingSetupRecorder.class);
-    public static final String SHUTDOWN_MESSAGE = " [Error Occurred After Shutdown]";
 
     final RuntimeValue<ConsoleRuntimeConfig> consoleRuntimeConfig;
 

docs/src/main/asciidoc/mailer-reference.adoc

@@ -368,6 +368,8 @@ quarkus.mailer.port=587
 quarkus.mailer.start-tls=REQUIRED
 [email protected]
 quarkus.mailer.password=YOURGENERATEDAPPLICATIONPASSWORD
+
+quarkus.mailer.mock=false # In dev mode, prevent from using the mock SMTP server
 ----
 
 Or with SSL:
@@ -381,6 +383,8 @@ quarkus.mailer.port=465
 quarkus.mailer.ssl=true
 [email protected]
 quarkus.mailer.password=YOURGENERATEDAPPLICATIONPASSWORD
+
+quarkus.mailer.mock=false # In dev mode, prevent from using the mock SMTP server
 ----
 
 [NOTE]

docs/src/main/asciidoc/mailer.adoc

@@ -181,32 +181,10 @@ In the `src/main/resources/application.properties` file, you need to configure t
 Note that the password can also be configured using system properties and environment variables.
 See the xref:config-reference.adoc[configuration reference guide] for details.
 
-Here is an example using _sendgrid_:
-
-[source,properties]
-----
-# Your email address you send from - must match the "from" address from sendgrid.
-[email protected]
-
-# The SMTP host
-quarkus.mailer.host=smtp.sendgrid.net
-# The SMTP port
-quarkus.mailer.port=465
-# If the SMTP connection requires SSL/TLS
-quarkus.mailer.ssl=true
-# Your username
-quarkus.mailer.username=....
-# Your password
-quarkus.mailer.password=....
-
-# By default, in dev mode, the mailer is a mock. This disables the mock and use the configured mailer.
-quarkus.mailer.mock=false
-----
+Configuration of popular mail services is covered in xref:mailer-reference.adoc#popular[the reference guide].
 
 Once you have configured the mailer, if you call the HTTP endpoint as shown above, you will send emails.
 
-Other popular mail services are covered in xref:mailer-reference.adoc#popular[the reference guide].
-
 == Conclusion
 
 This guide has shown how to send emails from your Quarkus application.

docs/src/main/asciidoc/security-customization.adoc

@@ -84,6 +84,8 @@ In some cases such a default logic of selecting the challenge is exactly what is
 
 [source,java]
 ----
+@Alternative <1>
+@Priority(1)
 @ApplicationScoped
 public class CustomAwareJWTAuthMechanism implements HttpAuthenticationMechanism {
 
@@ -102,18 +104,21 @@ public class CustomAwareJWTAuthMechanism implements HttpAuthenticationMechanism
 
 	@Override
 	public Uni<ChallengeData> getChallenge(RoutingContext context) {
-		return selectBetweenJwtAndOidcChallenge(context).getChallenge(context);
+            return selectBetweenJwtAndOidcChallenge(context).getChallenge(context);
 	}
 
 	@Override
 	public Set<Class<? extends AuthenticationRequest>> getCredentialTypes() {
-		return selectBetweenJwtAndOidc(context).getCredentialTypes();
+            Set<Class<? extends AuthenticationRequest>> credentialTypes = new HashSet<>();
+            credentialTypes.addAll(jwt.getCredentialTypes());
+            credentialTypes.addAll(oidc.getCredentialTypes());
+            return credentialTypes;
 	}
 
-	@Override
-	public HttpCredentialTransport getCredentialTransport(RoutingContext context) {
-		return selectBetweenJwtAndOidc(context).getCredentialTransport();
-	}
+        @Override
+        public Uni<HttpCredentialTransport> getCredentialTransport(RoutingContext context) {
+            return selectBetweenJwtAndOidc(context).getCredentialTransport(context);
+        }
 
         private HttpAuthenticationMechanism selectBetweenJwtAndOidc(RoutingContext context) {
             ....
@@ -125,6 +130,7 @@ public class CustomAwareJWTAuthMechanism implements HttpAuthenticationMechanism
 
 }
 ----
+<1> Declaring the mechanism an alternative bean ensures this mechanism is used rather than `OidcAuthenticationMechanism` and `JWTAuthMechanism`.
 
 [[security-identity-customization]]
 == Security Identity Customization

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

@@ -8,15 +8,37 @@ https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 include::./attributes.adoc[]
 :toc:
 
-This guide demonstrates how to use Quarkus OpenID Connect (OIDC) Extension to protect your JAX-RS applications using Bearer Token Authorization where Bearer Tokens are issued by OpenID Connect and OAuth 2.0 compliant Authorization Servers such as https://www.keycloak.org[Keycloak].
+You can use the Quarkus OpenID Connect (OIDC) extension to secure your JAX-RS applications using Bearer Token Authorization. 
+The Bearer Tokens are issued by OIDC and OAuth 2.0 compliant authorization servers, such as https://www.keycloak.org[Keycloak]. 
 
-Bearer Token Authorization is the process of authorizing HTTP requests based on the existence and validity of a Bearer Token which provides valuable information to determine the subject of the call as well as whether an HTTP resource can be accessed.
+Bearer Token Authorization is the process of authorizing HTTP requests based on the existence and validity of a Bearer Token. 
+The Bearer Token provides information about the subject of the call which is used to determine whether or not an HTTP resource can be accessed.
 
-Please read the xref:security-openid-connect-web-authentication.adoc[Using OpenID Connect to Protect Web Applications] guide if you need to authenticate and authorize the users using OpenID Connect Authorization Code Flow.
+The following diagrams outline the Bearer Token Authorization mechanism in Quarkus:
 
-If you use Keycloak and Bearer tokens then also see the xref:security-keycloak-authorization.adoc[Using Keycloak to Centralize Authorization] guide.
+.Bearer Token Authorization mechanism in Quarkus with Single-page application
+image::security-bearer-token-authorization-mechanism-1.png[alt=Bearer Token Authorization, width="60%", align=center]
+
+1. The Quarkus service retrieves verification keys from the OpenID Connect provider. The verification keys are used to verify the bearer access token signatures.
+2. The Quarkus user accesses the Single-page application.
+3. The Single-page application uses Authorization Code Flow to authenticate the user and retrieve tokens from the OpenID Connect provider.
+4. The Single-page application uses the access token to retrieve the service data from the Quarkus service.
+5. The Quarkus service verifies the bearer access token signature using the verification keys, checks the token expiry date and other claims, allows the request to proceed if the token is valid, and returns the service response to the Single-page application.
+6. The Single-page application returns the same data to the Quarkus user.
+
+.Bearer Token Authorization mechanism in Quarkus with Java or command line client
+image::security-bearer-token-authorization-mechanism-2.png[alt=Bearer Token Authorization, width="60%", align=center]
+
+1. The Quarkus service retrieves verification keys from the OpenID Connect provider. The verification keys are used to verify the bearer access token signatures.
+2. The Client uses `client_credentials` that requires client ID and secret or password grant, which also requires client ID, secret, user name, and password to retrieve the access token from the OpenID Connect provider.
+3. The Client uses the access token to retrieve the service data from the Quarkus service.
+4. The Quarkus service verifies the bearer access token signature using the verification keys, checks the token expiry date and other claims, allows the request to proceed if the token is valid, and returns the service response to the Client.
+
+If you need to authenticate and authorize the users using OpenID Connect Authorization Code Flow, see xref:security-openid-connect-web-authentication.adoc[Using OpenID Connect to Protect Web Applications].
+Also, if you use Keycloak and Bearer Tokens, see xref:security-keycloak-authorization.adoc[Using Keycloak to Centralize Authorization].
+
+For information about how to support multiple tenants, see xref:security-openid-connect-multitenancy.adoc[Using OpenID Connect Multi-Tenancy].
 
-Please read the xref:security-openid-connect-multitenancy.adoc[Using OpenID Connect Multi-Tenancy] guide how to support multiple tenants.
 
 == Quickstart