אימות משתמשים וניהול גישות

אימות וניהול גישות עבור משתמשים דרוש הם פרט הכרחי עבור עמודים אשר מוגבלים למשתמשים מסויימים. אימות משתמשים נועדה לוודא שהמשתמש שמאומת הוא אכן מי שהוא טוען שהוא. פעולה זו בדרך כלל כרוכה בהזנה של שם משתמש וסיסמא, אך יכולה לכלול דרכים נוספות כדי להציג את הזהות, כמו כרטיס חכם, טביעות אצבע, וכדומה. ניהול גישות הינה פעולה שמבררת אם המשתמש, אשר מחובר (לאחר ביצוע האימות), מורשה לתפעל משאבים מסויימים. זה בדרך כלל נקבע על ידי בירור אם אותו משתמש הוא בעל תפקיד אשר יכול לגשת לאותם משאבים.

Yii מגיעה עם מערכת אימות וניהול משתמשים מובנת אשר קלה לשימוש וניתנת להתאמה אישית לצרכים מיוחדים.

החלק המרכזי במערכת אימות המשתמשים הוא רכיב המשתמשים אשר מוגדר מראש שהינו אובייקט המיישם את הממשק IWebUser. רכיב המשתמשים מייצג את המידע הקבוע אודות זהות המשתמש הנוכחי. אנו יכולים לגשת אליו בכל מקום בעזרת Yii::app()-»user.

על ידי שימוש ברכיב המשתמשים אנו יכולים לבדוק אם משתמש מחובר או לא בעזרת CWebUser::isGuest; אנו יכולים לחבר ולנתק משתמש; אנו יכולים לבדוק אם משתמש מורשה לבצע פעולות מסויימות בעזרת קריאה ל CWebUser::checkAccess; כמו כן אנו יכולים להשיג את המזהה היחודי של המשתמש הנוכחי ומידע נוסף אודות זהות המשתמש.

1. הגדרת מחלקת זהות משתמש ¶

בכדי לזהות משתמש, אנו מגדירים מחלקת זהות משתמש אשר כוללת את לוגיקת האימות עצמה. מחלקת זהות המשתמש צריכה ליישם את הממשק IUserIdentity. מחלקות שונות ניתנות ליישום עבור גישות אימות משתמשים שונות (לדוגמא, OpenID, LDAP). התחלה טובה תיהיה על ידי הרחבה של המחלקה CUserIdentity שהינה המחלקה הבסיסית עבור אימות המשתמשים בהתבסס על שם משתמש וסיסמא.

העבודה העיקרית בהגדרת מחלקת זהות חדשה היא היישום של המתודה IUserIdentity::authenticate. מחלקת הזהות יכולה להגדיר מידע נוסף אודות זהות המשתמש שצריך להיות קבוע ונגיש במשך כל הזמן בו המשתמש נמצא באתר.

בדוגמא הבאה, אנו מאמתים את השם משתמש והסיסמא שסופקו אל מול טבלת המשתמשים הנמצאת במסד בעזרת Active Record. כמו כן אנו דורסים את המתודה getId כדי שתחזיר את המשתנה id_ המוגדר במהלך אימות המשתמש (כברירת מחדל היישום מחזיר את שם המשתמש כמזהה יחודי של המשתמש). במהלך האימות, אנו שומרים את הערך title שנשלף מהמסד בתור מידע קבוע באותו השם על ידי קריאה ל CBaseUserIdentity::setState.

class UserIdentity extends CUserIdentity
{
    private $_id;
    public function authenticate()
    {
        $record=User::model()-»findByAttributes(array('username'=»$this-»username));
        if($record===null)
            $this-»errorCode=self::ERROR_USERNAME_INVALID;
        else if($record-»password!==md5($this-»password))
            $this-»errorCode=self::ERROR_PASSWORD_INVALID;
        else
        {
            $this-»_id=$record-»id;
            $this-»setState('title', $record-»title);
            $this-»errorCode=self::ERROR_NONE;
        }
        return !$this-»errorCode;
    }
 
    public function getId()
    {
        return $this-»_id;
    }
}

הנתונים הנשמרים במידע הקבוע (על ידי קריאה ל CBaseUserIdentity::setState) יועברו ל CWebUser אשר שומר אותם באחסון קבוע, כמו לדוגמא Session. לנתונים אלו ניתן לגשת כמאפיינים של CWebUser. לדוגמא, אנו יכולים להשיג את הערך title של המשתמש הנוכחי בעזרת Yii::app()-»user-»title (אפשרות זו קיימת החל מגרסא 1.0.3. בגרסאות קודמות, אנו צריכים להשתמש ב Yii::app()-»user-»getState('title')).

» Info|מידע: כברירת מחדל, CWebUser משתמש ב Session כאחסון קבוע למידע אודות זהות המשתמש. במידה והאפשרות של התחברות עם עוגיות פעילה (על ידי הגדרת המאפיין CWebUser::allowAutoLogin ל True ), ניתן לשמור את המידע אודות זהות המשתמש בעוגיה. וודא שאינך שומר ערכים רגישים בתוך האחסון הקבוע של זהות המשתמש (לדוגמא סיסמא).

2. התחברות והתנתקות ¶

שימוש במחלקת הזהות ורכיב ניהול המשתמשים, אנו יכולים ליישם פעולות התחברות וניתוק בקלות.

// חיבור משתמש עם שם המשתמש והסיסמא
$identity=new UserIdentity($username,$password);
if($identity-»authenticate())
    Yii::app()-»user-»login($identity);
else
    echo $identity-»errorMessage;
......
// ניתוק המשתמש הנוכחי
Yii::app()-»user-»logout();

כברירת מחדל, משתמש ינותק אחרי זמן מסויים של חוסר פעילות, תלוי בהגדרות session. בכדי לשנות התנהגות זו, אנו יכולים להגדיר את המאפיין allowAutoLogin של רכיב המשתמשים לערך השווה ל true ולהעביר את משך זמן החיבור הפעיל כפרמטר למתודה CWebUser::login. כתוצאה המשתמש יהיה מחובר במשך הזמן שהוגדר, גם אם הוא סוגר את הדפדפן. יש לזכור שאפשרות זו דורשת מדפדפן המשתמש לאפשר שמירת עוגיות.

// חיבור המשתמש למשך 7 ימים
// יש לוודא שהערך allowAutoLogin הוגדר ל true
Yii::app()-»user-»login($identity,3600*24*7);

3. פילטר ניהול גישות ¶

פילטר ניהול גישות הינה תרשים הרשאות המקדים את הפעולה שהמשתמש רוצה לבצע ובודק אם אותו משתמש יכול לבצע אותה. ההרשאות מבוססות על שם משתמש, כתובת IP וסוגי בקשות. ניהול הגישות מתבצע על ידי פילטר בשם "accessControl".

» Tip|טיפ: פילטר ניהול גישות הוא מספק עבור מקרים פשוטים. עבור מקרים יותר מסובכים של ניהול גישות והרשאות, ניתן להשתמש בניהול גישות המבוסס על פי תפקידים (RBAC (או קבוצות)) אשר מפורט בהמשך.

בכדי לשלוט בגישה לפעולות בקונטרולר, אנו מתקינים את פילטר ניהול הגישות על ידי דריסה של המתודה CController::filters (ראה Filter למידע נוסף אודות התקנת פילטר).

class PostController extends CController
{
    ......
    public function filters()
    {
        return array(
            'accessControl',
        );
    }
}

בקוד המוצג למעלה, אנו מגדירים שפילטר ניהול הגישות מצורף לכל פעולה של הקונטרולר PostController. חוקי ההרשאה המפורטים של פילטר זה מוגדרים על ידי דריסה של המתודה CController::accessRules במחלקה של הקונטרולר.

class PostController extends CController
{
    ......
    public function accessRules()
    {
        return array(
            array('deny',
                'actions'=»array('create', 'edit'),
                'users'=»array('?'),
            ),
            array('allow',
                'actions'=»array('delete'),
                'roles'=»array('admin'),
            ),
            array('deny',
                'actions'=»array('delete'),
                'users'=»array('*'),
            ),
        );
    }
}

הקוד למעלה מגדיר 3 חוקים, כל אחד מיוצג כמערך. האלמנט הראשון במערך הוא 'allow' או 'deny' ושאר האלמנטים מגדירים את הפרמטרים של דפוס החוק. חוקים אלו מבצעים: הפעולות action ו create לא ניתנות לביצוע על ידי משתמשים אנונימיים; פעולת ה delete ניתנת לביצוע על ידי משתמשים עם תפקיד של admin; ופעולת ה delete לא ניתנת לביצוע על ידי כל אחד.

חוקי הגישות מוערכים אחד אחד בסדר בהם הם הוגדרו. החוק הראשון שתואם לדפו הנוכחי (לדוגמא שם משתמש, תפקיד, כתובת IP, כתובת) קובעת את תוצאת ההרשאה. אם חוק זה הוא חוק allow, הפעולה ניתנת לביצוע; במידה וחוק זה הוא deny, הפעולה לא ניתנת לביצוע; אם אף אחד מהחוקים לא תואם להקשר, הפעולה עדיין ניתנת לביצוע.

» Tip|טיפ: בכדי לוודא שהפעולה לא תתבצע תחת הקשר מסויים, רצוי להגדיר חוק התואם לכל של deny בסוף סט החוקים, כבדוגמא הבאה: » ~~~ » [php] » return array( » // ...חוקים נוספים.... » // החוק הבא מונע גישה לפעולה של מחיקה delete בכל ההקשרים » array('deny', » 'actions'=»array('delete'), » ), » ); » ~~~ » הסיבה שאנו מוסיפים את החוק הזה בסוף הוא כדי למנוע הרצה של הפעולה delete במידה ולא נמצא שום הקשר למשתמש הנוכחי. אחרת הפעולה תרוץ אם לאף אחד מהחוקים שמעליו לא נמצאה התאמה.

לכל הקשר בחוקים ניתן להגדיר את הפרמטרים הבאים:

• actions: מציין אילו פעולות החוק הזה תקף לגביהם ויהיה ניסיון התאמה. הגדרה זו צריכה להיות מערך של אלמנטים שהם שמות היחודיים של הפעולות. ההשוואה בין השמות אינה רגישה לאותיות גדולות-קטנות.

• controllers: מציין אילו קונטרולרים החוק הזה תקף לגביהם ויהיה ניסיון התאמה. הגדרה זו צריכה להיות מערך של אלמנטים שהם שמות היחודיים של הקונטרולרים. ההשוואה בין השמות אינה רגישה לאותיות גדולות-קטנות. אפשרות זו קיימת החל מגרסא 1.0.4.

• users: מציין אילו משתמשים החוק הזה תקף לגביהם ויהיה ניסיון התאמה. הערך שעליו תתבצע ההשואה הוא שם המשתמש - name ברכיב המשתמשים. ההשוואה בין השמות אינה רגישה לאותיות גדולות-קטנות. ניתן להשתמש כאן בשלושה תווים מיוחדים:

  • *: כל משתמש, הכולל גם את המשתמשים האנונימיים והמשתמשים שפרטיהם אומתו (מחוברים).
  • ?: משתמשים אנונימים.
  • @: משתמשים אשר פרטיהם אומתו (מחוברים).

• roles: מציין אילו תפקידים (קבוצות) החוק הזה תקף לגביהם ויהיה ניסיון התאמה. אפשרות זו נעזרת בניהול גישות המבוססת על תפקידים (קבוצות) אשר מתוארת בחלק הבא. חוק זה מצורף אם CWebUser::checkAccess מחזיר ערך true לאחד התפקידים. זכור, רצוי להשתמש בתפקידים בחוק שהוא מוגדר כ allow ולא deny מאחר ועל פי ההגדרה, תפקיד מייצג הרשאה לבצע פעולה מסויימת. כמו כן, רצוי לזכור שלמרות שאנו משתמשים במונח תפקידים (roles) במקרה הזה, הערך שלו יכול להיות כל ערך הרשאתי, הכולל תפקידים, משימות ופעולות.

• ips: מציין אילו כתובות IP החוק הזה תקף לגביהם ויהיה ניסיון התאמה עם הכתובת של המשתמש הנוכחי.

• verbs: מציין אילו סוגי בקשות (GET, POST) החוק הזה תקף לגביהם ויהיה ניסיון התאמה עם הבקשה הנוכחית. השוואה זו אינה רגישה לאותיות גדולות-קטנות.

• expression: מציין ביטוי ב PHP שהתוצאה מעידה אם החוק הזה תואם או לא. בביטוי, ניתן להשתמש במשתנה user$ אשר מתייחס ל Yii::app()-»user. אפשרות זו קיימת החל מגרסא 1.0.3.

טיפול בתוצאת האימות (הגישה)

ברגע שהגישה נדחית, כלומר, המשתמש אינו מורשה לבצע את הפעולה המיוחסת, אחד משני המקרים הבאים יכול לקרות:

• במידה והמשתמש אינו מחובר והמאפיין loginUrl של רכיב המשתמשים מוגדר להיות עמוד ההתחברות, המשתמש יועבר לעמוד זה. יש לזכור שכברירת מחדל, loginUrl מכוון לעמוד site/login.

• אחרת תזרק שגיאה חריגה (Exception) ותוצג שגיאת HTTP 304.

בעת ההגדרה של המאפיין loginUrl, ניתן לציין נתיב רלטיבי או מלא. כמו כן ניתן להגדיר את המאפיין כמערך שמציין כתובת לקונטרולר/פעולה ואז יעשה שימוש ב CWebApplication::createUrl בכדי להפוך את המערך לקישור נכון. האלמנט הראשון במערך מציין את הנתיב לקונטרולר של עמוד ההתחברות והפעולה שצריך להריץ, ושאר האלמנטים בפורמט של מפתח=»ערך הינם פרמטרים (GET) אשר יתווספו לקישור בעת יצירתו. לדוגמא,

array(
    ......
    'components'=»array(
        'user'=»array(
            // זהו בעצם ערך ברירת המחדל
            'loginUrl'=»array('site/login'),
        ),
    ),
)

במידה והמשתמש הועבר לעמוד ההתחברות והוא התחבר בהצלחה, אנו נרצה להעביר אותו לאותו עמוד שבו הוא היה קודם לכן כשהגישה שלו נדחתה. כיצד אנו יודעים מהו הקישור לעמוד זה? אנו יכולים לקבל מידע זה מהמאפיין returnUrl של רכיב המשתמשים. לכן אנו יכולים לכתוב את הקוד הבא כדי לבצע את ההעברה לעמוד בו הוא היה קודם:

Yii::app()-»request-»redirect(Yii::app()-»user-»returnUrl);

4. ניהול גישות על פי תפקידים (קבוצות משתמשים) ¶

ניהול גישות על פי תפקידים (RBAC) מספק מקום מרכזי לניהול הגישות בצורה פשוטה אך יעילה. יש לעיין במאמר Wiki כדי לקבל פרטים והשוואות של RBAC מול אפשרויות ניהול גישות מסורתיות אחרות.

Yii מיישם תכנית RBAC היררכי בעזרת הרכיב authManager. בחלק הבא, אנו קודם מציגים את המושגים העקריים בהם משתמשים בעיקר בתכנית זו; בסוף החלק אנו מציגים כיצד להשתמש באימות נתונים כדי לבדוק אפשרויות גישה שונות.

סקירה

העיקרון העומד מאחורי ה RBAC במערכת ה-Yii הוא פריט הרשאה. פריט הרשאה הינו סמכות לבצע פעולה מסויימת (לדוגמא יצירת הודעה חדשה, ניהול משתמשים). בהתאם לגרעיניות וקהל היעד, ניתן לסווג פריטי הרשאה כ פעולות, משימות ו תפקידים. תפקיד מכיל משימות, משימה מכילה פעולות, ופעולה הינה הרשאה שהיא אטומית. לדוגמא, במידה ויש לנו מערכת עם תפקיד בשם administrator המכיל משימות של ניהול הודעות ו ניהול משתמשים. המשימה ניהול משתמשים מכילה פעולות כמו יצירת משתמש, עדכון משתמש ו מחיקת משתמש. למקסימום גמישות, Yii מאפשרת לתפקיד להכיל תפקידים או פעולות נוספות, למשימה להכיל משימות נוספות, ופעולות להכיל פעולות נוספות (זאת אומרת לשרשר בין תפקידים משימות ופעולות).

פריט הרשאה מזוהה בצורה יחודית על ידי שמו.

פריט הרשאה יכול להיות מקושר קוד עסקי. קוד עסקי הינו חתיכת קוד PHP אשר ירוץ בעת בדיקת הגישה תוך התחשבות בפריט ההרשאתי. רק ברגע שהקוד שירוץ יחזיר True, אז המשתמש יחשב כבעל גישה המיוצג על ידי הפריט הזה. לדוגמא, בזמן שאנו מגדירים פעולה updatePost, אנו נרצה להוסיף קוד עסקי שבודק שמספר המשתמש הנוכחי הוא זהה למספר המשתמש של המפרסם שפרסם את ההודעהת ככה שרק המשתמש שפרסם את ההודעה יהיה ראשי לערוך אותה.

בעזרת שימוש בפריטי הרשאה, אנו יכולים לבנות היררכית הרשאות. פריט A הוא אב לפריט אחר בשם B בהיררכיה אם A מכיל את B (כלומר A יורש את ההרשאות המיוצגות על ידי B). פריט יכול להכיל כמה תתים, כמו כן הוא יכול להכיל כמה פריטים מעליו (אבות). לכן, היררכית הרשאות הינו גרף ולא עץ. בהיררכיה זו, פריטי תפקידים יושבים ברמה הגבוה ביותר, פעולות יושבות ברמה הנמוכה ביותר, בזמן שמשימות יושבות באמצע.

ברגע שיש ברשותנו היררכית הרשאות, אנו יכולים להקצות תפקידים בהירככיה זו למשתמשים באפליקציה. משתמש, ברגע שתפקיד מוקצה לו, יהיו ברשותו ההרשאות המיוצגות על ידי אותו תפקיד. לדוגמא, אם נקצה את התפקיד administrator למשתמש, הוא יוכל לבצע את המשימות של מנהל ראשי, משימות הכוללות לדוגמא ניהול הודעות ו ניהול משתמשים (והפעולות המקבילות למשימות אלו).

עכשיו החלק המהנה מתחיל. בפעולה בקונטרולר, אנו רוצים לבדוק אם המשתמש הנוכחי יכול למחוק את ההודעה שהוגדרה. שימוש בהיררכית RBAC וההקצאות, ניתן לבצע זאת בצורה פשוטה בדרך הבאה:

if(Yii::app()-»user-»checkAccess('deletePost'))
{
    // מחיקת ההודעה
}

הגדרת ניהול הרשאות

לפני שאנו ניגשים להגדרת היררכית הרשאות ולבצע בדיקות גישה, אנו צריכים להגדיר את הרכיב authManager באפליקציה. Yii מספקת שני סוגים של ניהול גישות: CPhpAuthManager ו CDbAuthManager. הראשון משתמש בקובץ סקריפט PHP כדי לאחסן את נתוני ההרשאות, בזמן שהשני שומר את נתוני ההרשאות במסד הנתונים. כשאנו מגדירים את רכיב האפליקציה authManager, אנו צריכים לציין איזה מחלקה אנו נשתמש בה ומה הם הערכים ההתחלתיים לרכיב. לדוגמא,

return array(
    'components'=»array(
        'db'=»array(
            'class'=»'CDbConnection',
            'connectionString'=»'sqlite:path/to/file.db',
        ),
        'authManager'=»array(
            'class'=»'CDbAuthManager',
            'connectionID'=»'db',
        ),
    ),
);

לאחר מכן אנו יכולים לגשת אל הרכיב authManager בעזרת Yii::app()-»authManager.

הגדרת היררכית הרשאות

הגדרת היררכית הרשאות כרוכה בשלושה שלבים: הגדרת פריטי הרשאה, יצירת קישורים בין פריטי הרשאה, והקצאת תפקידים למשתמשים באפליקציה. הרכיב authManager מספק סט שלם של מתודות (API) כדי להשיג מטרות אלו.

כדי להגדיר פריט הרשאה, יש לקרוא לאחת מהמתודות הבאות, תלוי בסוג הפריט:

• CAuthManager::createRole
• CAuthManager::createTask
• CAuthManager::createOperation

ברגע שיש לנו סט של פריטי הרשאה, אנו יכולים לקרוא למתודות הבאות בכדי ליצור קשרים בין פריטי ההרשאה השונים:

• CAuthManager::addItemChild
• CAuthManager::removeItemChild
• CAuthItem::addChild
• CAuthItem::removeChild

ולבסוף, אנו קוראים למתודות הבאות כדי להקצות תפקידים למשתמשים בודדים:

• CAuthManager::assign
• CAuthManager::revoke

למטה אנו מציגים דוגמא ליצירת היררכית הרשאות עם המתודות שהוצגו קודם לכן:

$auth=Yii::app()-»authManager;
 
$auth-»createOperation('createPost','יצירת הודעה');
$auth-»createOperation('readPost','קריאת הודעה');
$auth-»createOperation('updatePost','עריכת הודעה');
$auth-»createOperation('deletePost','מחיקת הודעה');
 
$bizRule='return Yii::app()-»user-»id==$params["post"]-»authID;';
$task=$auth-»createTask('updateOwnPost','עריכת הודעה על ידי המפרסם בלבד',$bizRule);
$task-»addChild('updatePost');
 
$role=$auth-»createRole('reader');
$role-»addChild('readPost');
 
$role=$auth-»createRole('author');
$role-»addChild('reader');
$role-»addChild('createPost');
$role-»addChild('updateOwnPost');
 
$role=$auth-»createRole('editor');
$role-»addChild('reader');
$role-»addChild('updatePost');
 
$role=$auth-»createRole('admin');
$role-»addChild('editor');
$role-»addChild('author');
$role-»addChild('deletePost');
 
$auth-»assign('reader','readerA');
$auth-»assign('author','authorB');
$auth-»assign('editor','editorC');
$auth-»assign('admin','adminD');

» Info|מידע: למרות שהקוד למעלה נראה ארוך ומשעמם, הוא נועד בעיקר לצרכי הדגמה לשימוש במתודות. מפתחים בדרך כלל צריכים לפתח ממשקים אשר מפשטים את הפעולות ההלו למשתמשי הקצה ויוצרים היררכיה הרשאות באופן אינטואיטיבי.

שימוש בקודים עסקיים

כשאנו מגדירים היררכית הרשאות, אנו יכולים לקשר תפקיד, משימה או פעולה למה שנקרא קוד עסקי. כמו כן אנו יכולים לקשר קוד עסקי כשאנו מקצים תפקיד למשתמש. קוד עסקי הינו חתיכת קוד PHP שירוץ ברגע שאנו נבצע בדיקת גישה. הערך המוחזר מהקוד העסקי נועד כדי לקבוע אם התפקיד או המשימה חלה על המשתמש הנוכחי. בדוגמא למעלה, אנו קישרנו קוד עסקי למשימה updateOwnPost. בקוד העסקי אנו פשוט בודקים אם מספר המזהה היחודי של המשתמש הנוכחי הוא זהה למספר המשתמש שפרסם את ההודעה. פרטי ההודעה במערך ה params$ מסופק על ידי המפתחים בעת ביצוע בדיקת הגישה.

בדיקת גישה

בכדי לבצע בדיקת גישה, אנו קודם צריכים לדעת את שם פריט ההרשאה. לדוגמא, כדי לבדוק אם המשתמש הנוכחי יכול ליצור הודעה, אנו נבדוק אם יש לו הרשאה המיוצגת על ידי הפעולה createPost. אז אנו קוראים ל-CWebUser::checkAccess כדי לבצע את בדיקת הגישה:

if(Yii::app()-»user-»checkAccess('createPost'))
{
    // יצירת הודעה
}

אם פריט ההרשאה מקושר עם קוד עסקי שדורש פרמטרים נוספים, אנו יכולים להעביר אותם גם כן. לדוגמא, בכדי לבדוק אם משתמש יכול לערוך הודעה, אנו נכתוב,

$params=array('post'=»$post);
if(Yii::app()-»user-»checkAccess('updateOwnPost',$params))
{
    // עדכון הודעה
}

שימוש בתפקידים מוגדרים מראש

» Note|הערה: אפשרות תפקידי ברירת המחדל קיימת החל מגרסא 1.0.3.

אפליקציות ווב רבות צריכות כמה תפקידים מאוד מיוחדים שיוקצו לכל המשתמשים או לרובם. לדוגמא, אנו נרצה להקצות הרשאות לכל המשתמשים המחוברים (שאומתו). זה דורש הרבה עבודת תחזוקה אם אנו נגדיר ונשמור את כל ההקצאות הללו במפורש. אנו יכולים לנצל את האפשרות של תפקידי ברירת מחדל (default roles) כדי לפתור בעיה זו.

תפקיד ברירת מחדל הינו תפקיד אשר הוקצה לכל משתמש, הכוללים את האורחים והמשתמשים כאחד. אנו לא צריכים להקצות תפקידים אלו עבור כל משתמש בנפרד. ברגע שמתבצעת קריאה של CWebUser::checkAccess, תפקידי ברירת המחדל נבדקים ראשונים במידה והם הוקצו למשתמש.

תפקידי ברירת מחדל צריכים להיות מוגדרים במאפיין CAuthManager::defaultRoles. לדוגמא, הקוד הבא מגדיר שני תפקידים כתפקידים ברירת מחדל: authenticated ו guest.

return array(
    'components'=»array(
        'authManager'=»array(
            'class'=»'CDbAuthManager',
            'defaultRoles'=»array('authenticated', 'guest'),
        ),
    ),
);

מאחר ותפקיד ברירת מחדל מוקצה לכל משתמש, הוא בדרך כלל צריך להיות מקושר עם קוד עסקי בכדי לקבוע אם אותו תפקיד באמת חל על המשתמש הנוכחי. לדוגמא, הקוד הבא מגדיר שני תפקידים, authenticated ו guest, אשר למעשה חל על משתמשים מחוברים ומשתמשים שהינם אורחים, בהתאמה.

$bizRule='return !Yii::app()-»user-»isGuest;';
$auth-»createRole('authenticated', 'authenticated user', $bizRule);
 
$bizRule='return Yii::app()-»user-»isGuest;';
$auth-»createRole('guest', 'guest user', $bizRule);