Changing and recovering passwords¶
The user may request to change their password, or may forget it and ask to have it reset.
To change password, the user must have the
When the user requests a reset of a forgotten password, an email is sent to them with a token. It allows them to create a new password.
For information about how to create and configure the template, see Add forgot password option
The template for this email is located in
You can customize it according to your needs.
The validity of the password recovery token can be set using the
By default, it is set to
PT1H (one hour).
In case of a security situation such as a data leakage, you may need to force users to change their passwords.
You can do it with the help of the
which revokes the passwords for specific users, User Groups or users belonging to the chosen Content Type.
To select which users to revoke passwords for, use one of the following options with the command:
--user-id|-u- the ID of the user. Accepts multiple user IDs
--user-group-id|-ug- the ID of the User Group. Accepts multiple group IDs
--user-content-type-identifier|-ct- the identifier of the user Content Type. Accepts multiple Content Types
You can use the following additional options with the command:
--force|-f- commits the change, otherwise the command only performs a dry run
--iteration-count|-c- defines how many users are fetched at once. Lowering this value helps with memory issues
--password-ttl|-t- number of days after which new passwords expire. Used when the command enables password expiration for user Content Types that do not use it yet.
For example, to revoke the passwords of all users of the
user Content Type, run:
To perform a dry run (without saving the results) of revoking passwords of all users from User Group 13, run:
You can customize the password policy in your project. Each password setting is customizable per User Field Type. You can change the password attributes or password expiration settings, and determine the rules for repeating passwords.
To access the password settings:
- In the Back Office, in the Admin Panel, open the Content Types tab.
- In the Content Type groups table, click on Users.
- Edit the User Content Type.
- In the Field definitions list, view the settings for User account (ezuser).
There can be other Content Types that function as users, beyond the built-in User Content Type. For details, see User Identifiers.
In the User account (ezuser) Field definition, you can determine if the password must contain at least:
- One uppercase letter
- One lowercase letter
- One number
- One non-alphanumeric character
You can also set the minimum password length.
In the User account (ezuser) Field definition, you can set password expiration rules, which will force users to change their passwords periodically.
You can also decide when the user will be notified that they need to change their password. The notification will be displayed in the Back Office after login and in the User Content item's preview.
You can set a rule that the password cannot be reused. You set it for the User Content Type in the User account (ezuser) Field Type's settings. When this is set, the user cannot type in the same password when it expires. It has to be changed to a new one.
This only checks the new password against the current one. A password that has been used before can be used again.
This rule is valid by default when password expiration is set.
You can set a rule that prevents using passwords which have been exposed in a public breach. To do this, in the User account (ezuser) Field definition, select "Password must not be contained in a public breach".
This rule checks the password against known password dumps by using the https://haveibeenpwned.com/ API. It does not check existing passwords, so it will not block login for anyone. It applies only to new passwords when users change them.
Two login methods are available: with User name or with email.
Providers for these two methods are
You can configure which method is allowed under the
security configuration key:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
You can customize per User Field whether the email address used as a login method must be unique or not.
To check that all existing User accounts have unique emails,
It will list all User accounts with duplicate emails.
Because logging in with email was not available until version v3.0, you can come across issues if you use the option on an existing database.
This may happen if more than one account uses the same email address. Login through the User name will still be available.
To resolve the issues, run
and manually modify accounts that have duplicate emails.
You can set the rules for allowed User names in the Back Office per User Field.
The rules are set using regular expressions.
For example, to ensure that User names can only contain lowercase letters,
[a-z]+$ as Username pattern:
To check that all existing User accounts have names that fit the current pattern,
It will check all User accounts in the database and list those that do not fit the pattern.
Registering new users¶
You can allow your users to create accounts by employing the
/register route. This route leads to a registration form that, when filled in, creates a new User Content item in the repository.
There are two user types defined:
users are Back Office users that are involved in creating the page such as editors, and
customers are frontend users.
To decide where the user should be registered to, you need to specify their user type under the
ibexa.system.<scope>.user_type_identifier configuration key.
1 2 3 4 5
By default, new Users generated in this way are placed in the Guest accounts group. You can select a different default group in the following section of configuration:
1 2 3 4 5
Registration form field configuration¶
To modify the registration form template, add or remove fields under the
allowed_field_definitions_identifiers configuration key:
1 2 3 4 5 6 7 8 9 10
Other user management templates¶
You can also modify form templates in the following way:
Changing user password:
1 2 3 4 5 6
Password recovery forms:
1 2 3 4
1 2 3
Authenticate user with multiple user providers¶
Symfony provides native support for multiple user providers. This makes it easy to integrate any kind of login handlers, including SSO and existing third party bundles (e.g. FR3DLdapBundle, HWIOauthBundle, FOSUserBundle, BeSimpleSsoAuthBundle, etc.).
However, to be able to use external user providers with Ibexa DXP, a valid Platform user needs to be injected into the Repository. This is mainly for the kernel to be able to manage content-related permissions (but not limited to this).
Depending on your context, you will either want to create a Platform User, return an existing User, or even always use a generic User.
Whenever an external user is matched (i.e. one that does not come from Platform repository, like coming from LDAP), Ibexa DXP kernel initiates an
Every service listening to this event receives an
Ibexa\Core\MVC\Symfony\Event\InteractiveLoginEvent object which contains the original security token (that holds the matched user) and the request.
Then, it is up to the listener to retrieve a Platform User from the Repository and to assign it back to the event object. This user will be injected into the repository and used for the rest of the request.
If no Ibexa DXP User is returned, the Anonymous User will be used.
User exposed and security token¶
When an external user is matched, a different token will be injected into the security context, the
This token holds a
UserWrapped instance which contains the originally matched User and the API user (the one from the Ibexa DXP Repository).
Note that the API user is mainly used for permission checks against the repository and thus stays under the hood.
Customize the User class¶
It is possible to customize the user class used by extending
Ibexa\Core\MVC\Symfony\Security\EventListener\SecurityListener service, which defaults to
You can override
getUser() to return whatever User class you want, as long as it implements
The following is an example of using the in-memory user provider:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Implement the listener¶
1 2 3 4 5
Do not mix
MVCEvents::INTERACTIVE_LOGIN event (specific to Ibexa DXP) and
SecurityEvents::INTERACTIVE_LOGIN event (fired by Symfony security component).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35