Front-end user management for October CMS

The Rain Lab

Last update: Nov 20, 2022

Related tags

CMS user-plugin

Overview

Front-end user plugin

Front-end user management for October CMS.

Requirements

This plugin requires the Ajax Framework to be included in your layout/page in order to handle form requests.

Managing users

Users are managed on the Users tab found in the back-end. Each user provides minimal data fields - Name, Surname, Email and Password. The Name can represent either the person's first name or their full name, making the Surname field optional, depending on the complexity of your site.

Below the Email field is an checkbox to block all outgoing mail sent to the user. This is a useful feature for accounts with an email address that is bouncing mail or has reported spam. When checked, no mail will ever be sent to this address, except for the mail template used for resetting the password.

Plugin settings

This plugin creates a Settings menu item, found by navigating to Settings > Users > User settings. This page allows the setting of common features, described in more detail below.

Registration

Registration to the site is allowed by default. If you are running a closed site, or need to temporarily disable registration, you may disable this feature by switching Allow user registration to the OFF setting.

Activation

Activation is a process of vetting a user who joins the site. By default, users are activated automatically when they register and an activated account is required to sign in.

The Activation mode specifies the activation workflow:

Automatic: This mode will automatically activate a user when they first register. This is the same as disabling activation entirely and is the default setting.
User: The user can activate their account by responding to a confirmation message sent to their nominated email address.
Administrator: The user can only be activated by an administrator via the back-end area.

You can allow users to sign in without activating by switching Sign in requires activation to the OFF setting. This is useful for minimising friction when registering, however with this approach it is often a good idea to disable any "identity sensitive" features until the user has been activated, such as posting content. Alternatively, you could implement a grace period that deletes users (with sufficient warning!) who have not activated within a given period of time.

Users have the ability to resend the activation email by clicking Send the verification email again found in the Account component.

Sign in

By default a User will sign in to the site using their email address as a unique identifier. You may use a unique login name instead by changing the Login attribute value to Username. This will introduce a new field called Username for each user, allowing them to specify their own short name or alias for identification. Both the Email address and Username must be unique to the user.

If a user experiences too many failed sign in attempts, their account will be temporarily suspended for a period of time. This feature is enabled by default and will suspend an account for 15 minutes after 5 failed sign in attempts, for a given IP address. You may disable this feature by switching Throttle attempts to the OFF setting.

As a security precaution, you may restrict users from having sessions across multiple devices at the same time. Enable the Prevent concurrent sessions setting to use this feature. When a user signs in to their account, it will automatically sign out the user for all other sessions.

Notifications

This feature is implemented by the Notify plugin. How to use this feature:

Install the RainLab.Notify plugin
Navigate to Settings > Notification rules
Click New notification rule
Select User > Activated
Click Add action
Select Compose a mail message
Select User email address for the Send to field
Here you may select the Mail template previously defined in the user settings.
Click Save

Extended features

For extra functionality, consider also installing the User Plus+ plugin (RainLab.UserPlus).

Session component

The session component should be added to a layout that has registered users. It has no default markup.

User variable

You can check the logged in user by accessing the {{ user }} Twig variable:

{% if user %}
    Hello {{ user.name }}
{% else %}
    Nobody is logged in
{% endif %}

Signing out

The Session component allows a user to sign out of their session.

Sign out">

Sign out

Page restriction

The Session component allows the restriction of a page or layout by allowing only signed in users, only guests or no restriction. This example shows how to restrict a page to users only:

title = "Restricted page"
url = "/users-only"

[session]
security = "user"
redirect = "home"

The security property can be user, guest or all. The redirect property refers to a page name to redirect to when access is restricted.

Route restriction

Access to routes can be restricted by applying the AuthMiddleware.

Route::group(['middleware' => 'RainLab\User\Classes\AuthMiddleware'], function () {
    // All routes here will require authentication
});

Account component

The account component provides a user sign in form, registration form, activation form and update form. To display the form:

title = "Account"
url = "/account/:code?"

[account]
redirect = "home"
paramCode = "code"
==
{% component 'account' %}

If the user is logged out, this will display a sign in and registration form. Otherwise, it will display an update form. The redirect property is the page name to redirect to after the submit process is complete. The paramCode is the URL routing code used for activating the user, only used if the feature is enabled.

Reset Password component

The reset password component allows a user to reset their password if they have forgotten it.

title = "Forgotten your password?"
url = "/forgot-password/:code?"

[resetPassword]
paramCode = "code"
==
{% component 'resetPassword' %}

This will display the initial restoration request form and also the password reset form used after the verification email has been received by the user. The paramCode is the URL routing code used for resetting the password.

Using a login name

By default the User plugin will use the email address as the login name. To switch to using a user defined login name, navigate to the backend under System > Users > User Settings and change the Login attribute under the Sign in tab to be Username. Then simply ask for a username upon registration by adding the username field:

Full Name Email Username Password ">


    Full Name
    

    Email
    

    Username
    

    Password

We can add any other additional fields here too, such as phone, company, etc.

Password length requirements

By default, the User plugin requires a minimum password length of 8 characters for all users when registering or changing their password. You can change this length requirement by going to backend and navigating to System > Users > User Settings. Inside the Registration tab, a Minimum password length field is provided, allowing you to increase or decrease this limit to your preferred length.

Error handling

Flash messages

This plugin makes use of October's Flash API. In order to display the error messages, you need to place the following snippet in your layout or page.

{% endflash %}">

{% flash %}
    {{ message }}
{% endflash %}

AJAX errors

The User plugin displays AJAX error messages in a simple alert()-box by default. However, this might scare non-technical users. You can change the default behavior of an AJAX error from displaying an alert() message, like this:

Checking if a login name is already taken

Here is a simple example of how you can quickly check if an email address / username is available in your registration forms. First, inside the page code, define the following AJAX handler to check the login name, here we are using the email address:

public function onCheckEmail()
{
    return ['isTaken' => Auth::findUserByLogin(post('email')) ? 1 : 0];
}

For the email input we use the data-request and data-track-input attributes to call the onCheckEmail handler any time the field is updated. The data-request-success attribute will call some jQuery code to toggle the alert box.

Email address


    Email address
    



    Sorry, that login name is already taken.

Overriding functionality

Here is how you would override the onSignin() handler to log any error messages. Inside the page code, define this method:

function onSignin()
{
    try {
        return $this->account->onSignin();
    }
    catch (Exception $ex) {
        Log::error($ex);
    }
}

Here the local handler method will take priority over the account component's event handler. Then we simply inherit the logic by calling the parent handler manually, via the component object ($this->account).

Auth facade

There is an Auth facade you may use for common tasks, it primarily inherits the October\Rain\Auth\Manager class for functionality.

You may use Auth::register to register an account:

$user = Auth::register([
    'name' => 'Some User',
    'email' => '[email protected]',
    'password' => 'changeme',
    'password_confirmation' => 'changeme',
]);

The second argument can specify if the account should be automatically activated:

// Auto activate this user
$user = Auth::register([...], true);

The Auth::check method is a quick way to check if the user is signed in.

// Returns true if signed in.
$loggedIn = Auth::check();

To return the user model that is signed in, use Auth::getUser instead.

// Returns the signed in user
$user = Auth::getUser();

You may authenticate a user by providing their login and password with Auth::authenticate.

// Authenticate user by credentials
$user = Auth::authenticate([
    'login' => post('login'),
    'password' => post('password')
]);

The second argument is used to store a non-expire cookie for the user.

$user = Auth::authenticate([...], true);

You can also authenticate as a user simply by passing the user model along with Auth::login.

// Sign in as a specific user
Auth::login($user);

The second argument is the same.

// Sign in and remember the user
Auth::login($user, true);

You may look up a user by their login name using the Auth::findUserByLogin method.

$user = Auth::findUserByLogin('[email protected]');

Guest users

Creating a guest user allows the registration process to be deferred. For example, making a purchase without needing to register first. Guest users are not able to sign in and will be added to the user group with the code guest.

Use the Auth::registerGuest method to create a guest user, it will return a user object and can be called multiple times. The unique identifier is the email address, which is a required field.

$user = Auth::registerGuest(['email' => '[email protected]']);

When a user registers with the same email address using the Auth::register method, they will inherit the existing guest user account.

'[email protected]', 'password' => 'changeme', 'password_confirmation' => 'changeme', ]);">

// This will not throw an "Email already taken" error
$user = Auth::register([
    'email' => '[email protected]',
    'password' => 'changeme',
    'password_confirmation' => 'changeme',
]);

Important: If you are using guest accounts, it is important to disable sensitive functionality for user accounts that are not verified, since it may be possible for anyone to inherit a guest account.

You may also convert a guest to a registered user with the convertToRegistered method. This will generate a random password and sends an invitation using the rainlab.user::mail.invite template.

$user->convertToRegistered();

To disable the notification and password reset, pass the first argument as false.

$user->convertToRegistered(false);

Events

This plugin will fire some global events that can be useful for interacting with other plugins.

rainlab.user.beforeRegister: Before the user's registration is processed. Passed the $data variable by reference to enable direct modifications to the $data provided to the Auth::register() method.
rainlab.user.register: The user has successfully registered. Passed the $user object and the submitted $data variable.
rainlab.user.beforeAuthenticate: Before the user is attempting to authenticate using the Account component.
rainlab.user.login: The user has successfully signed in.
rainlab.user.logout: The user has successfully signed out.
rainlab.user.deactivate: The user has opted-out of the site by deactivating their account. This should be used to disable any content the user may want removed.
rainlab.user.reactivate: The user has reactivated their own account by signing back in. This should revive the users content on the site.
rainlab.user.getNotificationVars: Fires when sending a user notification to enable passing more variables to the email templates. Passes the $user model the template will be for.
rainlab.user.view.extendListToolbar: Fires when the user listing page's toolbar is rendered.
rainlab.user.view.extendPreviewToolbar: Fires when the user preview page's toolbar is rendered.

Here is an example of hooking an event:

Event::listen('rainlab.user.deactivate', function($user) {
    // Hide all posts by the user
});

A common requirement is to adapt another to a legacy authentication system. In the example below, the WordPressLogin::check method would check the user password using an alternative hashing method, and if successful, update to the new one used by October.

Event::listen('rainlab.user.beforeAuthenticate', function($component, $credentials) {
    $login = array_get($credentials, 'login');
    $password = array_get($credentials, 'password');

    /*
     * No such user exists
     */
    if (!$user = Auth::findUserByLogin($login)) {
        return;
    }

    /*
     * The user is logging in with their old WordPress account
     * for the first time. Rehash their password using the new
     * October system.
     */
    if (WordPressLogin::check($user->password, $password)) {
        $user->password = $user->password_confirmation = $password;
        $user->forceSave();
    }
});

Comments

how to change user groups in octobercms automatically after payment
Hi, I am using "user plugin". In my website I have some paid content pages. The pages are accessible to only those users who belong to user-group -"paid". I want to change the user group of users to "paid" automatically, once they make the payment. Presently the only way its working is

I manually set a user as 'paid' in the backend.

I check the if the user is in paid group by- {% if user.groups[0].id == 3 %}

So the user whom I set as paid gets the access, the rest of the users don't.

But i am seeking answer to make it automatic once the payment is done. How can i achieve this. Thanks in advance.

Type: Question
opened by Mins17 30
Backend login redirects to front end login

When I try to login into the backend while not being logged in i the front end. I, after having entered the backend login information, gets redirected to the front end login form. Anyone else experienced this?

Expected behavior

If I'm not logged in via the Rainlab.User plugin and tries to login to the backend I expect to get redirected to the dashboard upon login.

Actual behavior

I get redirected to /favicon.ico instead. But if I first login into the frontend, this all works.

Reproduce steps

Install Rainlab.User, do not log in, visit the backend login, login.
Status: Review Needed Type: Unconfirmed Bug

opened by Hambern 26
isImpersonator() method not working properly
\Auth::isImpersonator() return false when impersonating a user ( and you are not already logged in as a frontend user )

Steps to reproduce: ( Best is to do it in incognito mode to be sure we are in a clean state )

Login as a backend user

Impersonate a frontend user

\Auth::isImpersonator() return false

Expected behaviour:

\Auth::isImpersonator() return true after impersonating a frontend user

I think it happens because if you call the \Auth::impersonate method and your are not already logged as a frontend user, the user_auth_impersonate session var will be stored as null so it will not be considered as set and consequently the isImpersonator() will return false.
Status: Completed Type: Bug
opened by KGE 24
Provide frontend translations ?

I know that frontend translations are normally defined in the theme files (with the Translate plugin), however I think translating the different frontend forms and mails is something that many october users will do when starting a new project, and it is time consuming.

It would be great and reaaally time-saving to have a localized user plugin "out of the box" (just like the backend is).

Couldn't backend translation system be used as well for frontend localization ? (Backend translations can be accessed in frontend with the |trans Twig function)

Alternatively, the Translate plugin could be refactored to support frontend localizations provided by plugins and overridable by themes).
Status: Review Needed Type: Conceptual Enhancement

opened by aurelien-roy 19
Update user's group

Hey,

Didnt find a way to update user's group (to add to a group)

$user = new User; $user->group = 'AAA'; $user->save();

Not working. Please advice? didnt find it in docs and in the code.

Thanks
Type: Question

opened by bbrandtlv 18
Translation issues

This is weird, im using Spanish lang, in my config/app.php my locale is "ES" 'locale' => 'es'

But all errors are displaying English...

Any idea?

Thanks
Status: Completed Type: Bug

opened by Asinox 16
Validation error: "The password confirmation does not match."
OctoberCMS Build: 458 PHP Version: 7.2.11-x64 Database Engine: MySQL Plugins Installed: RainLab.User

Hi everyone, I just updated my instance, and now, when I try to seed users (as I always managed to do before today), I get this error:

[October\Rain\Database\ModelException] The password confirmation does not match.

I'm reading rows from a CSV to import the users, this is the way I seed them:

$newUser = new User; $newUser->name = $data[1]; $newUser->email = $data[3]; $password = 'password'; $newUser->password = $password; $newUser->password_confirmation = $password; $newUser->is_activated = true; $newUser->is_guest = false; $newUser->is_superuser = false; $newUser->save();

Do you know how to solve this problem? Thanks in advance!
Type: Question Status: Testing Needed
opened by alessiovietri 15
[Bug?] Page restriction redirect

If you set a page restriction on a page to users then set the redirect to maybe /error.htm or error, if you are logged into the CMS this works fine, but as soon as you log out of the CMS and navigate to the same page, it instead redirects you to the login page of the CMS?

opened by DanielHitchen 15
is_activated doesn't necessarily mean that the email is verified
Problem

Users can change their e-mail and have their account is still marked "activated" Here is how:

User creates an account with a first mail address

User activates its account, via the link sent to its e-mail. The account is now activated.

User then changes its e-mail address (note that it is possible even if the website do not allow e-mail change via its account update form, because the onUpdate AJAX endpoint is exposed and allows the user change almost every property from a POST request)

The user now has a new e-mail, but the account is still marked as activated.

Why this is an issue

This is harmless for most websites, where the main purpose of activation is just to make sure that user didn't made a typo in its address. But a secondary usage of activation is to have a guarantee (from a security perspective) that user is the owner of the e-mail address he gave.

I myself got tricked while developing a authentification plugin on top of RainLab User, because I assumed that every activated account are associated with a verified e-mail (which I think is a reasonable assumption). I find it's counterintuitive that it's not, and could both mislead website owners and create potential security flaws.

Possible solutions

Now, I am willing to make a PR that solves this issue. But I see 3 possible solutions, and wanted to discuss what would be the best:

Solution 1: De-activate the account when e-mail is changed by setting NULL the "activated_at" and "is_activated" fields when e-mail is changed. If activation is required to log in into the website, user is logged out until they activate their account again. A new activation mail will be sent to the user to the new e-mail he has provided.

Solution 2: Have two fields in the user model: email and unverifiedEmail. When the user changes its e-mail via the onUpdate field, only the "unverifiedEmail" field is changed and a new activation link will be sent. Clicking on this link will set the email field equals to unverifiedEmail. In this solution, user account is never de-activated, however, this solution will guarantee that "email" field always contain a verified e-mail address.

Solution 3: Secure the onUpdate endpoint to deny e-mail change by default. The way that could be used is to add a property to the Account component listing every overridable fields. Let say something like "name,email,phone". When the onUpdate endpoint is called, only those fields will be overwritable. Now this doesn't totally solve the activation issue, but it will secures website that do not expect users to change their e-mail, forcing developers to knowledgly enable e-mail change and then deal with activation handling however they want. Note that solution 3 is a breaking change.

My opinion: I would go for 1 or 2. But I think 3 should be considered as well (in addition to 1 or 2), because it gives control on the field that can and cannot be edited.
Type: Question
opened by aurelien-roy 13
How to prevent guest users from resetting their password and make them re-direct back to the initial page after log in?

Hi,

Facing issues with the problem I described above, and would not really know where to start in modifying this part of the plugin.. Is there a way for preventing guest users from changing their password? I was thinking about simply re-directing these users (after they logged in) to the page it was set initially (such as the home page), so they won't even enter the "modify login" page, but don't really know how to... If there's anyone who could help me out on this, is really appreciated!

Thank you in advance!

Greetings, Nathalia
Type: Question

opened by NMorgana 12
first round of tests

more or less just scaffolding a test environment, and wiring it up with travis-ci.

@daftspunk or @LukeTowers when this is merged, I might need one of you to help setup the travis webhook for this repo
Status: Completed Type: Enhancement

opened by scottbedard 12
User Group Filter
Good day Team, I'm trying to display specific data for users in a user group, I found the code below on a forum post from 2 years ago but it doesn't seem to work now.

<div> <strong>Test Group</strong> {% for group in user.groups %} {% if group.name == 'development' %} <p>u are development user</p> {% endif %} {% endfor %} </div>

Can you help me with the correct code please?
opened by NielsvandenDries 0

Releases(v1.6.0)

v1.6.0(Aug 19, 2021)

This version (1.6) release signifies the beginning of support with October CMS v2.0. All changes should remain compatible with v1.0 in this release. Otherwise, this plugin will get bumped to v2.0 as well.

Enjoy!
Source code(tar.gz)
Source code(zip)
v1.5.4(Oct 7, 2020)
Changes

Users can now be unsuspended from the preview page when viewing a user. (https://github.com/rainlab/user-plugin/pull/430)

A confirmation message is now shown on registration if administrators must approve new registrations. (https://github.com/rainlab/user-plugin/pull/429)

The User plugin now uses GitHub Actions for testing. (https://github.com/rainlab/user-plugin/pull/446)

Bug fixes

The User model no longer uses guarded attributes (https://github.com/rainlab/user-plugin/pull/434). Fixes https://github.com/rainlab/userplus-plugin/issues/34.

Translation updates

Added Taiwanese translations. (https://github.com/rainlab/user-plugin/pull/454)

Added Slovenian translations. (https://github.com/rainlab/user-plugin/pull/431)

Updated Russian translations. (https://github.com/rainlab/user-plugin/pull/450)

Updated Turkish translations. (https://github.com/rainlab/user-plugin/pull/445)

Updated Dutch translations. (https://github.com/rainlab/user-plugin/pull/439)

Updated Spanish translations. (https://github.com/rainlab/user-plugin/pull/425)

For more information on this release, please review the milestone: https://github.com/rainlab/user-plugin/milestone/5?closed=1
Source code(tar.gz)
Source code(zip)
v1.5.3(Jan 10, 2020)
Changes

Users who have been banned are now highlighted in red in the Users list. (https://github.com/rainlab/user-plugin/pull/404)

The registration component now uses the same validation rules that are specified with the User model, as opposed to its own custom set of validation rules. (7307e999d1540103776bf2f7e0e98f3641023df1)

Bug fixes

Fixed an issue where the user update was prevented by a missing password index error if no password is provided. This occurred in setups where people allow users to change profile details without a "change password" field. (https://github.com/rainlab/user-plugin/pull/420)

Translation updates

Improved Indonesian translations. (https://github.com/rainlab/user-plugin/pull/405)

Improved Hungarian translations. (https://github.com/rainlab/user-plugin/pull/408)

For more information on this release, please review the milestone: https://github.com/rainlab/user-plugin/milestone/4?closed=1
Source code(tar.gz)
Source code(zip)
v1.5.2(Sep 13, 2019)
Changes

The username of the user is now available to be added to the Reset Password mail templates. This must be added to the template manually. (#403)

Bug Fixes

Whitespace from the start and end of usernames is now stripped on the login form. This fixes login issues for people who mistakenly put in spacing at login, eg. copying and pasting a username. (#399)

For more information about this release, please review the milestone: https://github.com/rainlab/user-plugin/milestone/3?closed=1
Source code(tar.gz)
Source code(zip)
v1.5.1(Sep 1, 2019)
New Features

Registration throttling functionality has been implemented, limiting registrations to 3 per hour per IP address. You can enable it via the User Settings administration panel. (#397)

User logins can now be remembered, allowing people to stay logged in for extended periods of time. This too is controlled in the User Settings administration panel. (#312)

Changes

Added a new Account component setting to require the user to enter in their current password when changing their account information. (#303, https://github.com/rainlab/user-plugin/commit/49dfee228d3cefe824de4e30d9e55b6902120cbe)

Updated Russian translations. (#394)

Bug Fixes

Fixed an issue where the wrong password validation message was shown when updating a user. (#371, https://github.com/octobercms/october/commit/610e0c383cbf92f17def3ce64ddd59c1204f1eff)

For more information about this release, please review the milestone: https://github.com/rainlab/user-plugin/milestone/2?closed=1
Source code(tar.gz)
Source code(zip)
v1.5.0(Jun 22, 2019)
Breaking Changes

To improve the security of this plugin, user passwords must now be at least 8 characters by default. This is configurable by the admin (see below). This change does not affect current passwords, which will continue to work. (#354)

New Features

The minimum length of passwords is now configurable via the User settings screen in the Backend. By default this is set to 8 characters. (#354)

Changes

The CSRF token is now inserted to the default User component templates. (#388)

Bug Fixes

The "no redirect" and "refresh page" options for the Redirect property in the User Component should now work correctly. (https://github.com/rainlab/user-plugin/commit/ba27e63dd2738ffe3788da8e5a69b85dfcfd6e52)

Fixed issue where users could not be reactivated by an admin after being deactivated. (https://github.com/rainlab/user-plugin/commit/9edc9556b0e14aa1d44072b3f9ecd7a3ef6fb8ab)

For more information about this release, please review the milestone: https://github.com/rainlab/user-plugin/milestone/1?closed=1
Source code(tar.gz)
Source code(zip)