Download the PHP package winter/wn-user-plugin without Composer

On this page you can find all versions of the php package winter/wn-user-plugin. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package wn-user-plugin

Frontend User plugin

Build Status MIT License

Provides frontend user management for Winter CMS. This allows you to separate out the users on the frontend of your Winter CMS website / application from the more privileged backend users that come default in Winter CMS.

Supports:

Requirements

This plugin requires either Snowboard framework or the original Ajax Framework to be included in your layout or page in order to handle form requests.

Installation

This plugin is available for installation via Composer.

After installing the plugin you will need to run the migrations and (if you are using a public folder) republish your public directory.

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:

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

When a user is first activated -- either by registration, email confirmation or administrator approval -- they are sent a welcome email. To disable the welcome email, select "Do not send a notification" from the Welcome mail template dropdown. The default message template used is winter.user::mail.welcome and you can customize this by selecting Mail > Mail Templates from the settings menu.

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:

Signing out

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

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:

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.

Account component

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

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.

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:

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 config/config.php. Inside the file, change the value of the minPasswordLength parameter to your own.

Error handling

Flash messages

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

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

NOTE: Implementing the below example may be a privacy risk as it allows unauthenticated users to query your service to see if given email addresses are signed up to your service or not.

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:

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.

Overriding functionality

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

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 Winter\Storm\Auth\Manager class for functionality.

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

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

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

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

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

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

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

The second argument is the same.

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

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.

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

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 winter.user::mail.invite template.

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

Events

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

Here is an example of hooking an event:

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 Winter CMS.


All versions of wn-user-plugin with dependencies

PHP Build Version
Package Version
Requires php Version >=7.2
composer/installers Version ~1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package winter/wn-user-plugin contains the following files

Loading the files please wait ....