Permissions

When using the default Auth_Basic authentication type, you get a bunch of basic user account infrastructure mechanisms.

Groups

Groups are what you use to define rights. Individual users are then assigned to a group in order to receive permissions on the site. Groups are not something you can define with the default web interface (yet). There are 5 defined groups, which are as follows:

1. titan - this is the super user group which always has rights to do everything. The only user assigned to this group is the first user created during site installation.
2. admin - this is a normal admin role group which may be restricted from some actions (like Delete)
3. privileged - a user with above normal rights, like a moderator
4. restricted - a normal user
5. dinner_guest - the "guest" which is not logged in

User Accounts

The Account table has minimal information in it... account_id, account_name, and external_id. Self explanatory except that external_id is not used for anything in the website, purely there for helping link accounts to some external account system to support a master/slave set of user accounts.

I have strived to use the current "best practice" approach to user security and cookie use and have come up with the following two "Auth" tables to keep track of account passwords and cookie use: auth and auth_cookie. The auth table manages authentication by keeping track of an email associated with the account along with a 60 char hash & 16 char salt of the user's password. Salts are randomly generated for each new account so that each time a password is saved or changed, a new salt is used. The auth_cookie table keeps track of cookies so that account passwords will not be stored inside the cookie but uses a large, randomly generated token instead.

Permissions

res/Permissions.php - Permission definitions can be defined here without labels and descriptions. Add your group of rights to the $namespace_keys array and then add a public class variable with the "myNamespace_keys" nomenclature. e.g. if you wanted to add a "newperm" set of rights with the specific rights of "modify", "create", "delete", "play", and "loop":

public $namespace_keys = array('auth','config','accounts','home', 'newperm',);
public $newperm_keys = array('modify','create','delete','play','loop',);

res/i18n/en/Permissions.php - Permission definitions with their labels and descriptions in the language for the folder they reside in. Change the "en" to your 2-char language identifier for languages other than English. Regions within a given language can also be used as well, such as res/i18n/en/US/Permissions.php. In this class, you would modify the $namespace variable as well as create a new variable for your $newperm. e.g. using the same example from res/Permissions.php:

public $namespace = array(
    'auth' => array('label'=>'Authorization', 'desc'=>'Authorization Rights', ),
    'config' => array('label'=>'Settings', 'desc'=>'Settings/Configuration/Preferences', ),
    'accounts' => array('label'=>'Accounts', 'desc'=>'Membership Account Rights', ),
    'newperm' => array('label'=>'My New Permissions', 'desc'=>'Long description for my new permissions.', ),
);

public $newperm = array(
    'modify' => array('label'=>'Modify A Widget', 'desc'=>'Change widget properties.', ),
    'create' => array('label'=>'Create A Widget', 'desc'=>'Define new widgets.', ),
    'delete' => array('label'=>'Delete A Widget', 'desc'=>'Remove existing widgets.', ),
    'play' => array('label'=>'Run A Widget', 'desc'=>'Activate a widget.', ),
    'loop' => array('label'=>'Run A Widget Continuously', 'desc'=>'Loop a widget forever.', ),
);

Note that these two classes and their respective array variables will be merged together; what this means is that if you define new rights only in the "res/i18n/en/Permissions.php" file, they will still be considered "defined rights" such that the website will operate on them normally. It is considered best practice, though, to define them in both places so that language dependency is not an issue.

Usage

Inside Actors, Scenes, or the Director, you can use $this->isGuest() to determine if the visitor is not logged in. Views would typically use $v->isGuest() to access it's Scene's method. Aside from that check, you would use the isAllowed($aNamespace,$aPermission,$acctInfo); method to check for specific permissions granted to the currently logged in user. $this->isAllowed('my_right_namespace','modify') is the typcial usage, with the last parameter being used only if you want to check a specific user's permission besides the one currently viewing the page.