Yii AuthManager schema and types

Question

I'm confused about the Yii's AuthManager in general and the schema used for DB tables.

1. The type field in the AuthItem table can be only between 0 and 2 ( Role=2, Task=1, Operation=0 ) ?
2. Could you make me an example of what I can find stored in the bizrule and data fields using the blog used in the tutorial ?
3. The userid field must be a varchar ?

This schema ( for MySQL ) generates any conflict ?

CREATE TABLE `AuthItem` (
  `name` varchar(60) NOT NULL,
  `type` tinyint(1) unsigned NOT NULL,
  `description` varchar(255),
  `bizrule` text,
  `data` text,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `AuthItemChild` (
  `parent` varchar(60) NOT NULL,
  `child` varchar(60) NOT NULL,
  PRIMARY KEY (`parent`,`child`),
  FOREIGN KEY (`parent`) REFERENCES `AuthItem` (`name`)
    ON DELETE CASCADE 
    ON UPDATE CASCADE,
  FOREIGN KEY (`child`) REFERENCES `AuthItem` (`name`)
    ON DELETE CASCADE
    ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `AuthAssignment` (
  `itemname` varchar(60) NOT NULL,
  `userid` int(10) unsigned NOT NULL,
  `bizrule` text,
  `data` text,
  PRIMARY KEY (`itemname`,`userid`),
  FOREIGN KEY (`itemname`) REFERENCES `AuthItem` (`name`)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  FOREIGN KEY (`userid`) REFERENCES `User` (`userid`)
    ON DELETE CASCADE
    ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

THANKS IN ADVANCE!

Answer 1

1. Yes type field have to be one of those values.

   0: operation, 1: task, 2: role
   

2. bizrule can be any string that holds an executable PHP code which returns false or true and ends with a semicolon. And data should be a string contains some serialized value(s), you can use them by operating $data variable in your bizrule.

3. userid field can be of any type I think, but default varchar implementation comes from here.

Answer 2

You only have three different types of authentication items; roles, tasks, and operations. The reality is that they can be treated virtually the same and the distinction is more for design than implementation. The biz rule is used to determine whether a user has access or not or in other words granularity to the permissions. For example a user might have permission to create a user, but only a basic user, not an admin. This is the kind of granularity the bizrules can give you. Spend time on the design of the roles and access and the auth implementation will be pretty straight forward. This playlist on youtube gives a better example.

http://www.youtube.com/watch?v=7fGUtvwofU8&list=PLdfhvjWV26rQBM9gUAPG1BnTrDGsReQSr