-
Notifications
You must be signed in to change notification settings - Fork 3k
Migration Guide 3.18
|
Note
|
We highly recommend the use of Items marked below with ⚙️ ✅ are automatically handled by |
In dev and test mode, the management interface will now listen on the localhost interface by default (instead of 0.0.0.0) to be made consistent with the behavior of the main interface.
Note that similarly to what has been done for the main interface, on Windows with WSL, it will continue to listen to 0.0.0.0.
For JSON templates the ", \ and the control characters (U+0000 through U+001F) are escaped by default if a corresponding template variant is set. In Quarkus, a variant is set automatically for templates located in the src/main/resources/templates. By default, the java.net.URLConnection#getFileNameMap() is used to determine the content-type of a template file. The additional map of suffixes to content types can be set via quarkus.qute.content-types. If you need to render the unescaped value use the raw or safe properties implemented as extension methods of the java.lang.Object, or wrap the String value in a io.quarkus.qute.RawString.
This release of Quarkus includes SmallRye Fault Tolerance 6.7.0. This version technically does not contain any breaking changes, but:
-
The first version of the programmatic API (
FaultTolerance,@ApplyFaultTolerance) is deprecated and will be removed in SmallRye Fault Tolerance 7.0. The second version (Guard,TypedGuard,@ApplyGuard) is relatively similar, but there are still significant differences. -
The specification-defined configuration properties can still be used, but there are Quarkus-native configuration properties now.
See the SmallRye Fault Tolerance 6.7.0 release announcement (https://smallrye.io/blog/fault-tolerance-6-7-0/) for more information, including links to the migration guides for the programmatic API and a description of the new configuration properties. The Quarkus guide for SmallRye Fault Tolerance includes a full reference of the new configuration properties as well.
Query parameters set to an empty value (for example: ?foo=) used to produce an empty String value ("") when deserialised as @RestQuery String foo or a collection of size one with an empty string value when deserialised as @RestQuery List<String> foo.
This has been changed in https://github.com/quarkusio/quarkus/pull/42468#issuecomment-2302312141 to produce a null value when deserialised as @RestQuery String foo and an empty collection when deserialised as @RestQuery List<String> foo.
This release is now updated to Flyway 11, which removes the cleanOnValidationError configuration.
The Quarkus team initially decided to delete the configuration instead of deprecating it, but in 3.18.2, we introduced quarkus.flyway.validate-at-start.clean-on-validation-error which allows to get a similar behavior (implemented in Quarkus itself) but only for validate-at-start.
With Quarkus 3.18, only ObjectMapperCustomizer beans that don’t use any qualifiers are applied to the default ObjectMapper Quarkus creates. Previously all customizers beans - even ones with custom qualifers - were applied to the default ObjectMapper.
This release includes the version upgrade for the Fabric8 Kubernetes Client from version 6.13 to version 7.0.
The client is used and exposed by the quarkus-kubernetes-client and quarkus-openshift-client extensions.
And by the quarkus-kubernetes and quarkus-openshift extensions, however, for these no changes should be required.
The complete and original upstream migration guide can be found at fabric8io/kubernetes-client/doc/MIGRATION-v7.md.
With respect to Quarkus, the most important change is the removal of the io.quarkus:quarkus-test-openshift-client module.
You should use instead the standard io.quarkus:quarkus-test-kubernetes-client which provides the same functionality.
Please check the guide for additional information.
Additionally, some of the model classes have moved to different modules. Make sure to check the migration guide to locate the new module in case a class is no longer found.
The quarkus-security-webauthn module has been reimplemented on top of WebAuthn4J. As a result, it is not binary or source compatible with the previous versions, and you must update the following code:
-
All
userNamereferences have been replaced withusername -
The
Authenticatortype-
The
Authenticatorclass (from Vert.x) is no longer used, and has been replaced functionally withWebAuthnCredentialRecord. It holds similar data to the previous class, but as it is a subtype of a WebAuthn4J type, accessing its content is slightly different. -
Its replacing type
WebAuthnCredentialRecordnow has agetRequiredPersistedData()method which returns aRequiredPersistedDatarecord holding all the data you need to persist to your data source (database, or anything persistent), to make it easier. -
The static method
WebAuthnCredentialRecord.fromRequiredPersistedData(RequiredPersistedData)allows you to turn your stored data into aWebAuthnCredentialRecordfor the opposite operation. -
If you had any JPA entities or database tables storing the old
Authenticatorformat of data, you will need to update them to the new set of data. Open an issue if you need help for that.
-
-
The
WebAuthnUserProvidertype that you had to implement has been restructured:-
findWebAuthnCredentialsByUserName()was renamed tofindByUsername() -
findWebAuthnCredentialsByCredID()was renamed tofindByCredentialId() -
updateOrStoreWebAuthnCredentialswas split into the two methods it represented:update(String credentialId, long counter)andstore(WebAuthnCredentialRecord credentialRecord)
-
-
Default endpoints:
-
/q/webauthn/loginwas renamed to/q/webauthn/login-options-challenge -
/q/webauthn/registerwas renamed to/q/webauthn/register-options-challenge -
/q/webauthn/callbackwas split into the two operations it represented:/q/webauthn/loginand/q/webauthn/register. These endpoints are now disabled by default (for security reasons) and can be enabled using thequarkus.webauthn.enable-registration-endpointandquarkus.webauthn.enable-login-endpointconfiguration properties. -
/q/webauthn/registernow requires ausernamequery parameter. -
/.well-known/webauthnwas added to return the list of allowed related origins -
The user name for
loginandlogin-options-challengeis now optional -
The
/q/webauthn/login-options-challengeand/q/webauthn/registerendpoints moved fromPOSTtoGETmethods and now take their parameters via query parameters instead of JSON bodies
-
-
WebAuthnSecurity-
Two methods have been added to
WebAuthnSecurity:getLoginOptionsChallenge()andgetRegisterOptionsChallenge()to make it easier to call and customise them. -
The user name parameter for
login()andloginOptionsChallenge()is now optional -
The
register()method now takes an additionalusernameparameter (due to the removal of the username cookie)
-
-
Configuration:
-
The
quarkus.webauthn.require-resident-key(boolean defaulting tofalse) setting has been replaced by thequarkus.webauthn.resident-key(enum defaulting toREQUIRED) -
The
quarkus.webauthn.challenge-username-cookie-namesetting has been removed along with its related cookie. -
The
quarkus.webauthn.load-metadata(boolean defaulting tofalse) setting has been added to control loading of FIDO metadata. -
The
quarkus.webauthn.user-presence-required(boolean defaulting totrue) setting has been added to control the requirement of user presence. -
The
quarkus.webauthn.user-verificationsetting has changed default fromDISCOURAGEDtoREQUIRED. -
The
quarkus.webauthn.timeoutdefault has increased from1 minuteto5 minutesas specified in the WebAuthn standard -
The
quarkus.webauthn.pub-key-cred-paramssetting has been renamed toquarkus.webauthn.public-key-credential-parameters -
The
quarkus.webauthn.originsetting has been renamed toquarkus.webauthn.origins(plural) and now allows more than one origin (as required by spec) -
The new
quarkus.webauthn.enable-registration-endpointboolean configuration (defaults tofalse) enables the default registration endpoint. -
The new
quarkus.webauthn.enable-login-endpointboolean configuration (defaults tofalse) enables the default login endpoint.
-
-
The verification of WebAuthn credential attestations may differ slightly for settings of
quarkus.security.webauthn.attestationother thanNONE(the default). -
In the
quarkus-test-security-webauthntest module:-
The
WebAuthnHardwarecontructor now requires aURLto represent the location of your endpoints, you can obtain in your test classes it using@TestHTTPResource URL url -
The
WebAuthnEndpointHelper.invokeRegistrationmethod was renamed toobtainRegistrationChallenge -
The
WebAuthnEndpointHelper.invokeLoginmethod was renamed toobtainLoginChallenge -
The
WebAuthnEndpointHelper.invokeCallbackmethod was split into the two operations it represented:WebAuthnEndpointHelper.invokeRegistrationandWebAuthnEndpointHelper.invokeLogin -
The
WebAuthnEndpointHelper.invokeLoginandWebAuthnEndpointHelper.obtainLoginChallengeuser name parameter is now optional -
The
WebAuthnEndpointHelper.invokeRegistrationmethod now takes ausernameparameter
-
-
JavaScript library:
-
The
registerOnlymethod has been renamed toregisterClientSteps -
The
loginOnlymethod has been renamed tologinClientSteps -
The
loginandloginClientStepsmethod’suserparameter is now optional -
The constructor’s
registerPathhas been renamed toregisterOptionsChallengePathand has the default value/q/webauthn/register-options-challenge -
The constructor’s
loginPathhas been renamed tologinOptionsChallengePathand has the default value/q/webauthn/login-options-challenge -
The constructor’s
callbackPathhas been split into its two componentsregisterPath(default value/q/webauthn/register) andloginPath(default value/q/webauthn/login -
The constructor now accepts a
csrfoption of typeJsonObjectwith two keys:headerfor the header name to use to add the CSRF token, andvaluefor the CSRF token value. This is mostly useful when usingquarkus-csrfand using custom endpoints that are protected by CSRF (unlike the default endpoints).
-
We have also downgraded its status from preview to experimental to allow extra bake time with those changes.
Quarkus uses a specific JUnit ClassOrderer to reduce restarts of Quarkus, but it is also possible to set a custom one. In previous versions, to replace the Quarkus JUnit ClassOrderer it required excluding the dependency io.quarkus:quarkus-junit5-properties and setting one in junit-platform.properties. Now, to override the Quarkus JUnit ClassOrderer, set the FQCN in the configuration property quarkus.test.class-orderer in any configuration source. If the class cannot be found, it falls back to JUnit default behaviour, which does not set a ClassOrderer.
For a long time, the metrics and spans for non-application endpoints such as /q/arc/ or /q/openapi/ were reported without the /q prefix (e.g. /arc/ or openapi).
It has now been fixed and they are properly reported with the /q prefix.
Note that they will also be properly suppressed from the metrics and spans if the suppression of non application URLs is enabled (which is the default).
The driver and container image (used for Dev Services) were upgraded to version 12.
It comes with some changes on how to register your license. See https://www.ibm.com/support/pages/features-behavior-change-while-upgrading-db2connect-121-driver for more information.