Home › Development › Modules
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
CRITICAL SECURITY VERSION UPDATE:
https://github.com/daylightstudio/FUEL-CMS/releases/tag/1.4.13
https://github.com/daylightstudio/FUEL-CMS/releases/tag/1.4.13
Advanced Modules Links not rendered in admin if module utilises extended permisions
Hi,
I noted the bug when using v1 downloaded from github on 11th Feb 2014.
By extended permissions I mean 'module', 'module/edit', module/publish, module/create, module/delete as is possible for any simple model as outlined in the userguide and illustrated using the Pages module as an example.
An authorized user for each action however can view the page if the url is entered manually eg fuel_uri/module/model/action thus the links should be visible.
Everything's fine if the module is simple i.e not advanced requiring its own folder inside the modules folder. You simply configure the module in MY_Fuel_Modules eg the pages model:
$config['modules']['pages'] = array(
...,
'permission' => array('pages', 'create', 'edit', 'pages/upload' => 'pages/create', 'publish', 'delete'),
),
);
Fuel_Auth::has_permission($perm) is the common method called in deciding which links to render in the left pane (from nav.php view ) and whether to restrict a module action eg create, delete (from module.php controller).
From the line statement : $perm = (isset($mods[$key]) AND !is_array($mods[$key])) ? $mods[$key] : $key; , as used in nav.php, $perm defaults to the module link which in the case of an advanced module will probably be MODULE/model which the user will most probably fail authorization especially if you used the generate functionality which will have created the module permissions as MODULE, MODULE_Model, MODULE_Model/create, MODULE_Model/edit, MODULE_Model/delete, MODULE_Model/publish for each model under the module.
Thus the links not rendered.
Solution:
Changing the nav.php statement at line 31 to $perm = (isset($mods[$key])) ? $mods[$key] : $key; rectifies the bug since now $perm will be passed as an array to Fuel_Auth::has_permission() and parsed into the format above. Thus the links are renderd.
New bug: (logged in as non-admin)
Implementing the above will work as long as for every 'page' FUEL can determine the module (ie CI has the module property). Such as is the case with all routed towards module.php which determines the module from the start. Otherwise as in the case of custom controllers eg dashboard that dont specify a 'module ' property; a 'Undefined Property ' error will be thrown for each module (simple or advanced) that has extended permissions. This is so since foreach module, Fuel_Auth tries to check if its a foreign module using $this->CI->module if the $perm param passed is an array.
My work-around this is is to alter the if condition in Fuel_Auth.php at line 340 to if (!isset($this->CI->module) || (($permission[0] != $this->CI->module) AND in_array($permission[0], array_keys($this->CI->fuel->modules->get())))) {$foreign_module = $permission[0];} in case no module property was declared.
Hope I evaluated this correctly & I welcome any improvement.
I noted the bug when using v1 downloaded from github on 11th Feb 2014.
By extended permissions I mean 'module', 'module/edit', module/publish, module/create, module/delete as is possible for any simple model as outlined in the userguide and illustrated using the Pages module as an example.
An authorized user for each action however can view the page if the url is entered manually eg fuel_uri/module/model/action thus the links should be visible.
Everything's fine if the module is simple i.e not advanced requiring its own folder inside the modules folder. You simply configure the module in MY_Fuel_Modules eg the pages model:
$config['modules']['pages'] = array(
...,
'permission' => array('pages', 'create', 'edit', 'pages/upload' => 'pages/create', 'publish', 'delete'),
),
);
Fuel_Auth::has_permission($perm) is the common method called in deciding which links to render in the left pane (from nav.php view ) and whether to restrict a module action eg create, delete (from module.php controller).
From the line statement : $perm = (isset($mods[$key]) AND !is_array($mods[$key])) ? $mods[$key] : $key; , as used in nav.php, $perm defaults to the module link which in the case of an advanced module will probably be MODULE/model which the user will most probably fail authorization especially if you used the generate functionality which will have created the module permissions as MODULE, MODULE_Model, MODULE_Model/create, MODULE_Model/edit, MODULE_Model/delete, MODULE_Model/publish for each model under the module.
Thus the links not rendered.
Solution:
Changing the nav.php statement at line 31 to $perm = (isset($mods[$key])) ? $mods[$key] : $key; rectifies the bug since now $perm will be passed as an array to Fuel_Auth::has_permission() and parsed into the format above. Thus the links are renderd.
New bug: (logged in as non-admin)
Implementing the above will work as long as for every 'page' FUEL can determine the module (ie CI has the module property). Such as is the case with all routed towards module.php which determines the module from the start. Otherwise as in the case of custom controllers eg dashboard that dont specify a 'module ' property; a 'Undefined Property ' error will be thrown for each module (simple or advanced) that has extended permissions. This is so since foreach module, Fuel_Auth tries to check if its a foreign module using $this->CI->module if the $perm param passed is an array.
My work-around this is is to alter the if condition in Fuel_Auth.php at line 340 to if (!isset($this->CI->module) || (($permission[0] != $this->CI->module) AND in_array($permission[0], array_keys($this->CI->fuel->modules->get())))) {$foreign_module = $permission[0];} in case no module property was declared.
Hope I evaluated this correctly & I welcome any improvement.
Comments