diff --git a/docs/src/main/asciidoc/building-native-image.adoc b/docs/src/main/asciidoc/building-native-image.adoc index f5b9efd84e2bd..37c83b2ef2dfd 100644 --- a/docs/src/main/asciidoc/building-native-image.adoc +++ b/docs/src/main/asciidoc/building-native-image.adoc @@ -472,7 +472,7 @@ If one of those extensions is present, then creating a container image for the n ==== If you're running a remote Docker daemon, you need to replace `quarkus.native.container-build=true` with `quarkus.native.remote-container-build=true`. -See <> for more details. +See <> for more details. ==== * `quarkus.container-image.build=true` instructs Quarkus to create a container-image using the final application artifact (which is the native executable in this case) diff --git a/docs/src/main/asciidoc/config-reference.adoc b/docs/src/main/asciidoc/config-reference.adoc index 41664ad7df60f..5b78ff8f33194 100644 --- a/docs/src/main/asciidoc/config-reference.adoc +++ b/docs/src/main/asciidoc/config-reference.adoc @@ -553,7 +553,7 @@ It generates the UUID at startup time. So, the value changes between startups, including reloads in dev mode. You can access the generated value using the `quarkus.uuid` property. -Use <> to access it: `${quarkus.uuid}`. +Use <> to access it: `${quarkus.uuid}`. For example, it can be useful to configure a Kafka client with a unique consumer group: [source, properties] diff --git a/docs/src/main/asciidoc/dev-mode-differences.adoc b/docs/src/main/asciidoc/dev-mode-differences.adoc index 0cea038c00db0..158ff0de45947 100644 --- a/docs/src/main/asciidoc/dev-mode-differences.adoc +++ b/docs/src/main/asciidoc/dev-mode-differences.adoc @@ -31,7 +31,7 @@ In keeping with the mantra of providing developer joy, Quarkus provides a host o === Live reload -This mightily important feature needs no introduction and has already been mentioned in the <> section. +This mightily important feature needs no introduction and has already been mentioned in the <> section. === Dev UI diff --git a/docs/src/main/asciidoc/hibernate-search-orm-elasticsearch.adoc b/docs/src/main/asciidoc/hibernate-search-orm-elasticsearch.adoc index 0770d96f26937..f3b4733707374 100644 --- a/docs/src/main/asciidoc/hibernate-search-orm-elasticsearch.adoc +++ b/docs/src/main/asciidoc/hibernate-search-orm-elasticsearch.adoc @@ -612,7 +612,7 @@ See also link:#quarkus-hibernate-search-orm-elasticsearch_quarkus.hibernate-sear [TIP] -For more information about the Hibernate Search extension configuration please refer to the <>. +For more information about the Hibernate Search extension configuration please refer to the <>. [[dev-services]] === Dev Services (Configuration Free Databases) diff --git a/docs/src/main/asciidoc/jms.adoc b/docs/src/main/asciidoc/jms.adoc index 4d1b4e500f04c..b846b5278feb6 100644 --- a/docs/src/main/asciidoc/jms.adoc +++ b/docs/src/main/asciidoc/jms.adoc @@ -30,7 +30,7 @@ The data can be fetched from a browser using a fetch button from a Jakarta REST The guide can be used either via the Apache Qpid JMS AMQP client as detailed immediately below, or alternatively with the Apache ActiveMQ Artemis JMS client given some different configuration -as <>. +as <>. [#qpid-jms-amqp] == Qpid JMS - AMQP @@ -330,7 +330,7 @@ Open `http://localhost:8080/prices.html` in your browser. The above steps detailed using the Qpid JMS AMQP client, however the guide can also be used with the Artemis JMS client. Many of the individual steps are exactly as previously -<>. The individual component code is the same. +<>. The individual component code is the same. The only differences are in the dependency for the initial project creation, and the configuration properties used. These changes are detailed below and should be substituted for the equivalent step during the sequence above. diff --git a/docs/src/main/asciidoc/kafka.adoc b/docs/src/main/asciidoc/kafka.adoc index 999588c70b8ca..2403dd67d5828 100644 --- a/docs/src/main/asciidoc/kafka.adoc +++ b/docs/src/main/asciidoc/kafka.adoc @@ -714,7 +714,7 @@ The `checkpoint` commit strategy is an experimental feature and can change in th Smallrye Reactive Messaging `checkpoint` commit strategy allows consumer applications to process messages in a stateful manner, while also respecting Kafka consumer scalability. An incoming channel with `checkpoint` commit strategy persists consumer offsets on an external -<>, such as a relational database or a key-value store. +<>, such as a relational database or a key-value store. As a result of processing consumed records, the consumer application can accumulate an internal state for each topic-partition assigned to the Kafka consumer. This local state will be periodically persisted to the state store and will be associated with the offset of the record that produced it. @@ -1589,7 +1589,7 @@ NOTE: With JSON serialization correctly configured, you can also use `Publisher< === Serializing via Jackson Quarkus has built-in support for JSON serialization and deserialization based on Jackson. -It will also <> the serializer and deserializer for you, so you do not have to configure anything. +It will also <> the serializer and deserializer for you, so you do not have to configure anything. When generation is disabled, you can use the provided `ObjectMapperSerializer` and `ObjectMapperDeserializer` as explained below. There is an existing `ObjectMapperSerializer` that can be used to serialize all data objects via Jackson. diff --git a/docs/src/main/asciidoc/mailer-reference.adoc b/docs/src/main/asciidoc/mailer-reference.adoc index 76ccbfdf7052a..897725b39da1a 100644 --- a/docs/src/main/asciidoc/mailer-reference.adoc +++ b/docs/src/main/asciidoc/mailer-reference.adoc @@ -316,7 +316,7 @@ More details about this extension and its configuration can be found in the http [TIP] -For more information about the Mailer configuration please refer to the <>. +For more information about the Mailer configuration please refer to the <>. == Configuring a trust store diff --git a/docs/src/main/asciidoc/security-customization.adoc b/docs/src/main/asciidoc/security-customization.adoc index 4399a90eb17e3..17b513c0e8519 100644 --- a/docs/src/main/asciidoc/security-customization.adoc +++ b/docs/src/main/asciidoc/security-customization.adoc @@ -12,7 +12,7 @@ include::_attributes.adoc[] `io.quarkus:quarkus-security` module contains the core Quarkus Security classes. In most cases, it does not have to be added directly to your project's build file as it is already provided by all the security extensions. -However, if you need to write your own custom security code (for example, register a <>) or use <> libraries, then please make sure it is included: +However, if you need to write your own custom security code (for example, register a <>) or use <> libraries, then please make sure it is included: [source,xml,role="primary asciidoc-tabs-target-sync-cli asciidoc-tabs-target-sync-maven"] .pom.xml diff --git a/docs/src/main/asciidoc/security-jwt-build.adoc b/docs/src/main/asciidoc/security-jwt-build.adoc index 9ad8f9afb5870..76365e2c562d5 100644 --- a/docs/src/main/asciidoc/security-jwt-build.adoc +++ b/docs/src/main/asciidoc/security-jwt-build.adoc @@ -133,7 +133,7 @@ import io.smallrye.jwt.build.Jwt; String jwt = Jwt.upn("Alice").sign(); ---- -Note the `sign` step can be combined with the <> step to produce `inner-signed and encrypted` tokens, see <> section. +Note the `sign` step can be combined with the <> step to produce `inner-signed and encrypted` tokens, see <> section. [[encrypt-claims]] == Encrypt the claims @@ -201,7 +201,7 @@ String jwt = Jwt.subject("Bob").encrypt(); Note that when the token is directly encrypted by the public RSA or EC key it is not possible to verify which party sent the token. Therefore, the secret keys should be preferred for directly encrypting the tokens, for example, when using JWT as cookies where a secret key is managed by the Quarkus endpoint with only this endpoint being both a producer and a consumer of the encrypted token. -If you would like to use RSA or EC public keys to encrypt the token then it is recommended to sign the token first if the signing key is available, see the next <> section. +If you would like to use RSA or EC public keys to encrypt the token then it is recommended to sign the token first if the signing key is available, see the next <> section. [[innersign-encrypt-claims]] == Sign the claims and encrypt the nested JWT token diff --git a/docs/src/main/asciidoc/security-jwt.adoc b/docs/src/main/asciidoc/security-jwt.adoc index 5f902935ef2f5..37f9bdd5d20b2 100644 --- a/docs/src/main/asciidoc/security-jwt.adoc +++ b/docs/src/main/asciidoc/security-jwt.adoc @@ -742,7 +742,7 @@ public class SecuredResource { } ---- -Please also see the <> section about using `JWTParser` without the `HTTP` support provided by `quarkus-smallrye-jwt`. +Please also see the <> section about using `JWTParser` without the `HTTP` support provided by `quarkus-smallrye-jwt`. === Token Decryption diff --git a/docs/src/main/asciidoc/security-keycloak-authorization.adoc b/docs/src/main/asciidoc/security-keycloak-authorization.adoc index bbb02157f3865..cc64943975af0 100644 --- a/docs/src/main/asciidoc/security-keycloak-authorization.adoc +++ b/docs/src/main/asciidoc/security-keycloak-authorization.adoc @@ -192,13 +192,13 @@ quarkus.keycloak.policy-enforcer.enable=true quarkus.keycloak.devservices.realm-path=quarkus-realm.json ---- -NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in a dev mode. See <> section below for more information. +NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in a dev mode. See <> section below for more information. NOTE: By default, applications using the `quarkus-oidc` extension are marked as a `service` type application (see `quarkus.oidc.application-type`). This extension also supports only `web-app` type applications but only if the access token returned as part of the authorization code grant response is marked as a source of roles: `quarkus.oidc.roles.source=accesstoken` (`web-app` type applications check ID token roles by default). == Starting and Configuring the Keycloak Server -NOTE: Do not start the Keycloak server when you run the application in a dev mode - `Dev Services for Keycloak` will launch a container. See <> section below for more information. +NOTE: Do not start the Keycloak server when you run the application in a dev mode - `Dev Services for Keycloak` will launch a container. See <> section below for more information. To start a Keycloak Server you can use Docker and just run the following command: @@ -277,7 +277,7 @@ After getting a cup of coffee, you'll be able to run this binary directly: == Testing the Application -See <> section above about testing your application in a dev mode. +See <> section above about testing your application in a dev mode. You can test the application launched in JVM or Native modes with `curl`. diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc index 54bcf1773f285..ff81993528580 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc @@ -267,7 +267,7 @@ quarkus.oidc.tls.trust-store-password=${trust-store-password} ==== Introspection endpoint authentication Some OIDC providers require authenticating to its introspection endpoint by using Basic authentication and with credentials that are different to the `client_id` and `client_secret`. -If you have previously configured security authentication to support either the`client_secret_basic` or `client_secret_post` client authentication methods as described in the <> section, you might need to apply the additional configuration, as follows. +If you have previously configured security authentication to support either the`client_secret_basic` or `client_secret_post` client authentication methods as described in the <> section, you might need to apply the additional configuration, as follows. If the tokens have to be introspected and the introspection endpoint-specific authentication mechanism is required, then you can configure `quarkus-oidc`, as follows: @@ -677,7 +677,7 @@ quarkus.http.auth.permission.public.policy=permit ---- You may also need to set `quarkus.oidc.authentication.cookie-path` to a path value common to all the application resources which is `/` in this example. -For more information, see the <> section. +For more information, see the <> section. [NOTE] ==== @@ -791,7 +791,7 @@ public class ServiceResource { [[oidc-session]] ====== Using `OidcSession` for local logout -`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`, which can help to perform a <>, retrieve the current session's tenant identifier, and check when the session will expire. +`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`, which can help to perform a <>, retrieve the current session's tenant identifier, and check when the session will expire. More useful methods will be added to it over time. [[session-management]] @@ -1327,7 +1327,7 @@ If a custom realm file has to be imported into Keycloak before running the tests quarkus.keycloak.devservices.realm-path=quarkus-realm.json ---- -Finally, write a test code the same way as it is described in the <> section. +Finally, write a test code the same way as it is described in the <> section. The only difference is that `@QuarkusTestResource` is no longer needed: [source, java] @@ -1384,7 +1384,7 @@ And configure the Maven Surefire plugin as follows: (and similarly the Maven Failsafe plugin when testing in native image). -And now set the configuration and write the test code the same way as it is described in the <> section. +And now set the configuration and write the test code the same way as it is described in the <> section. The only difference is the name of `QuarkusTestResource`: [source, java] diff --git a/docs/src/main/asciidoc/security-openid-connect-client-reference.adoc b/docs/src/main/asciidoc/security-openid-connect-client-reference.adoc index 31eb3b8b11608..c06de7492625f 100644 --- a/docs/src/main/asciidoc/security-openid-connect-client-reference.adoc +++ b/docs/src/main/asciidoc/security-openid-connect-client-reference.adoc @@ -389,7 +389,7 @@ Note it will also bring `io.quarkus:quarkus-oidc-client`. `quarkus-oidc-client-reactive-filter` extension provides `io.quarkus.oidc.client.filter.OidcClientRequestReactiveFilter`. -It works similarly to the way `OidcClientRequestFilter` does (see <>) - it uses `OidcClient` to acquire the access token, refresh it if needed, and set it as an HTTP `Authorization` `Bearer` scheme value. The difference is that it works with xref:rest-client-reactive.adoc[Reactive RestClient] and implements a non-blocking client filter which does not block the current IO thread when acquiring or refreshing the tokens. +It works similarly to the way `OidcClientRequestFilter` does (see <>) - it uses `OidcClient` to acquire the access token, refresh it if needed, and set it as an HTTP `Authorization` `Bearer` scheme value. The difference is that it works with xref:rest-client-reactive.adoc[Reactive RestClient] and implements a non-blocking client filter which does not block the current IO thread when acquiring or refreshing the tokens. `OidcClientRequestReactiveFilter` delays an initial token acquisition until it is executed to avoid blocking an IO thread. @@ -433,7 +433,7 @@ public interface ProtectedResourceService { `OidcClientRequestReactiveFilter` uses a default `OidcClient` by default. A named `OidcClient` can be selected with a `quarkus.oidc-client-reactive-filter.client-name` configuration property. You can also select `OidcClient` by setting `value` attribute of the `@OidcClientFilter` annotation. The client name set through annotation has higher priority than the `quarkus.oidc-client-reactive-filter.client-name` configuration property. -For example, given <> `jwt-secret` named OIDC client declaration, you can refer to this client like this: +For example, given <> `jwt-secret` named OIDC client declaration, you can refer to this client like this: [source,java] ---- @@ -510,7 +510,7 @@ Alternatively, `OidcClientRequestFilter` can be registered automatically with al `OidcClientRequestFilter` uses a default `OidcClient` by default. A named `OidcClient` can be selected with a `quarkus.oidc-client-filter.client-name` configuration property. You can also select `OidcClient` by setting `value` attribute of the `@OidcClientFilter` annotation. The client name set through annotation has higher priority than the `quarkus.oidc-client-filter.client-name` configuration property. -For example, given <> `jwt-secret` named OIDC client declaration, you can refer to this client like this: +For example, given <> `jwt-secret` named OIDC client declaration, you can refer to this client like this: [source,java] ---- diff --git a/docs/src/main/asciidoc/security-openid-connect-client.adoc b/docs/src/main/asciidoc/security-openid-connect-client.adoc index b44f959e00d5d..2a1670dca3fe5 100644 --- a/docs/src/main/asciidoc/security-openid-connect-client.adoc +++ b/docs/src/main/asciidoc/security-openid-connect-client.adoc @@ -329,11 +329,11 @@ org.acme.security.openid.connect.client.RestClientWithTokenPropagationFilter/mp- This configuration references Keycloak which will be used by `ProtectedResource` to verify the incoming access tokens and by `OidcClient` to get the tokens for a user `alice` using a `password` grant. Both RESTClients point to `ProtectedResource`'s HTTP address. -NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in dev or test modes. See <> section below for more information. +NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in dev or test modes. See <> section below for more information. == Starting and Configuring the Keycloak Server -NOTE: Do not start the Keycloak server when you run the application in dev mode or test modes - `Dev Services for Keycloak` will launch a container. See <> section below for more information. Make sure to put the link:{quickstarts-tree-url}/security-openid-connect-client-quickstart/config/quarkus-realm.json[realm configuration file] on the classpath (`target/classes` directory) so that it gets imported automatically when running in dev mode - unless you have already built a link:{quickstarts-tree-url}/security-openid-connect-quickstart[complete solution] in which case this realm file will be added to the classpath during the build. +NOTE: Do not start the Keycloak server when you run the application in dev mode or test modes - `Dev Services for Keycloak` will launch a container. See <> section below for more information. Make sure to put the link:{quickstarts-tree-url}/security-openid-connect-client-quickstart/config/quarkus-realm.json[realm configuration file] on the classpath (`target/classes` directory) so that it gets imported automatically when running in dev mode - unless you have already built a link:{quickstarts-tree-url}/security-openid-connect-quickstart[complete solution] in which case this realm file will be added to the classpath during the build. To start a Keycloak Server you can use Docker and just run the following command: @@ -411,7 +411,7 @@ After getting a cup of coffee, you'll be able to run this binary directly: == Testing the Application -See <> section above about testing your application in dev mode. +See <> section above about testing your application in dev mode. You can test the application launched in JVM or Native modes with `curl`. diff --git a/docs/src/main/asciidoc/security-openid-connect-dev-services.adoc b/docs/src/main/asciidoc/security-openid-connect-dev-services.adoc index 4582ddf498dea..67a51a1b768ec 100644 --- a/docs/src/main/asciidoc/security-openid-connect-dev-services.adoc +++ b/docs/src/main/asciidoc/security-openid-connect-dev-services.adoc @@ -105,7 +105,7 @@ You can use an `eraser` symbol in the right bottom corner to clear the test resu Sometimes ID tokens are forwarded to the application frontends as bearer tokens as well for the endpoints be aware about the user who is currently logged into SPA or to perform an out-of-band token verification. Choose `Test with ID Token` option in such cases. -Manually entering the service paths is not ideal, so please see the <> section about enabling Swagger or GraphQL UI for testing the service with the access token already acquired by OIDC Dev UI. +Manually entering the service paths is not ideal, so please see the <> section about enabling Swagger or GraphQL UI for testing the service with the access token already acquired by OIDC Dev UI. Finally, you can select a `Log Out` image::dev-ui-keycloak-logout.png option if you'd like to log out and authenticate to Keycloak as a different user. @@ -198,7 +198,7 @@ To make Dev UI more useful for supporting the development of OIDC `web-app` appl %dev.quarkus.oidc.application-type=service ---- -It will ensure that all Dev UI options described in <> will be available when your `web-app` application is run in dev mode. The limitation of this approach is that both access and ID tokens returned with the code flow and acquired with Dev UI will be sent to the endpoint as HTTP `Bearer` tokens - which will not work well if your endpoint requires the injection of `IdToken`. +It will ensure that all Dev UI options described in <> will be available when your `web-app` application is run in dev mode. The limitation of this approach is that both access and ID tokens returned with the code flow and acquired with Dev UI will be sent to the endpoint as HTTP `Bearer` tokens - which will not work well if your endpoint requires the injection of `IdToken`. However, it will work as expected if your `web-app` application only uses the access token, for example, as a source of roles or to get `UserInfo`, even if it is assumed to be a `service` application in dev mode. Even a better option is to use a `hybrid` application type in devmode: diff --git a/docs/src/main/asciidoc/writing-extensions.adoc b/docs/src/main/asciidoc/writing-extensions.adoc index fd239bd8c15ad..f185a27b431d3 100644 --- a/docs/src/main/asciidoc/writing-extensions.adoc +++ b/docs/src/main/asciidoc/writing-extensions.adoc @@ -1373,7 +1373,7 @@ If the guide includes an `application.properties` example, a tip must be include [source, asciidoc] ---- [TIP] -For more information about the extension configuration please refer to the <>. +For more information about the extension configuration please refer to the <>. ---- And at the end of the guide, the extensive configuration documentation: @@ -3029,7 +3029,7 @@ Before publishing your extension to the xref:tooling.adoc[Quarkus tooling], make * Your extension is published in Maven Central -* Your extension repository is configured to use the <>. +* Your extension repository is configured to use the <>. Then you must create a pull request adding a `your-extension.yaml` file in the `extensions/` directory in the link:https://github.com/quarkusio/quarkus-extension-catalog[Quarkus Extension Catalog]. The YAML must have the following structure: diff --git a/docs/src/main/asciidoc/writing-native-applications-tips.adoc b/docs/src/main/asciidoc/writing-native-applications-tips.adoc index 06dbf77e8961f..ffc534ecc3315 100644 --- a/docs/src/main/asciidoc/writing-native-applications-tips.adoc +++ b/docs/src/main/asciidoc/writing-native-applications-tips.adoc @@ -410,7 +410,7 @@ and instead code that interacts with optional dependencies should be moved into [[enforcing-singletons]] === Enforcing Singletons -As already explained in the <> section, +As already explained in the <> section, Quarkus marks all code to be initialized at build time by default. This means that, unless marked otherwise, static variables will be assigned at build time,