Create password reset token
Event action – Abstract
Purpose: Assigns a newly generated 'Password token' (base64 string) to a user account, which can be used to assign a new password without logging in.
Background: What is a password token used for?
Typically, the Produktname client is started with a token string for the URL parameter pwdRequestToken after a user uses the Passwort-Vergessen-Funktion in the login dialog to request an e-mail with a corresponding link. The user can use the link with the 'Password token' to set a new password for their user account within a limited validity period from the time of creation (default: 24 hours).
The Create password reset token event action does not actually play a role in this interactively triggered process. Rather, it is used to automatically set a user account to a state in which a 'Password token' can be used to change the password.
Optionally, the event 'Password; Reset requested' (see Password action (Events)) can also be triggered, which usually causes an e-mail message with a link (incl. token) to be sent to the user (see ''Forgot password' function).
The Create password reset token event action expects a user account (see Users) as the reference object to which a new Base64-encoded password token is assigned.
The character string for the created token is assigned as a value to the hidden property 'Password reset token' (lastResetPasswordToken) in this user account.
CAUTION
A token is only created if the relevant user account has at least one communication information attribute with the Communication type 'E-mail' (EMAIL).
When a new password is set for the user account, the token becomes invalid and the 'Password reset token' (lastResetPasswordToken) field is deleted again.
If the validity of an unused token expires, the text value in the 'Password reset token' (lastResetPasswordToken) property is retained. However, the token can no longer be used to change the password.
►IMPORTANT◄ The user account available as a reference object is flagged for saving (see Save changes later) so that the change for the 'Password reset token' (lastResetPasswordToken) field is retained in the commit.
If there is no write access for the user account in the execution context, an error with rollback occurs for the transaction.
The save flag also applies to all changes to the relevant user account that are made before and after the Create password reset token event action is executed in the context of the transaction.
The Dispatch Password-Request-Event option can be used to additionally trigger the 'Password: Reset requested' event (see Password action (Events)) for the user account available as a reference object, which is also triggered in the context of the 'Forgot password' function.
If the Dispatch Password-Request-Event option is selected, the Application Base URL parameter should be used to define the base URL for the Lobster Data Platform / Orchestration client to which the user in question should be referred for the password change via link.
Configuration
The user account for which a password token is to be created must exist as a reference object for the Create password reset token event action. If this is not guaranteed by the triggering event (e.g. create or change), this reference must be established via a suitable event action – e.g. Execute with or For each loop.
►NOTE◄ If there is no user account as a reference object in the context of the Create password reset token event action, the event action has no effect. However, no error will occur.
|
Parameter |
Description |
Example |
|
Dispatch Password-Request-Event option |
The Dispatch Password-Request-Event option is unchecked by default. It can be checked to trigger the 'Password: Reset requested' event (see Password action (Events)) for the user account specified as the reference object in order to execute workflows created for the 'Forgot password' function. |
►NOTE◄ If required, the base URL applicable in the execution context of the event action can be determined via the Session information value resolver from the additionalData-Map with the key (or via Object property) serverURL. |
|
Application Base URL text value |
If the Dispatch Password-Request-Event option is checked, this parameter should be used to specify the 'base URL' for accessing Lobster Data Platform / Orchestration, which the user should use to establish a new password. By default, the optional Application Base URL parameter allows the direct input of text. By clicking on the small gray arrow (bottom left in the text field), the user interface switches to the value configuration. ►IMPORTANT◄ Even if the parameter appears optional, a value assignment (via direct input or value resolver) should not be omitted if the Create password reset token event is triggered. Otherwise, the text 'null' will appear in the links that this event provides via variables instead of a base URL. A link such as null?pwdRequestToken=... is then effectively useless. |
Example
A custom overview (see Custom overviews) only shows Users for whom the following conditions are met:
The 'active' property has the value false. The user account is therefore 'inactive'.
The account address contains at least one piece of communication information of the Communication type 'E-mail' (EMAIL).
A button is offered for the 'Administrator' role in the overview ribbon, which triggers a Custom action event 'Reactivate user' (REACTIVATE_USER) for a single or multiple selection.
An event handling for this event should 'Reactivate' the user account and ensure that the user in question receives a link with a 'Password token' by e-mail, which can be used to assign a new password for the account:
For general users, the link should use the base URL 'https://common.doma.in'.
For users in whose address the flag attribute 'Vip' (VIP) is set, the base URL in the link should be 'https://vip.doma.in'.
Configuration:
|
The Triggering event is a Custom action event ('Reactivate user') that has been set up specifically for this workflow and is called up via a ribbon macro. A Validating rule is a Check type for the 'User' entity type. Further checks can be omitted here, as the context of the custom overview with the ribbon marker contains the corresponding restrictions (only 'inactive' users with e-mail address as 'communication information'). The following two event actions are executed under the Action on passed rule:
|
|
