Jump to content

Attribute-level Security: Difference between revisions

From NusaATK
No edit summary
Ncgonz (talk | contribs)
 
(2 intermediate revisions by 2 users not shown)
Line 5: Line 5:
==haslevel==
==haslevel==
A simple method is to wrap things around a haslevel check, e.g.
A simple method is to wrap things around a haslevel check, e.g.
<pre>
<syntaxhighlight lang="php">
$securityMgr = &atkGetSecurityManager();
$securityMgr = &atkGetSecurityManager();
if ($securityMgr->haslevel(1) {
if ($securityMgr->haslevel(1))
{
   //Do something
   //Do something
}
}
<pre>
</syntaxhighlight>
 
==Using tabs==
==Using tabs==
When I asked on the mailing list, Ivo gave this idea as well
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,
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
then add an access right that corresponds to the tabname, and setting it
up like so in your constructor:
up like so in your constructor:
<pre>
 
<syntaxhighlight lang="php">
if ($this->allowed("advanced_tab")
if ($this->allowed("advanced_tab")
{
{
Line 27: Line 30:
   $this->add(....., "publication");
   $this->add(....., "publication");
}
}
</pre>
</syntaxhighlight>
You will obviously want to have a look into the allowed function in the API documentation
 
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==
==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:
 
$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.


There is a feature called 'attrib level security' in
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.  
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.  


You should be able to find out the details by looking at
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.
atk/security/class.auth_db.inc. It has a method for retrieving the
attribute privileges. It probably has some details about the table
structure.

Latest revision as of 23:51, 29 November 2008

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.