Backend

For support of the data access class the table structure has to follow this rules:

• primary key, autoincrement
• creatorID, if right check is needed
• datetimecreated, type datetime (optional)
• clientID (optional, needed for domain_rightmode=1)
• rightgroupID (optional, needed for domain_rightmode=2)

The users are saved in k8login.

Data access can be granted for friends or followers in k8loginfriends.

Images for all tables are joined in k8references.

If you like to change this datadefinitions, copy it please in your project folder. The datadefintions in the project folder are read first and have priority.

RBAC (Role Based Access Control) assigns the user to 1 or more roles. Roles restrict or authorize the access to tables and records. This rights can only be granted by using the login with php sessions. The RBAC is implemented in the PHP data access class. The access check is activated for an object in the datadefinition by setting "rightcheck=1". In the data table the column "creatorID" is added. Comparing the creatorID with the logged in user gives the result: own record or foreign record.

By opening the website the user is assigned to the role "0:public". His userID is also 0. By login the role is replaced by the default roles of the login table: k8login.roles="3,5". The userID is set. For each object or table, for each CRUD operation (create, read, update, delete) and role an access check is implemented.

This is the data access definition in the datadefinition (masterdata.rights):

• CRUD Operation
  • Role-ID
    • Method for access check

Thanks to the roles and data access methods, you can easyly grant the rights of your CRUD operations.

Roles

The roles are defined in:

• masterdata/_init.php

Users and role membership

The initial roles are the default value in the columns array of the datadefinition "k8login". It can be changed in the user list by super user or admin.

Datadefinition / table

In the datadefinition the rights are written in:

• masterdata
  • rights

Methods

The methods are checked before or by executing the sql statement.

By each CRUD operation the data access is checked in the correspondent data access function.

masterdata/_init.php, domain_roles:

The available roles are defined in the "_init.php".

Roles by login:

Each user can get assigned to 1 or several roles. The default roles can be set in masterdata/k8login/k8login.json, property: columns / roles / mydefault in a comma separated string like "3,5".

Admin / user list:

Superuser or admin can change the user roles in the user_list.

By each CRUD operation the access rights are checked. If the operation by Create, Update or Delete is not granted, an error is returned. Reading a table can return an empty recordset, because of the missing rights.

By Read the results of the access check for Update and Delete are returned in advance like this:

• in the datadefinitition:
  • masterdata.rightuser_create: true
• by reading the recordset:
  • rightuser_update: true
  • rightuser_delete: true

To check the user right by foreign tables the table can be joined or checked by "EXISTS()":

This are the default rights in the data access class (masterdata.defaultrights=true (default)).

Rights from the datadefinition overwrite it. To allow the roles: public and member to read all records in the object, add in the datadefinition:

The access right of the table depend on another master table. In this case the master table needs to be checked for the access rights. This is declared in the datadefinition:

Link to master

The masterdatadefID declares the master datadefinition. The first right check is made by this datadefinition. The masterkey defines the colun of this table, which correspond to the master key column of the master datadefinition.

Access right: read

1. first the acces rights of the master is checked
2. The right of the master is heritated to the child by the method: 1000

Access rights: create, update, delete

1. first the right "Update" of the master is checked
2. The right of the master is heritated to the child by the method: 1000

In this example the the access for role 2 is granted to all CRUD methods. The role 3 herites the access from the master.

Allow multiple clients to use your Web App. Each table has a clientID to differentiate the data from each other. Each Client has an own admin to govern his data and user. The user registers for 1 client. For each client he needs a different email.

masterdata/_init.php:

The domain_rightmode==1 enables:

• register: selection of the client
• menu Admin: display "Clients"

Social groups are part of many social platforms like facebook and others. Properties of a social group are:

• Title
• Description
• Owner
• Members
  • Admins
  • Observers
  • Members

The example role for social groups is 30. The method to check the rights in the groups is 14. Additionally the user has to choose 1 of his groups in my Data, in which he will be active now.

The group in the example "K8 Web Kit" was not created for easy posts but for bug reporting. If this group is active, the menu entry is available.

This is an easy example for an RBAC system. To complete it, the following functions need to be added:

• users
  • group search with admission request
  • list with group membership or pending admission request
• group admins
  • list of admission request with dialog to admit or deny

masterdata/_init.php:

The domain_rightmode==2 enables:

• my data: selection of the right group
• menu Admin: display "Right groups"

bRecordReadPermission()

This function creates a clause which which determines which records are read.

bRecordUDPermission()

This function is called 2 times and creates the columns for the data access "update" and "delete":

• rightuser_update: 0/1
• rightuser_delete: 0/1

In masterdata/_init.php the variable $GLOBALS['domain_includes'] allows to include own PHP files to write your own methods:

• [RBAC_Read]:bRecordReadPermission()
• [RBAC_RUD]: bRecordUDPermission()
• [RBAC_CUD]: bRecordAccess()