PHP download

Download the PHP package remp/crm-users-module without Composer

On this page you can find all versions of the php package remp/crm-users-module. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

Table of contents
Download remp/crm-users-module
More information about remp/crm-users-module
Files in remp/crm-users-module

Vendor remp
Package crm-users-module
Short Description CRM Users Module
License MIT
Homepage https://remp2030.com

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?

Example code of remp/crm-users-module

Informations about the package crm-users-module

CRM Users Module

This documentation describes API handlers and CLI commands provided by this module for others to use. It expects your application is based on the CRM skeleton provided by us.

Installing module

We recommend using Composer for installation and update management.

Enabling module

Add installed extension to your app/config/config.neon file.

Generate ACL

User access resources are used to control access rights of admin groups in CRM admin. These resources are generated from methods render*, action*, handle* of all presenters extending Crm\AdminModule\Presenters\AdminPresenter.

To generate run command:

This command should be run everytime new version is released to validate & generate new resources.

All new resources are automatically assigned to superadmin admin group - check seeder Crm\UsersModule\Seeders\UsersSeeder.

Other admin groups are not affected. New resources have to be assigned either manually via admin interface (http://crm.press/users/admin-group-admin/show/1) or seeded within your module.

ACL - `admin-access-level`

These annotations are optional and do not affect resolving access rights to resource.

To ease assigning of access rights to admin groups (http://crm.press/users/admin-group-admin/show/1), level of access resource can be specified as method annotation admin-access-level. CRM uses now two levels read and write. Level write indicates that this method can be used to create, update or remove entity. Rest of resources has level read.

Example:

If annotation admin-access-level is missing, no level is displayed on page where resources/right are assigned to admin groups (http://crm.press/users/admin-group-admin/show/1).

Cleanup

Command has also cleanup option:

After resources are generated, it will compare current ACL resources and actions with previous state. Orphaned ACL resources will be removed from database. Useful when module is uninstalled or admin presenter / action is removed.

WARNING: This option doesn't fix ACL after resource is moved. That should be handled by module when resource is moved / renamed (eg. by migration).

Single sign-on

Google Sign-In

Users module supports Google Sign-In authentication using the Authorization code flow and ID token.

Configuration

Any application that uses Google Sign-In must have authorization credentials that identify the application to Google's OAuth 2.0 server. To set up credentials, please go to Google Credentials page.

After acquiring credentials, put them to neon configuration file using the following format:

Last step is to enable Google Sign-In in CRM settings in /admin/config-admin/ Authentication section.

ID Token

ID Token is a Google-signed JWT token holding user information (see the documentation). This module provides an API endpoint to validate the token and match it to an existing user (or create a new one) using user's email address.

Authorization code flow

Standard OAuth2 Authorization code flow is initiated when user is redirected to http://crm.press/users/google/sign URL.

An optional parameter is url, which is a URL to redirect to after the successful login. url is validated against current CRM domain - url has to share at least the second level domain, e.g. if your CRM is available at crm.yoursystem.com, any domain passing *.yoursystem.com will be considered as a valid redirect URI.

Example

HTML button to initiate Google Sign-In:

Apple Sign-In

Users module supports Apple Sign-In authentication using the Authorization code flow and ID token.

Configuration

Any application that uses Apple Sign-In must have authorization credentials that identify the application to Apple. For more information, please go to Apple Get started page.

After acquiring credentials, put them to neon configuration file using the following format:

Last step is to enable Apple Sign-In in CRM settings in /admin/config-admin/ Authentication section.

ID Token

ID Token is a Apple-signed JWT token holding user information. This module provides an API endpoint to validate the token and match it to an existing user (or create a new one) using user's email address.

Authorization code flow

Standard OAuth2 Authorization code flow is initiated when user is redirected to http://crm.press/users/apple/sign URL.

Example

HTML button to initiate Apple Sign-In:

Allow domains in url redirect

To enable more domains in url redirect, please add the following configuration to your configuration neon file:

Secured admin login

Required Google Sign-In

To enhance security, one may require all users with admin role to log-in using Google Sign-In, if they want to access admin interface. User verification security then relies on Google security mechanisms to identify potential abuse.

To turn on this option (called "Secured login"):

Register following event handler to one of your internal modules so the sign-in process correctly flags the source of sign-in (e.g. Google) secure:
- If you want more control or different level of security, create your own SecureAccessSignInEventHandler and implement your custom rules.
Check Authentication section of CRM admin settings and enable Secured login.
After enabling the option, each such user has to be acknowledged by adding secure_login_allowed flag to user_meta table.

Two-factor authentication

Currently, 2FA authentication is not implemented.

Data retention configuration

You can configure time before which application:cleanup deletes old repository data and column which it uses by using (in your project configuration file):

AccessTokenAuthenticator

UsersModule generates an access token for every successful user authentication. This token can be used to authenticate the user in API calls.

You can log the user into the CRM automatically if you have such token thanks to the AccessTokenAuthenticator.

How to use

CRM checks if there's a cookie called n_token and extracts the value from it. If the value is valid access token (it's still present in the access_tokens table), and it doesn't belong to admin account, it logs user in automatically without requesting username or password.

This comes handy in case your login process is handled on other domain (e.g. in your CMS via CRM's API) and you want your users to get logged in only once.

Events

NewUserEvent

NewUserEvent is emitted for all types of new users created - both regular (claimed) and unclaimed.

UserRegisteredEvent

UserRegisteredEvent is emitted when a regular user is created through UserBuilder. Unclaimed user is not considered to be a regular user.

If you call UsersRepository::add directly in your own extension and it's a regular user, make sure you emit UserRegisteredEvent at the end of the process.

UserCreatedEvent

UserCreatedEvent used to be an event emitted during user registration. This is now deprecated. Use UserRegisteredEvent and possibly NewUserEvent instead.

API documentation

All examples use http://crm.press as a base domain. Please change the host to the one you use before executing the examples.

All examples use XXX as a default value for authorization token, please replace it with the real tokens:

API tokens. Standard API keys for server-server communication. It identifies the calling application as a whole. They can be generated in CRM Admin (/api/api-tokens-admin/) and each API key has to be whitelisted to access specific API endpoints. By default the API key has access to no endpoint.
User tokens. Generated for each user during the login process, token identify single user when communicating between different parts of the system. The token can be read:
- From n_token cookie if the user was logged in via CRM.
- From the response of /api/v1/users/login endpoint - you're free to store the response into your own cookie/local storage/session.

API responses can contain following HTTP codes:

Value	Description
200 OK	Successful response, default value
400 Bad Request	Invalid request (missing required parameters)
403 Forbidden	The authorization failed (provided token was not valid)
404 Not found	Referenced resource wasn't found

If possible, the response includes application/json encoded payload with message explaining the error further.

GET `/api/v1/user/info`

API call returns basic user information and meta information, based on provided user token.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	User token.

Example:

Response:

This was a response from default UserAuthenticator. If your application use some custom implementation of authenticator (e.g. FooAuthenticator), the authenticator can add extra parameters to the response:

POST `/api/v1/users/login`

API call verifies provided credentials and returns user token.

Params:

Name	Value	Required	Description
Email	String	yes	User's email address.
Password	String	yes	User's plain text password.
Source	String	no	Source of the login indicating which implementation of UserAuthenticator to verify credentials. The caller is responsible for providing source of the credentials so the handler know which implementation can handle the verification.
device_token	String	no	Token used for pairing mobile device to users access tokens. Can be generated by `users/get-device-token`.

Example:

Success response:

Invalid credentials response:

POST `/api/v1/users/logout`

API call that logs out the authenticated user. If user is authenticated using device token, all associated access tokens are removed too.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	Access token or device token

Example:

Success response:

POST `/api/v1/users/email` (DEPRECATED: Use `/api/v2/users/email` instead.)

API calls checks whether provided email address is valid and available to use (for possible registration).

Additionally it checks whether the provided password is valid for given email address or not. It doesn't login the user into the system and it also doesn't return any user token, it only verifies the password if it was provided.

Params:

Name	Value	Required	Description
Email	String	yes	Email to verify
Password	String	no	Password to verify

Example:

Response when email is already taken:

Response when email is available:

POST `/api/v2/users/email`

API calls checks whether provided email address is valid and available to use (for possible registration).

Params:

Name	Value	Required	Description
Email	String	yes	Email to verify
Password	String	no	Password to verify

Example:

Response when email is already taken:

Response when email is available:

POST `/api/v1/users/email-check`

API call checks whether provided email address is valid and available to use (for possible registration).

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token

Params:

Name	Value	Required	Description
Email	String	yes	Email to verify

Example:

Response when email is already taken:

Response when email is available:

POST `/api/v1/users/create`

API for registration of user into the system. Password is generated automatically by the system and sent to user by email.

When the user is registered, he/she is automatically logged in and user token is also returned.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token

Params:

Name	Value	Required	Description
email	String	yes	-
password	String	no	-
first_name	String	no	-
last_name	String	no	-
ext_id	Integer	no	User identificator from external system
source	String	no	Source of user registration - string label groupping users registered via the same source.
referer	String	no	Referer URL to indicate where user got registered.
note	String	no	Note visible only to administrators
send_email	String	no	Flag whether to send welcome email after the registration. If not provided, the system will send an email.
disable_email_validation	Boolean	no	Flag whether to bypass email address validation. If not provided, the system will validate email address.
device_token	String	no	Token used for pairing mobile device to users access tokens. Can be generated by `users/get-device-token`.
unclaimed	Boolean	no	Flag whether to create unclaimed user. If not provided, standard user will be created.
newsletters_subscribe	Boolean	no	Flag whether to subscribe registered user to newsletters.
locale	String	no	User locale.

Example:

Success response:

POST `/api/v1/users/update`

API for updating user info.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token

Params:

Name	Value	Required	Description
user_id	String	yes	ID of the user to update
email	String	no	-
password	String	no	-
ext_id	Integer	no	User identificator from external system
disable_email_validation	Boolean	no	Flag whether to bypass email address validation. If not provided, the system will validate email address.
locale	String	no	User locale.

Example:

Success response:

GET `/api/v1/users/add-to-group`

Adds user to the provided group. Group serves for artificial user groupping based on your arbitrary criteria.

You can list your available groups in CRM admin at /users/groups-admin/.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
email	String	yes	Email to add to user group.
group_id	Integer	yes	ID of user group to be used.

Example:

Response:

GET `/api/v1/users/remove-from-group`

Removes the user from selected group. Group serves for artificial user groupping based on your arbitrary criteria.

You can list your available groups in CRM admin at /users/groups-admin/.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
email	String	yes	Email to remove from group.
group_id	Integer	yes	ID of user group to be removed from.

Example:

Response:

GET `/api/v1/users/addresses`

Lists all user addresses. User is identified by email address.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
email	String	yes	User email.
type	String	no	Type of address - types of addresses are managed by modules (e.g. `InvoiceModule` adds support for `invoice` address type.

Example:

Response:

POST `/api/v1/users/address`

Creates new address for given user.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
email	String	yes	User email.
type	String	yes	Type of address - types of addresses are managed by modules (e.g. `InvoiceModule` adds support for `invoice` address type.
first_name	String	no	First name.
last_name	String	no	Last name.
address	String	no	Street name.
number	String	no	Street number.
zip	String	no	ZIP code.
city	String	no	City.
country_iso	String	no	Country ISO 3166-1 alpha-2 code. Default country is used if not provided
company_name	String	no	Name of the company (if it's corporate address)
company_id	String	no	ID of company (if it's corporate address)
tax_id	String	no	Tax ID of company (if it's corporate address)
vat_id	String	no	VAT ID of company (if it's corporate address)
phone_number	String	no	Phone number.

Example:

Response:

GET `/api/v1/user/addresses`

Lists all user's own addresses. User is identified from provided user token.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	User token.

Params:

Name	Value	Required	Description
type	String	no	Type of address - types of addresses are managed by modules (e.g. `InvoiceModule` adds support for `invoice` address type.

Example:

Response:

POST `/api/v1/users/change-address-request`

Creates new address change request for given type of address and user. Change request might still need to be approved. You should check if the address with given type exists before calling this - if not, create the address first via users/address API call.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
email	String	yes	User email.
type	String	yes	Type of address - types of addresses are managed by modules (e.g. `InvoiceModule` adds support for `invoice` address type.
first_name	String	no	First name.
company_name	String	no	Name of the company (if it's corporate address)
last_name	String	no	Last name.
address	String	no	Street name.
number	String	no	Street number.
zip	String	no	ZIP code.
city	String	no	City.
country_iso	String	no	Country ISO 3166-1 alpha-2 code. Default country is used if not provided
country_id	String	no	Deprecated and will be removed. Replaced with `country_iso`.
phone_number	String	no	Phone number.
company_id	String	no	ID of company (if it's corporate address)
company_tax_id	String	no	Tax ID of company (if it's corporate address)
company_vat_id	String	no	VAT ID of company (if it's corporate address)

Example:

Response:

If the address with given type doesn't exist yet, HTTP 400 is returned with following message:

POST `/api/v1/users/list`

Lists information of requested users (identified by user IDs). Endpoint requires pagination parameter to be included and paginates the result by 1000 users in one response.

Anonymized users are excluded from list. Deactivated users can be included by using include_deactivated flag.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
user_ids	String	yes	JSON-encoded array of requested user IDs.
page	Integer	yes	Page number to retrieve (starting with 1).
include_deactivated	Boolean	no	Flag indicating that deactivated users should be listed too. Doesn't affect anonymized users - they are always excluded.

Example:

Response:

POST `/api/v1/users/confirm`

Confirms user based on given email address.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
email	String	yes	Email of user to confirm. Unconfirmed users might be deleted in the future or won't get the emails.

Example:

Response:

If the user with given email doesn't exist , HTTP 404 is returned with following code:

POST `/api/v1/user/delete`

Deletes personal data and makes an account anonymous. If the account cannot be deleted, HTTP 403 is returned.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	User token.

Example:

Response:

204: Returned when the user was deleted. No body is returned.
403: Returned when the user cannot be deleted:

GET `/api/v1/users/touch`

API call to refresh cached user's data.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	User token.

Example:

Response:

USER META INFORMATION API

The concept of meta user's information is to provide the way how to store user related data without need of the database structure changes.

Meta information for user is stored as a pair key - value and respect two rules:

One value for one key
More unique keys for one user

Public property (is_public) defines the availability of meta information for the visual components of CRM administration and the availability for other modules by data providers.

POST `/api/v1/user-meta/upsert`

Create or update the meta information for given user.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
user_id	Integer	yes	ID of user to add/update meta information.
key	String	yes	Meta information key to set.
value	String	yes	Meta information value to set.
is_public	Boolean	no	Meta information property public to set.

Example:

Response:

POST `/api/v1/user-meta/list`

Return all public meta information of specified user. You can specify meta information by using the meta information key.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	User or API token.

Params:

Name	Value	Required	Description
user_id	Integer	no	ID of user. Used only when API token is provided, otherwise user is determined from User token.
key	String	no	The meta information key of user to filter by.

Example:

Response:

POST `/api/v1/user-meta/key-users`

Return all users with specified meta information key and value.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
key	String	yes	The meta key information of user to filter by.
value	String	no	The meta value information of user to filter by.

Example:

Response:

POST `/api/v1/user-meta/delete`

Delete the meta information of user by key. You can delete the meta information of user also only with specific value.

Headers:

Name	Value	Required	Description
Authorization	Bearer String	yes	API token.

Params:

Name	Value	Required	Description
user_id	Integer	yes	The ID of user.
key	String	yes	The meta information key to delete by.
value	String	no	The meta information value to delete by.

Example:

POST `/api/v1/users/autologin-token-login`

API call verifies provided autologin token and returns user identity and token.

Params:

Name	Value	Required	Description
autologin_token	String	yes	User's autologin token.
device_token	String	yes	Device token acquired by `/api/v1/users/get-device-token`.
source	String	no	Source identifying originating client. If provided, CRM will prefix `source` with `api+` prefix; otherwise CRM will use `api` as a default value for `source`.

Example:

Success response:

Invalid token response:

POST `/api/v1/users/get-device-token`

API call generates and returns new device token based on sent device_id.

Params:

Name	Value	Required	Description
device_id	String	yes	User's device id.
access_token	String	no	Access token to pair with generated device token.

Example:

Success response:

POST `/api/v1/users/set-email-validated`

API call validates email address for user, if the user exists.

Params:

Name	Value	Required	Description
Email	String	yes	User's email address.

Example:

Success response:

Invalid request response:

Invalid email response:

Email not assigned response:

POST `/api/v1/users/set-email-invalidated`

API call invalidates email address for user, if the user exists.

Params:

Name	Value	Required	Description
Email	String	yes	User's email address.

Example:

Success response:

All other responses are the same as for /validateMail method above

POST `/api/v2/users/set-email-validated`

API call validates email addresses for users that exist.

Params:

Name	Value	Required	Description
emails	String[]	yes	Array of emails to validate.

Example:

Success response:

POST `/api/v2/users/set-email-invalidated`

API call invalidates email addresses for users that exist.

Params:

Name	Value	Required	Description
emails	String[]	yes	Array of emails to invalidate.

Example:

Success response:

POST `/api/v1/users/google-token-sign-in`

API for authentication of user using Google Sign-In with ID token, as described in https://developers.google.com/identity/sign-in/web/backend-auth. Endpoint tries to match google user to an existing user using email address. If such user does not exist, a new account is created.

Params:

Name	Value	Required	Description
id_token	String	yes	Google signed JWT token containing user data
create_access_token	Boolean	no	If true, access token for user is created
device_token	String	no	Token used for pairing mobile device to users access tokens. Can be generated by `users/get-device-token`. Use only with parameter `create_access_token=true`.
gsi_auth_code	String	no	Google auth code used for one-time exchange for credentials. Acquired credentials contain `id_token` which replaces `id_token` sent as parameter.
is_web	Boolean	no	Set to `true` if `gsi_auth_code` was retrieved from web surface using JS OAuth library. Defaults to `false`.
source	String	no	Source of user registration - string label groupping users registered via the same source.
locale	String	no	User locale.

Example:

Success response:

POST `/api/v1/users/apple-token-sign-in`

API for authentication of user using Apple Sign-In with ID token. Endpoint tries to match google user to an existing user using email address. If such user does not exist, a new account is created.

Params:

Name	Value	Required	Description
id_token	String	yes	Apple signed JWT token containing user data
create_access_token	Boolean	no	If true, access token for user is created
device_token	String	no	Token used for pairing mobile device to users access tokens. Can be generated by `users/get-device-token`. Use only with parameter `create_access_token=true`.
locale	String	no	User locale.

Example:

Success response:

Components

AddressWidget

Admin user detail address widget.

Source code

How to use

AutologinTokens

Admin user detail tokens widget.

Source code

How to use

MonthToDateUsersStatWidget

Admin dashboard single stat widget.

Source code

How to use

MonthUsersSmallBarGraphWidget

Admin users header widget.

Source code

How to use

MonthUsersStatWidget

Admin dashboard single stat widget.

Source code

How to use

ActiveRegisteredUsersStatWidget

Admin dashboard single stat widget.

Source code

How to use

TodayUsersStatWidget

Admin dashboard single stat widget.

Source code

How to use

UserActionsLog