The provided version of Kotlin was upgraded from 2.0.0 to 2.0.20.
2.0.0
2.0.20
Plug-in developers are encouraged to upgrade to this version to remain aligned with the included version.
The fragments/poller.vm template, containing shared logic for client-side polling, was updated to improve how certain elements are located in the HTML page. As a consequence, the following templates were also updated:
fragments/poller.vm
authentication-action/require-active-account/poller.vm
authenticator/duo/authenticate/device-poller.vm
authenticator/duo/register/register-device-poller.vm
authenticator/email/link-wait/index.vm
authenticator/encap/wait/index.vm
authenticator/openid-wallet/launch/index.vm
authenticator/openid-wallet/wait/index.vm
authenticator/sms/link-wait/get.vm
authenticator/sms/register/wait.vm
consentor/bankid-signing-consentor/bankid-poller.vm
The changes are retro-compatible but it is recommended that any custom templates based on the above items are also updated. Specifically, the form elements in those templates should now have the poller-onsuccess class.
form
poller-onsuccess
During an authentication flow, it is possible for an user to try to access an invalid authentication action, namely if they try to navigate back using the browser’s back-button. The Curity Identity Server has a protection against these invalid accesses that produces an error page, involving the following changes:
_authnRecoverInfo
views/error/403/index.vm
fragments/recover-from-invalid-action.vm
The error page produced when the user tries to access an invalid authentication action only appears when the browser does a request to the Curity Identity Server, for instance when the user submits a form. To improve user experience, the Curity Identity Server also added the ability to detect a back navigation to an invalid action in the browser-side and immediately present a dialog warning the issuer that they are navigation to a page that isn’t valid anymore, even before the user interacts with that page. The presented dialog can be customized by overriding the fragments/invalid-authn-action-dialog fragment, which is conditionally included by the default.vm template. This detection requires the inclusion of the fragments/detect-invalid-authn-action-page.vm fragment, containing JavaScript, which is also conditionally included in the fragments/header fragment. By default, this browser-side early detection feature is disabled. To enable it, set the $enableDetectInvalidAuthnActionPage setting to true (see settings.vm).
fragments/invalid-authn-action-dialog
default.vm
fragments/detect-invalid-authn-action-page.vm
fragments/header
$enableDetectInvalidAuthnActionPage
true
settings.vm
As a result of these changes, the following steps should be carried out:
If the early detection of navigation to an invalid page should be used, then:
fragments/invalid-authn-action-dialog.vm
For more information please see comments present in the views/error/403/index.vm, fragments/recover-from-invalid-action.vm, fragments/detect-invalid-authn-action-page.vm, and fragments/invalid-authn-action-dialog.vm templates.
The DynamoDB data source manages account and credential data as a whole, so credential management operations - namely storing/updating a credential - can only be performed for existing user accounts. In previous versions, a credential update for an account that wasn’t found would be silently ignored. This was incorrect and has been fixed in the current release so that such update fails.