Access control

Template based access control

<? if(!t_is('administrator')) a_render(403); ?>

You may have already noticed such clause in previous examples and CMSity bundled templates. It checks whether the user is an administrator - has a tag of name (slug) "administrator" and if not renders HTTP 403 error template, usually _.403.php file.

The clause uses two important functions: t_is which checks whether logged user has specified tag, and a_render that renders an action.

The objective of template level access control is to create generic, system-wide user roles within the templates having the access to particular system functions rather to the particular content (page).

So if you want to let the group of bloggers post on your blog, you may try to use following _.create.php template:

<?
  $type = true; /* Any new node's type via POST */
  /* If the user is blogger and the current node is blog... */
  if(t_is('blogger') && g('type') == 'blog')
    /* Let him create a post */
    $type = 'post';
  /* Otherwise if the user is not administrator, render access-denied */
  elseif(!t_is('administrator'))
    a_render(403);

  /* Create a new node, forcing it to the $type */
  a_new($type, array('title', 'name', 'content'), array('title', 'content'));
?>
(...)

Here any user having "Blogger" tag, mapped to "blogger" tag name (slug) internally, will be able to create new post via http://www.mysite.com/blog?create. Administrators still can add any type of subnode.

Note: Template functions expect tag names (slugs) rather than original titles

Template functions such as t_is or t_has taking tags as parameters expect a name (slug) rather than title (original text you typed in WYSIWYG UI). So if you have specified "Administrator" tag, you should lowercase it to "administrator", while for "Fancy User" you should type "fancy-user". Tip: Tag names are the ones that are passed trough URLs.

Note: a_render never returns the control to the template

You don't need to care about putting exit or return after a_render(403), since it does not return the control back to your template's code.

Tag based access control (Pro version only)

Pro version provides automatic access mechanism based on "access" node property. Unlike template based access control, tag based access control's objective is to check access to particular content (site's area) and does not need the template modifications. Tag based access modification if possible directly trough node's Edit action WYSIWYG UI.

Template developers can extend/provide tag based access control using a_tag('access') and letting "access" property be specified at a_edit and a_new functions in similar fashion as "tags" property (This functionality is provided by default with bundled templates)

Tags in "access" property are comma separated list of tag terms (unlike tag names for t_in). User must have only ONE OF the specified tags to get the access.

An example

Imagine you want to limit your subforum http://www.myserver.com/forum/beta only to betatesters. First you assign "Betatester" tag via user's Edit action to all users that are betatesters. Next you assign "Betatester" access to the subforum. And viola! Only betatesters see and have access to the betatester subforum.

If you want to let the nerds to this subforum too you may change the access to "Betatester, Nerd", which means that the user must be betatester OR nerd (does not need to be both) to get in.

Administrator has always the access

Users having "Administrator" tag have full access to any node regardless of the node's access property. This means that "Administrator" tag is (one unique) special tag for CMSity, that bypass completely automatic access checking for logged administrators. This is done in case you put invalid access to some node that lets nobody in.

Access inheritance and nesting

First of all, node access affects all of its subnodes. Which means that all subnodes of the node inherit access setting of their parents.

However the subnodes may have own access. In such case node require valid parent access + its own access. So specifying "Developer" for the subnode, and "Betatester" for the parent (as shown on the picture above), requires the user to be both developer and betatester to access the subnode.