Permission Library



( ZN >= 0.01 )

A hierarchy created for the regulation of access privileges to pages or objects. Configures object or page access according to the criteria in the Config file.

 

 

# Configuration


File: Config / Authorization.php
permission
Array $ method = [] Used to set data request authority.
Array $ page = [] Used to set page visit permissions.
Array $ process = [] Used to set object view permissions.

 

 

# Authority Keys


anya There is no authority.
all Full authority.
noperm Unauthorized page or objects.
perm Allowed pages or objects.

Accordingly, it is determined which id page is allowed to be given to which pages or objects. If an authority is restricted to noperm , it is authorized to do anything outside it. If an authority is restricted to perm , then there is no authority outside anything else.

 

 

# Methods


Void roleId(Int $roleId = 0)
Bool post(Void)
Bool get(Void)
Bool request(Void)
String process(String $process = NULL, String $object = NULL)
Void start(String $process = NULL)
Void end(Void)
Bool page(Void)

 

 

# RoleID ( ZN >= 5.4.4 )


It is used to define the $ roleId parameter of other methods of the Permission :: class once. Thus, in every method there is no need to specify the role id repeatedly . With this methodrole idIf the definition is made, the parameters of the other methods are replaced. That is, the third parameter is the second parameter and the second parameter is the first parameter

Parameters

scaler $ role Role value. It usually represents the value from the role column in the user tables. It determines how to restrict by which role.
return void

Use of

Especially recommended for use with the initial control. It is more accurate to define once in the initial controller instead of redefining each controller each time.

File: Controllers / start.php
<?php namespace Project\Controllers;

use Permission, User;

class Start
{
    public function main()
    {
        $user = User::data();

        Permission::roleId($user->role_id);

        if( ! Permission::page() )
        {
            redirect('home/noaccess');
        }
    }
}

 

 

# Post ( ZN >= 5.3.9 )


It authorizes which data to send with the post . For example, when a user presses the delete button, you can prevent the delete post value from being processed.

Parameters

void
return Bool

uses

Consider a configuration example as follows.

'method' =>
[
    '1' => 'all',
    '2' => ['noperm' => ['delete']],
    '3' => ['noperm' => ['add', 'update', 'delete']]
];

In the following example, the above settings are enabled according to the role id of the user.

if( ! Permission::post(User::data()->role_id) )
{
    redirect('show404');
}
For Role ID 1 : There are no restrictions.
For Role ID 2 :Post :: delete ()can not be sent.
For Role ID 3 :Post :: add () , Post :: update (), and Post :: delete () can not be sent.

 

 

# Get ( ZN >= 5.3.9 )


It authorizes which data to send with get . For example, when a user presses the delete button, you can prevent the delete get value from being processed.

Parameters

void
return Bool

uses

Consider a configuration example as follows.

'method' =>
[
    '1' => 'all',
    '2' => ['noperm' => ['delete']],
    '3' => ['noperm' => ['add', 'update', 'delete']]
];

In the following example, the above settings are enabled according to the role id of the user.

if( ! Permission::get(User::data()->role_id) )
{
    redirect('show404');
}
For Role ID 1 : There are no restrictions.
For Role ID 2 :Get :: delete ()can not be sent.
For Role ID 3 :Get :: add () , Get :: update (), and Get :: delete () can not be sent.

 

 

# Request ( ZN >= 5.3.9 )


Authorizes which data to send with post or get . For example, when a user presses the delete button, you can prevent the delete post or get value from being processed.

Parameters

void
return Bool

uses

Consider a configuration example as follows.

'method' =>
[
    '1' => 'all',
    '2' => ['noperm' => ['delete']],
    '3' => ['noperm' => ['add', 'update', 'delete']]
];

In the following example, the above settings are enabled according to the role id of the user.

if( ! Permission::request(User::data()->role_id) )
{
    redirect('show404');
}
For Role ID 1 : There are no restrictions.
For Role ID 2 :Request :: delete ()can not be sent.
For Role ID 3 :Request :: add () , Request :: update (), and Request :: delete () can not be sent.

 

 

# Process ( ZN >= 0.0.1 )


Used to determine the method of accessing objects.

Parameters

String $ process = NULL Process name.
String $ object = NULL The object to be covered.
return String

uses

I will edit the authorization settings file as follows and review it on an example.

'process' =>
[
	'1' => 'any',
	'2' => 'any',
	'3' => ['perm'   => ['update']],
	'4' => ['perm'   => ['update', 'add']],
	'5' => ['perm'   => ['update', 'add', 'delete']],
   	'6' => ['noperm' => ['edit'],
	'7' => 'all'
];

According to this;

# Rol ID 4 için;
echo Permission::process('update', Html::bold('Update Process'));
echo Permission::process('add', Html::bold('Add Process')); 
echo Permission::process('delete', Html::bold('Delete Process')); 
echo Permission::process('edit', Html::bold('Edit Process')); 
Update Process
Add Process

If you are creating view objects with Form :: and Html :: libraries, you can also do the authorization check as follows.

# Rol ID 6 için;
echo Html::perm('update')->bold('Update Process'); 
echo Html::perm('add')->bold('Add Process'); 
echo Html::perm('delete')->bold('Delete Process');
echo Html::perm('edit')->bold('Edit Process');
Update Process
Add Process
Delete Process
# Rol ID 7 için;
Update Process
Add Process
Delete Process
Edit Process

 

 

# Start ( ZN >= 3.0.4 )


It is used to control access to a code block. The code that passes through the access control is written to the beginning of the block.

Parameters

String $ process = NULL Process name.
return void

uses

Permission::start();
echo 'Allow';
Permission::end();
allow

You can also control by using the authority names specified in the Config.

Permission::start('perm4');
echo 'Allow';
Permission::end();
allow
Permission::start('perm6');
echo 'Allow';
Permission::end();
false

If the above considerations config file was according to noperm that authority did not give names appeared in perm or that of noperm gives output except for the names.

 

 

# End ( ZN >= 3.0.4 )


It is the method that finishes the access control. The access control code is placed at the end of the block.

Parameters

void
return void

uses

Permission::end();

 

 

# Page ( ZN >= 0.0.1 )


Used for paging access. It is the same logic as the use of the process () method. According to the settings in the config file to true or false return value.

Parameters

void
return Bool

uses

$roleId = 4;

if( Permission::page($roleId) === false )
{
    redirect('show404');
}

 

 

# Application ( ZN = 5.4.4 )


In this example, it is about whether the delete button in a data table can be displayed according to the role.

Configuring Settings

File: Config / IndividualStructures.php
'process' => 
[
    1 => 'all',
    2 => ['noperm' => ['delete']],
    3 => ['noperm' => ['delete', 'edit']]
]

In the above configuration , you can do all the operations with an id value of 1 , but not delete and edit only the deletion 3 which is 2 .

Use at Startup Controller

File: Controllers / start.php
<?php namespace Project\Controllers;

use Permission, User;

class Start
{
    public function main()
    {
        View::user($user = User::data());

        Permission::roleId($user->role_id);
    }
}

Use in View

File: Views / users / list.wizard.php
@foreach( $user as $data ):
  $data->username- 
  @Html::perm('edit')->anchor('users/edit'.$data->id, 'Düzenle'):-
  @Html::perm('delete')->anchor('users/delete'.$data->id, 'Sil'):<br>
@endforeach:

In the above usage Permission :: process () method, it is shown which roles can see the corresponding buttons.