Help

This application implements users and roles management and utilize Single Sign On (SSO) concept. The SSO is a term used to indicate when a pool of applications needs a centralized authentication, so that users login once and access to any application.

Implementing the single sign on concept for you application pool is quite simple, and can be done by using examples which are included to the package. The package contains simple and advanced examples how to connect your web sites and the users and roles management web site. The User Role Manager application performs users and roles management and helps to support Single Sign On (SSO) concept for your PHP applications without the need to create user management application again and again for each new web site. Also, you can use the same application and database with different domains using different configuration which can be linked to specific domain

Important: This implementation supports single sign-on approach for subdomains. The cross domain implementation is possible in the future.

The general concept is this: users are created, activated, possibly approved by admin, roles are assigned to users.

Users can self register and activate their account or admin can to do that. Users are linked to specific domain(s) and roles can be split by domain. It means that a user can have different roles in different domain(s).

The Application Terminology

The User Role Management application uses a concept of Roles, designed to give the tool owner the ability to control and define what users can and cannot do. An owner of admin application can manage roles and users and allow access to such functions as creating role, creating users, assigning roles, managing other users.

A role defines the set of tasks that a user is allowed to perform.

For instance, the role of Admin encompasses every possible task that can be performed within User Role application. On the other hand, the Blocked role prevents to sing-in or execute any another action.

Each role is given names that highlight the core functional responsibilities of the role and each role has own color, name and settings properties. The settings property is used to keep text information which can be used as configuration string for different purposes by third party applications.

Summary of Roles

  • Admins - People who care about role and user management
  • Blocked - Blocked users for some reason
  • Self Registered - Users which registered independently via public UI
  • Not Activated - Users which are not activated using notification email
  • API Users - Users which use API for some purposes
  • Self Activated - Users which activated their accounts
  • A-SocialSignIn: Users which signed in via Social Networks
  • Twitter: Users which signed in via Twitter
  • Facebook: Users which signed in via Facebook
  • Google: Users which signed in via Google
  • Yahoo: Users which signed in via Yahoo

The role names are self speaking and the meaning is pretty clear. You can add new role and use it according to your needs. Unnecessary self-made role can be deleted if there are no users whom such role is assigned. Role assigned every new created user by default can be changed by you.

An authentication and authorization is a key requirement for many web applications which you want to develop. In order to do that a user (user) should have unique e-mail and password. This area allows creating and managing users. You can create, delete, assign a role to a user, or remove users from the role and control a user action by audit log. The application allows you to create API token which gives a possibility to use application functionality in other applications which need authentication and authorization? Also, you have a possibility to export/import users via CSV file. The format of the export file is very easy to understand and will be described on FAQ page.

This page contains the list of available domains, so you can use it to restrict profile fields visibility by domains. If you created a profile fields it will be visible for all domains by default. To change that click on the field name on the Fields page and click on "Restricted By Domains" or "Restricted By Roles" tab and check domains or roles which you need. You can select a user domain on the user edit dialog or it will be assigned during sign up process. The domain name will be set for a user during signup process or you can find the user on the Users page, click on the user name and set the user domain on the Domains tab.

This implementation supports subdomain single sign-on only.

A user should be able to log in to any subdomain and be logged in to another subdomain and the root domain.

This area provides an ability to create additional fields which keeps additional information about a user like country, city, address etc. You have the posibility to group the fields and define their type: it can be simple string or collection of values. The next release will have more types like date, date range, multiple selection collection etc. Any field can be included to sign up form.

You can define a profile field visibility.

The visibility of each profile field can be restricted by domain, role, or a mission (for inatnce signup form, admin use only etc.)

This area provides an ability to track what happens for admin application. The application support the following type of audit events: System, Application, API.

  • System - describes application unhandled exception, and other system staff;
  • Application - describes the application function result (user and role creation, sign in/ sign out etc.) or action comment;
  • API - describes API method execution result or comment.

You have an ability to use this feature or switch it off. The audit log allows analyzing different type of events and provides extra information like a query string, request parameters, cookies, exception message and detail etc.

The last audit event will be always on top of event list. Each row will be collapsed if event description contains more than 80 words. Some rows will have the detail link which provides extra information about events.

This area contains a set of simple tools. Actually, at the moment, the application has only one item in this area. It is the PHP framework configuration info.

This area provides a set of options which help to adjust the application to your needs.

You have a possibility to create multiple configurations.

You have a possibility to create extra configuration as well and attach them to a domain. Each domain can have own a set of parameters.

General

  • Admin Email: The emails address of site admin;
  • Application Path: Application's absolute path;
  • Domain Name: The name of domain;
  • Auth Cookie Name: Name of cookie which will use for the authentication;
  • Audit: Enable audit functionality;
  • Secret Admin URL: Admin UI virtual path
  • Maintenance Time URL: Local or external path of maintenance page
  • Maintenance Time: Switch to the maintenance mode

User Interface

  • Application Name: The name of the application
  • Default Paging Size: The default page size for all grids

Languages

  • Public UI language: Default language for Sign In, Sign Out forms
  • Reload label files: Reload all label files and load new if exist

Outgoing Mail Server

  • SMTP Host: SMTP server host used for sending emails (e.g. smtp.domainname.com)
  • SMTP User Name: SMTP server user name used for sending emails
  • SMTP User Email: The user email for SMTP account used for sending emails
  • SMTP Password: The password for the SMTP account used for sending emails
  • SMTP Port: The port for SMTP server used for sending emails
  • SSL: Enable SSL connection between application and mail server.
  • Enable TLS connection between application and mail server.

Registration

  • Self-Registration: Enables self-registration functionality.
  • Self-Activation: Enables self-activation functionality.
  • Reset Password: Enables reset password functionality.
  • Self-Registration Roles: Add member to roles after self-registration
  • Self-Activation Roles: Add member to roles after self-activation
  • Mail Domains: Restricted mail domain list with options: Allow All (Excluding from the list) Deny All (Excluding from the list)
  • Using Google reCAPTCHA 2: Show Google reCAPTCHA, Site Key, SecretKey

Rules

  • Redirect After Sign In: Redirect members to this URL after sign in if no back link
  • Redirect After Sign Out: Redirect members to this URL after sign out if no back link
  • Blind Carbon Copy (Bcc): This is a copy of an email message sent to a recipient whose email address does not appear in the message. Action: registration, activation, changing password.
  • Add member to role if password failed: Assign role to a member if password was failed n-times. You can use built in role Blocked or use your custom role in order to be self informed.
  • And redirect to: Redirects to URL if account was blocked
  • User doesn't exist for the authentication domain: Do not authenticate a user

Social Networks


Twitter

You need to register your application with Twitter. That means you should have your production URL ready before you think to start your development. When you finished with registration, you will receive consumer key and consumer secret. These unique credentials will help your app to interact with Twitter. No big deal. And to register for new app you need to visit http://twitter.com/apps/new.

Facebook

It is recommended that users be able to authenticate with Facebook when using Socialize so as to maximize the exposure and promotion of your app. First step for Facebook is retrieve the App ID and App Secret (it is based on oAuth 2.0), so register you application on https://developers.facebook.com/apps.

The Facebook/Twitter API token are saved in the database (and updated after expiration date), so you can use that to have an access to Facebook/Twitter API.

Google and other OpenID providers

You don't need any key for those providers, so just enable or disable the possibilities.

Installation

The package contains three web applications: User Roles Manager and two example wed sites which demonstarte how to use it. Just drop content of UserRolesManager.Application to your Apache web site, run it in broswer and use installation wizard to set up all parameters. Also see more details below.

  • Subdomain Single Sign On concept support
  • Social Networks & OpenID Sign In Integration
  • Public registration form
  • Activation email
  • Change password email
  • Email templates support
  • Audit Event log
  • Mail domain restriction
  • Bootstrap Themes
  • Responsive design
  • Live user search
  • Multilingual support ready
  • Role / User import & export via CSV
  • Ability to change public form design
  • Public forms default language
  • Import/Export file example
  • User Profile
  • Custom User Profile Fields
  • Profile field visibility can be restricted by domain
  • Profile field visibility can be restricted by role
  • User Domains

Maybe useful: Simple tutorials on setting up a LAMP stack on Ubuntu 14.04 LTS and 12.04 LTS.
Another useful example: how to correctly install apache2, php5, mysql and phpmyadmin

  • PHP 5.3+
  • MySQL
  • mod_rewrite activated
  • php5-mysql, php5-curl, php5-gd

Install to localhost

Open etc/hosts file and add the following lines (for demo purpose only):

127.0.0.1 accounts.localhost.com
127.0.0.1 simple.localhost.com
127.0.0.1 advanced.localhost.com

Note: It doesn't need if you have domain with real IP address.

The application is downloadable in zip archive, within which you'll find the following directories and files, logically grouping common resources and code files. The package contains five folders with web applications:

  • UserRoleManager.Application
  • UserRoleManager.Client.Example.Simple
  • UserRoleManager.Client.Example.Advanced
  • UserRoleManager.Example.Data
  • UserRolesManager.Help
The UserRoleManager implementation is based on simple minimalistic MVC framework.

The example applications explain how to connect management application and existing web sites. The simple one explains how to get a user data and roles even you have one simple PHP page.

Step 1 — Activate mod_rewrite
Tutorials for How To Set Up mod_rewrite for Apache on Ubuntu 14.04

Step 2 — Create website folder
Create website folder and copy all files from UserRoleManager folder

Step 3 — Setting Up VirtualHost
Open the default Apache configuration file using nano or your favorite text editor add the following block: (accounts.localhost.com is used for demo purpose only)
$ sudo nano /etc/apache2/sites-enabled/000-default.conf

	
	<VirtualHost *:80>
	    ServerName accounts.localhost.com
		DocumentRoot [web site full path]
		ErrorLog [web site error log file full path]
		CustomLog  [web site custome log file full path]
		    <Directory [web site full path]>
			Require all granted
			RewriteEngine On		
			Options Indexes FollowSymLinks MultiViews 
			AllowOverride all
		    	Order allow,deny
			Allow from all
		    </Directory>
	</VirtualHost>
	
Step 4 — Edit index.php file
Inside index.php edit the ROOT definition. It should contain full path to your web site folder.

Step 5 — Execute the SQL statements
In UserRoleManager.SQL folder (for example with PHPMyAdmin) to create the demo database.

Step 6 — Edit the development database configs
Inside application/libs/Configuration/Config.php edit the database credentials and fill in your values.

Step 1 — Create example website folder
Create website folder and copy all files from UserRoleManager.Example.Client.Simple folder

Step 2 — Setting Up VirtualHost
Open the default Apache configuration file using nano or your favorite text editor add the following block: (accounts.localhost.com is used for demo purpose only)
$ sudo nano /etc/apache2/sites-enabled/000-default.conf

	
	<VirtualHost *:80>
	    ServerName simple.localhost.com
		DocumentRoot [web site full path]
		ErrorLog [web site error log file full path]
		CustomLog  [web site custome log file full path]
		    <Directory [web site full path]>
			Require all granted
			RewriteEngine On		
			Options Indexes FollowSymLinks MultiViews 
			AllowOverride all
		    	Order allow,deny
			Allow from all
		    </Directory>
	</VirtualHost>
	
div> Step 3 — Edit index.php file
Inside index.php edit the ROOT definition. It should contain full path to your web site folder.

Step 1 — Create example website folder
Create website folder and copy all files from UserRoleManager.Example.Client.Advanced folder

Step 2 — Setting Up VirtualHost
Open the default Apache configuration file using nano or your favorite text editor add the following block: (accounts.localhost.com is used for demo purpose only)
$ sudo nano /etc/apache2/sites-enabled/000-default.conf

	
	<VirtualHost *:80>
	    ServerName advanced.localhost.com
		DocumentRoot [web site full path]
		ErrorLog [web site error log file full path]
		CustomLog  [web site custome log file full path]
		    <Directory [web site full path]>
			Require all granted
			RewriteEngine On		
			Options Indexes FollowSymLinks MultiViews 
			AllowOverride all
		    	Order allow,deny
			Allow from all
		    </Directory>
	</VirtualHost>
	
Step 3 — Edit index.php file
Inside index.php edit the ROOT definition. It should contain full path to your web site folder.

Install your real domain in the database

In order to setup your real domain you showld execute the following SQL script
	
	/* Setup domain and roles to your domain  */
	START TRANSACTION;

	SET @your_domain_name = N'your_domain_name';
	INSERT INTO `domains` (`Name`, `Description`, `ThemePublic`, `ThemeAdmin`, ConfigID, `Created`, `Modified`) VALUES (@your_domain_name, N'The localhost management domain.', N'bootstrap', N'bootstrap', 0, NOW(), NULL);

	SET @your_domain_id = LAST_INSERT_ID();
	INSERT INTO `domainusers`(`UserID`, `DomainID`) SELECT UserID,@your_domain_id FROM `users`;
	INSERT INTO `domainroles` (`DomainID`,`RoleID`) SELECT @your_domain_id, RoleID FROM `roles`;
	INSERT INTO `userroles` (`UserID`,`DomainID`, `RoleID`, `Created`) VALUES (1, @your_domain_id,1, NOW());

	COMMIT;
	

© 2016 User Roles Management Tool  Version: 1.0