User management¶
Passwords¶
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 user/password
permission.
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.
The template for this email is located in /Resources/views/Security/mail/forgot_user_password.html.twig
in ezsystems/ezplatform-user
.
You can customize it according to your needs.
The validity of the password recovery token can be set using the ezpublish.system.<siteaccess>.security.token_interval_spec
parameter.
By default it is set to PT1H
(one hour).
Setting password expiration¶
You can set password expiry rules, which will force users to change their passwords periodically.
Password expiry is defined per User Field Type.
You can set it for the User Content Type in the ezuser
Field Type's settings:
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.
Repeating passwords¶
You can set a rule that the password cannot be reused.
You set it for the User Content Type in the 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.
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.
User Groups¶
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 templates¶
You can use custom templates for the registration form and registration confirmation page.
The templates are defined with the following configuration:
1 2 3 4 5 6 7 |
|
With this configuration you place the templates in app/Resources/views/user/registration_form.html.twig
and app/Resources/views/user/registration_confirmation.html.twig
.
Here are default templates that you can reuse and/or modify:
Registration form:
1 2 3 4 5 6 7 8 |
|
Registration confirmation:
1 2 3 4 5 6 7 |
|
Other user management templates¶
You can also modify the following form templates:
Changing user password:
1 2 3 4 5 6 |
|
Password recovery forms:
1 2 3 4 |
|
Resetting password:
1 2 3 |
|
User settings:
1 2 |
|
Authenticating 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.).
Caution
BeSimpleSsoAuthBundle
requires an outdated version of kriswallsmith/buzz
package (>=0.7,<=0.16.1) and therefore cannot be used in eZ Platform 2.5 until that is solved in BeSimpleSsoAuthBundle
itself.
However, to be able to use external user providers with eZ Platform, 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), eZ Platform kernel initiates an MVCEvents::INTERACTIVE_LOGIN
event.
Every service listening to this event receives an eZ\Publish\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 eZ Platform 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 InteractiveLoginToken
.
This token holds a UserWrapped
instance which contains the originally matched user and the API user (the one from the eZ Platform repository).
Note that the API user is mainly used for permission checks against the repository and thus stays under the hood.
Customizing the User class¶
It is possible to customize the user class used by extending ezpublish.security.login_listener
service, which defaults to eZ\Publish\Core\MVC\Symfony\Security\EventListener\SecurityListener
.
You can override getUser()
to return whatever User class you want, as long as it implements eZ\Publish\Core\MVC\Symfony\Security\UserInterface
.
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 |
|
Implementing the listener¶
In the services.yml
file in your AcmeExampleBundle:
1 2 3 4 5 6 7 8 9 |
|
Do not mix MVCEvents::INTERACTIVE_LOGIN
event (specific to eZ Platform) 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 |
|