Jump to content

Attribute-level Security: Difference between revisions

From NusaATK
No edit summary
Line 35: Line 35:
==Using 'attrib level security' that is built into ATK==
==Using 'attrib level security' that is built into ATK==


This one is something that needs a little research added here. Here is an subset of Ivo's comments on it:
There is a feature called 'attrib level security' in atkSecurityManager,
edit config.inc.php to use it. Add the following line to config.inc.php:


''There is a feature called 'attrib level security' in atkSecurityManager, but it's ages since I last used it so I'm not sure how it works. It involves an extra table where the rights per attribute are stored.''
$config_security_attributes = true;


''You should be able to find out the details by looking at atk/security/class.auth_db.inc. It has a method for retrieving the attribute privileges. It probably has some details about the table structure.''
 
It involves an extra table where the rights per attribute are stored.
 
Create the table:
 
CREATE TABLE `attribaccess` (
  `node` varchar(200) NOT NULL default '',
  `attribute` varchar(200) NOT NULL default '',
  `mode` varchar(200) NOT NULL default '',
  `usergroup` int(10) NOT NULL default '0'
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 
Once you set config_security_attributes = true no attribute will be shown exept it is added to the attribaccess table. this is similar to the security of the nodes.
 
the attribute level security is not yet handled by the profile attribute, which handles the node level security. So you have to implement a node to handle this for your application.
 
You should be able to find out more details by looking at atk/security/class.auth_db.inc. It has a method for retrieving the attribute privileges.

Revision as of 10:21, 16 March 2007

ATK Howto: Attribute-level Security

Complexity: Advanced
Author: James Stewart

List of other Howto's

Some times you want some people to see something that another group cannot.

haslevel

A simple method is to wrap things around a haslevel check, e.g.

$securityMgr = &atkGetSecurityManager();
if ($securityMgr->haslevel(1) 
{
  //Do something
}

Using tabs

When I asked on the mailing list, Ivo gave this idea as well:

A good alternative might be to spread the attributes over multiple tabs, then add an access right that corresponds to the tabname, and setting it up like so in your constructor:

if ($this->allowed("advanced_tab")
{
  $this->add(....., "advanced");
  $this->add(....., "advanced");
}
if ($this->allowed("publication_tab")
{
  $this->add(....., "publication");
}

You will obviously want to have a look into the allowed function in the API documentation.

Using 'attrib level security' that is built into ATK

There is a feature called 'attrib level security' in atkSecurityManager, edit config.inc.php to use it. Add the following line to config.inc.php:

$config_security_attributes = true;


It involves an extra table where the rights per attribute are stored.

Create the table:

CREATE TABLE `attribaccess` (

 `node` varchar(200) NOT NULL default ,
 `attribute` varchar(200) NOT NULL default ,
 `mode` varchar(200) NOT NULL default ,
 `usergroup` int(10) NOT NULL default '0'

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Once you set config_security_attributes = true no attribute will be shown exept it is added to the attribaccess table. this is similar to the security of the nodes.

the attribute level security is not yet handled by the profile attribute, which handles the node level security. So you have to implement a node to handle this for your application.

You should be able to find out more details by looking at atk/security/class.auth_db.inc. It has a method for retrieving the attribute privileges.