Users and registration #

This page is for developers who build sites where visitors sign up, sign in and have a profile. In Exponential a user account is a content object, so extending a profile is the same work as extending any class, and access is the same role system as for content.

Contents #

1. Users are content
2. User groups and roles
3. Self-registration
4. Activation and approval
5. Passwords
6. Sign-in: handlers and two-factor
7. The user module's pages and templates
8. Users in templates and PHP
9. Privacy

Users are content #

A user is an object of the user class (site.ini [UserSettings] UserClassID=4) with an ezuser attribute that holds the login, the e-mail address and the password hash. Add attributes for a profile (a portrait, a biography, a company) in the class editor like for any class. Groups are objects of the user group class (UserGroupClassID=3). Every account, also the anonymous visitor (AnonymousUserID=10), lives in the user tree below node 5.

User groups and roles #

A user belongs to the groups its nodes are in; a user with two locations is in two groups. Roles are assigned to groups, so moving or adding a location changes what a user may do. Typical groups: Members for registered visitors, Editors, Administrators. Keep editors and members in separate groups so a member can never gain editing rights by a role meant for staff (Sections, roles and policies).

Self-registration #

Visitors register on /user/register when the Anonymous role has user/register. The settings are in site.ini [UserSettings]:

Change them in your siteaccess or extension settings, never in settings/site.ini. A workflow on the registration can hold accounts for approval (Workflows and triggers). Protect the registration form from spam with a captcha datatype on the user class (recaptcha, hcaptcha; Choosing datatypes).

Activation and approval #

Unconfirmed accounts are listed under Users > Unactivated users (user/unactivated), where an administrator can activate or remove them; ActivationByAdministratorSendsApprovalMail=enabled sends the user the approval mail. The administrator's mail about a new registration carries signed links to view, approve or reject the account (RegistrationAdminLinks=enabled; Signed links in the registration mail). Old unactivated accounts are cleaned up as described in Roles, policies and unactivated users, section 7.

Passwords #

Never store, log or mail passwords in clear text, and keep PasswordInRegistrationEmail=disabled. Administrators reset a password with ./console exp:resetuserpassword --help (Reset a user's password).

Sign-in: handlers and two-factor #

[UserSettings] LoginHandler[] lists the handlers tried in order; standard checks the database. The kernel also has handlers for LDAP (ldap.ini) and a text file, and an extension can add its own in extension/<ext>/login_handler/ (Handlers named by settings). Two-factor sign-in comes from the sevenx_authentication_2fa extension of the default distribution (Two-factor sign-in). MaxNumberOfFailedLogin (0, off, when shipped) can lock an account after failed attempts.

The user module's pages and templates #

The module user has the views login, logout, register, activate, forgotpassword, password, edit, preferences and unactivated among others (kernel/user/). Their templates are in user/ of the design chain; override them in your design extension to match the site, keeping the field names the module reads (User and login templates). A profile page is the full view of the user object, so it is styled with an override for the user class.

Users in templates and PHP #

{def $current = fetch( 'user', 'current_user' )}
{if $current.is_logged_in}
    <a href={'/user/edit'|ezurl}>{$current.contentobject.name|wash()}</a>
{/if}
{undef $current}

Output that depends on the user must not land in a cache shared by all visitors: see Caching for CMS developers. In PHP, eZUser::currentUser() returns the signed-in user and eZUser::fetchByName() or eZUser::fetchByEmail() find others (eZUser and access).

Privacy #

User objects hold personal data. Collect only what the site needs, keep test accounts at example.invalid, and plan how accounts are retired: Deactivate and move (DeactivateAndMove, off by default) disables accounts and parks them in a hidden group without removing them (Check user accounts).

Related pages #

• Accounts and sign-in: the user's view
• Security checklist
• Forms and information collection
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.