0 follower

Autentisering och auktorisering

Autentisering och auktorisering erfordras för en webbsida som skall vara tillgänglig endast för vissa användare. Autentisering handlar om att verifiera att någon är den han/hon uppger sig vara. Identifieringsförfarandet involverar vanligtvis ett användarnamn och ett lösenord, men kan också omfatta någon annan metod för att verifiera identitet, såsom smartcard, fingeravtryck etc. Auktorisering innebär att avgöra huruvida en person, när denne väl är identifierad (autentiserad), har tillåtelse att manipulera specifika resurser. Detta avgörs vanligtvis genom att undersöka om denna person ingår i en viss roll som har tillgång till resurserna.

Yii har ett inbyggt autentiserings-/auktoriseringsramverk (auth), vilket är lättanvänt och kan anpassas till speciella behov.

Den centrala delen i Yii:s auth-ramverk är den fördefinierade applikationskomponenten user, ett objekt som implementerar gränssnittet IWebUser. Komponenten user representerar icke-flyktig information om aktuell användares identitet. Den kan kommas åt från alla ställen i koden med hjälp av Yii::app()->user.

Med hjälp av user-komponenten kan vi kontrollera om en användare är inlogggad eller inte via CWebUser::isGuest; logga in och logga ut en användare; undersöka om en användare kan utföra specifika operationer genom att anropa CWebUser::checkAccess; samt även erhålla den unika identifieraren och annan icke-flyktig identitetsinformation rörande användaren.

1. Definiera identitetsklass

Som nämnts ovan handlar autentisering om att validera användarens identitet. En typisk webbapplikations implementering av autentisering involverar vanligtvis en kombination av användarnamn och lösenord för att verifiera en användares identitet. Den kan dock omfatta andra metoder och skilda implementeringar kan erfordras. För att åstadkomma varierande autentiseringsmetoder introducerar Yii:s auth-ramverk begreppet identitetsklass.

Vi definierar en identitetsklass som innehåller den faktiska autentiseringslogiken. Identitetsklassen skall implementera gränssnittet IUserIdentity. Olika klasser kan implementeras för varierande autentiseringsmetoder (t.ex. OpenID, LDAP, Twitter OAuth, Facebook Connect). En bra start är att ärva och utvidga CUserIdentity som är basklass för autenticeringsmetoden som baseras på användarnamn och lösenord.

Det mesta arbetet med att definiera en identitetsklass är implementeringen av metoden IUserIdentity::authenticate. Detta är metoden som används för att kapsla in de huvudsakliga detaljerna för tillvägagångssättet vid autentisering. En identitetsklass kan även deklarera ytterligare identitetsinformation som behöver förbli icke-flyktig under pågående användarsession.

Ett exempel

åsidosätter även metoden getId så att den returnerar variabeln _id, vilken åsätts ett värde under autentiseringen (standardimplementeringen returnerar användarnamnet som ID). Under autentiseringen kan inhämtad title-information lagras i ett state med samma namn medelst anrop av CBaseUserIdentity::setState.

I följande exempel, använder vi en identitetsklass för att demonstrera tillvägagångssättet att använda en databas för autentisering. Detta är mycket typiskt för de flesta webbapplikationer. En användare matar in sitt användarnamn och lösenord i ett inmatningsformulär, därefter validerar vi, med hjälp av ActiveRecord, dessa inloggningsuppgifter mot en användartabell i databasen. Flera olika saker demonstreras i detta enstaka exempel:

  1. Implementering av metoden authenticate() så att den använder databasen för validering av inloggningsuppgifter.
  2. Åsidosättning av metoden CUserIdentity::getId() så att den returnerar propertyn _id eftersom standardimplementeringen returnerar användarnamnet som ID.
  3. Användning av metoden setState() (CBaseUserIdentity::setState) för att visa hur man kan lagra ytterligare information som lätt kan återhämtas vid senare request.
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;
    }
}

När vi i nästa avsnitt går igenom inloggning och utloggning, kommer det att framgå att vi bifogar denna identitetsklass vid anrop inloggningsmetoden för en användare. Information som sparas i ett state (genom anrop av CBaseUserIdentity::setState) förmedlas till CWebUser vilken lagrar den i icke-flyktigt minne, så som session. Denna information kan sedan kommas åt i form av propertyn i CWebUser. I vårt exempel lagrade vi information om användarens titel via anropet $this->setState('title', $record->title);. När väl inloggningsprocesen är genomförd, går det att erhålla title-information för aktuell användare via Yii::app()->user->title.

Info: Som standard använder CWebUser sessionen för icke-flyktig lagring av information om användaridentitet. Om cookie-baserad inloggning gjorts möjlig (genom att sätta CWebUser::allowAutoLogin till true), kan informationen om användarens identitet även lagras i en cookie. Se till att känslig information (t.ex. lösenord) ej deklareras som icke-flyktig.

2. In- och utloggning

Genom användning av identitetsklassen och user-komponenten kan in-och utloggningsåtgärder enkelt implementeras. När vi nu sett ett exempel på hur en användaridentitet kan skapas, använder vi detta som hjälp att underlätta implementeringen av erforderliga inloggnings- och utloggningsåtgärder. Följande kod visar hur detta kan åstadkommas:

// Login a user with the provided username and password.
$identity=new UserIdentity($username,$password);
if($identity->authenticate())
    Yii::app()->user->login($identity);
else
    echo $identity->errorMessage;
......
// Logout the current user
Yii::app()->user->logout();

Här skapar vi ett nytt UserIdentity-objekt och lämnar med autentiseringsuppgifterna (d.v.s $username- och $password-värdena användaren matat in) till dess constructor. Därefter anropar vi helt enkelt metoden authenticate(). Vid lyckad autentisering
lämnar vi vidare identitetsinformationen till metoden CWebUser::login, som kommer
att spara identitetsinformationen till icke-flyktigt minne (som standard PHP:s session), för senare återhämtning vid kommande request. Om autentiseringen misslyckas kan vi erhålla mer information om anledningen från propertyn errorMessage.

Huruvida en användare blivit autentiserad kan lätt kontrolleras från valfri plats i applikationen med hjälp av Yii::app()->user->isGuest. Om icke-flyktigt minne (som standard session) och/eller en cookie (se nedan) används till att lagra identitetsinformationen, kan användaren förbli inloggad inför efterkommande request. I detta fall behöver inte klassen UserIdentity och hela inloggningsprocessen användas vid varje request. I stället kommer CWebUser att automatiskt ombesörja laddning av identitetsinformationen från icke-flyktigt minne och använda den för att avgöra huruvida Yii::app()->user->isGuest returnerar true eller false.

Som standard loggas en användare ut efter en viss tid utan aktivitet, beroende på sessionskonfigurationen. Detta beteende kan man ändra genom att propertyn allowAutoLogin i user-komponenten sätts till true samt genom att lämna en varaktighetsparameter till metoden CWebUser::login. Användaren kommer då att förbli inloggad hela den specificerade varaktigheten, även om webbläsarens fönster dessförinnan stängs. Lägg märke till att denna finess kräver att användarens webbläsare accepterar cookies.

// Låt användaren förbli inloggad i 7 dagar.
// Kontrollera att allowAutoLogin är konfigurerad till true i komponenten user.
Yii::app()->user->login($identity,3600*24*7);

Som tidigare nämnts kommer, om cookie-baserad inloggning är aktiverad, även de tillstånd som lagrats via CBaseUserIdentity::setState att sparas i cookie. Nästa gång användaren loggas in, kommer dessa tillstånd att läsas från cookie och göras tillgängliga via Yii::app()->user.

Även om Yii kan vidta åtgärder för att skydda en tillstånds-cookie från att bli ändrad på klientsidan, rekommenderar vi bestämt att ur säkerhetssynpunkt känslig information ej lagras som tillstånd (states). Istället bör sådan information återskapas på serversidan genom att den läses från något icke-flyktigt lagringsmedium (t.ex. databas).

Vidare, i fråga om seriösa webbapplikationer, rekommenderar vi starkt användning av följande strategi för ökad säkerhet vid cookie-baserad inloggning.

  • När en användare genomför en lyckad inloggning genom att fylla i ett inloggningsformulär, lagrar vi en slumpgenererad nyckel såväl i cookielagrad tillståndinformation som i icke-flyktigt medium på serversidan (t.ex. databas).

  • När, vid en senare kommande request, autentisering av användaren sker via cookielagrad information, jämför vi de två exemplaren av den slumpgenererade nyckeln och förvissar oss om att de överensstämmer innan användaren loggas in.

  • Om inloggningsformuläret återigen används för inloggning, behöver nyckeln genereras på nytt.

Genom användning av ovanstående strategi eliminerar vi möjligheten att en användare återanvänder en gammal cookie, som kan innehålla inaktuell tillståndsinformation.

För att implementera ovanstående strategi, behöver vi åsidosätta följande två metoder:

  • CUserIdentity::authenticate(): här utförs den egentliga autentiseringen. Om användaren är korrekt autentiserad, genererar vi en ny slumpgenererad nyckel och lagrar den i såväl databasen som i identitetstillståndet, via CBaseUserIdentity::setState.

  • CWebUser::beforeLogin(): anropas när användaren faktiskt loggas in. Här kontrollerar vi att nyckeln som erhålls från tillstånds-cookie överensstämmer med den som hämtas från databasen.

4. Filter för åtkomstkontroll

Filter för åtkomstkontroll (access control filter) är ett preliminärt auktoriseringsschema som bestämmer huruvida den aktuella användaren får utföra begärd kontrolleråtgärd. Auktoriseringen baseras på användarnamnet, klientens ip-adress samt typ av request. Den tillhandahålls som ett filter benämnt "accessControl".

Tips: Ett filter för åtkomstkontroll är tillräckligt för enklare scenarier. För mer komplex åtkomstkontroll kan rollbaserad åtkomsthantering (RBAC) användas, vilket beskrivs i nästa avsnitt.

För att hantera åtkomst till åtgärder i en kontroller, installerar man ett filter för åtkomstkontroll genom att åsidosätta CController::filters (se Filter för fler detaljer angående installation av filter).

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

I ovanstående exempel specificeras att filtret access control skall appliceras på varje åtgärd i PostController. De detaljerade auktoriseringsreglerna som filtret använder specificeras genom att man åsidosätter CController::accessRules i kontrollerklassen.

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('*'),
            ),
        );
    }
}

Ovanstående kod specificerar tre regler, var och en representerad av en array. Det första elementet i arrayen är antingen 'allow' eller 'deny', övriga består av namn-värdepar som specificerar reglerna genom mönsterparametrar. Exemplets regler skall utläsas: åtgärderna create och edit kan inte utföras av ej autentiserade användare (anonymous); åtgärden delete kan utföras av användare med rollen admin; åtgärden delete kan inte utföras av någon.

Åtkomstreglerna utvärderas en och en i den ordning de specificerats. Den första regeln som matchar aktuellt mönster (t.ex. användarnamn, roller, klientens ip-adress) bestämmer resultatet av auktoriseringen. Om denna regel är en allow-regel, kan åtgärden exekveras; om den är en deny-regel, kan åtgärden inte köras; om ingen av reglerna är tillämplig i kontextet, kommer åtgärden fortfarande att kunna köras.

Tips: För att säkerställa att en viss åtgärd inte körs i vissa kontext, är det fördelaktigt att i slutet av regeluppsättningen alltid specificera en deny-regel som matchar allt , som i det följande:

return array(
    // ... andra regler...
    // följande regel förhindrar 'delete'-åtgärden att köras i alla kontext
    array('deny',
        'actions'=>array('delete'),
    ),
);

Anledningen till ovanstående regel är att om ingen regel alls matchar ett kontext, kommer en åtgärd att fortsätta exekveras.

En åtkomstregel kan matcha följande kontextparametrar:

  • actions: specificerar vilka åtgärder denna regel matchar. Detta skall vara en array av åtgärds-ID:n. Jämförelsen sker skiftlägesoberoende (case-insensitive).

  • controllers: specificerar vilka kontroller denna regel matchar. Detta skall vara en array av kontroller-ID:n. Jämförelsen sker skiftlägesoberoende.

  • users: specificerar vilka användare denna regel matchar. Aktuellt användarnamn används för matchning. Jämförelsen sker skiftlägesoberoende. Tre specialtecken kan användas här:

    • *: varje användare, inkluderande både anonyma och autentiserade användare.
    • ?: anonyma användare.
    • @: autentiserade användare.

  • roles: specificerar vilka roller denna regel matchar. Till detta används finessen rollbaserad åtkomstkontroll som kommer att beskrivas i nästa underavsnitt. Mer detaljerat, regeln appliceras om CWebUser::checkAccess returnerar true för någon av rollerna. Lägg märke till att roller huvudsakligen bör användas i en allow-regel eftersom, per definition, representerar en roll tillåtelse att göra något. Märk också att, även om termen roles används här, kan dess värde utgöras av varje auth-element, inklusive roller, uppgifter och operationer.

  • ips: specificerar vilka (klient) ip-adresser denna regel matchar.

  • verbs: specificerar vilka typer av request (t.ex. GET, POST) denna regel, matchar. Jämförelsen sker skiftlägesoberoende.

  • expression: specificerar ett PHP-uttryck vars värde indikerar huruvida denna regel matchar. I uttrycket kan man använda variabeln $user, vilken refererar till Yii::app()->user.

5. Hantera resultat av auktorisering

När en auktorisering misslyckas, dvs användaren tillåts inte utföra den tilltänkta åtgärden, kan ett av följande två scenarier utspela sig:

  • Om användaren inte är inloggad samt user-komponentens property loginUrl konfigurerats att vara inloggningssidans URL, kommer webbläsaren att styras om till den sidan. Lägg märke till att som standard pekar loginUrl till sidan site/login.

  • I annat fall kommer en HTTP-exception att presenteras, med felkod 403.

När loginUrl-propertyn konfigureras kan man ange en relativ eller absolut URL. Man kan även ange en array som då kommer att användas vid generering av en URL genom anrop till CWebApplication::createUrl. Det första arrayelementet skall specificera en route till inloggningskontrollerns åtgärd, resterande namn-värdepar är GET-parametrar. Till exempel,

array(
    ......
    'components'=>array(
        'user'=>array(
            // this is actually the default value
            'loginUrl'=>array('site/login'),
        ),
    ),
)

Om webbläsaren har styrts om till inloggningssidan och inloggningen lyckas, vill vi antagligen styra webbläsaren tillbaka till sidan som fann auktoriseringen otillräcklig. Hur kan vi veta URL:en för denna sida? Den informationen går att erhålla från user-komponentens property returnUrl. Sålunda kan omstyrningen åstadkommas på följande sätt:

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

6. Rollbaserad åtkomsthantering

Rollbaserad åtkomsthantering (RBAC) tillhandahåller enkel men ändå kraftfull centraliserad åtkomstkontroll. Vänligen läs wiki- artikeln för fler detaljer kring RBAC i jämförelse med andra mer traditionella scheman för åtkomstkontroll.

Yii implementerar ett hierarkiskt RBAC-schema genom sin applikationskomponent authManager. I det följande introduceras huvudkoncepten i detta schema; därefter beskrivs hur man definierar auktoriseringsdata; till sist visas hur auktoriseringsdata kommer till användning vid genomförande av åtkomstkontroll.

Översikt

Ett fundamentalt koncept i Yii:s RBAC är auktoriseringsartikel (authorization item). En auktoriseeringsartikel är en rättighet att göra någonting (t.ex. skapa nya bloggpostningar, hantera användare). Alltefter dess finkornighet samt tilltänkta publik kan auktoriseringsartiklar klassificeras som operationer, uppgifter och roller. En roll består av uppgifter, en uppgift består av operationer, en operation är en atomär rättighet. Till exempel kan vi ha ett system med rollen administratör vilken består av uppgifterna hantera postningar och hantera användare. Uppgiften hantera användare kan i sin tur bestå av operationerna skapa användare, uppdatera användare samt tag bort användare. För större flexibilitet tillåter Yii också att en roll består av andra roller eller operationer, en uppgift av andra uppgifter, och en operation av andra operationer.

En auktoriseringsartikel identifieras unikt av dess namn.

En auktoriseringsartikel kan associeras med en affärsregel (business rule). En affärsregel är ett stycke PHP-kod som kommer att exekveras när åtkomstkontroll skall utföras enligt auktoriseringsartikeln. Endast om exekveringen returnerar true, kommer användaren att anses ha rättigheten som representeras av auktoriseringsartikeln. Till exempel, när operationen updatePost definieras, vill vi antagligen lägga till en affärsregel som kollar om användar-ID är samma som postningens författares ID, så att endast författaren själv kan ha rättighet att uppdatera en postning.

Genom användning av auktoriseringsartiklar kan vi bygga upp en auktoriseringshierarki. En artikel A är förälder till en annan artikel B i hierarkin om A består av B (eller säg A ärver rättigheter(na) som B representerar). En artikel kan ha flera barnartiklar (child items), och den kan också ha flera föräldraartiklar. Av denna anledning är en auktoriseringshierarki en partiellt ordnad graf snarare än en trädstruktur. I denna hierarki placerar sig rollartiklar på översta nivån, operationer på de lägsta nivåerna, med uppgiftsartiklar däremellan.

När vi väl har en auktoriseringshierarki, kan vi tilldela applikationsanvändare roller i denna hierarki. En användare har, när denne tilldelats en roll, de rättigheter som rollen representerar. Till exempel, om vi tilldelar en användare rollen administratör, kommer denne att ha administratörsrättigheterna vilka inkluderar hantera postningar and hantera användare (och motsvarande operationer så som skapa användare).

Nu startar det roliga. I en kontrolleråtgärd, vill man kolla om den aktuella användaren kan ta bort den specificerade postningen. Med användning av RBAC- hierarki och -tilldelning kan detta enkelt låta sig göras på följande sätt:

if(Yii::app()->user->checkAccess('deletePost'))
{
    // delete the post
}

7. Konfigurera auktoriseringshanteraren

Innan vi sätter igång med att definiera en auktoriseringshierarki och genomföra åtkomstkontroll, behöver vi konfigurera applikationskomponenten authManager. Yii tillhandahåller två typer av auktoriseringshanterare: CPhpAuthManager och CDbAuthManager. Den förra använder PHP-skriptfiler till att lagra auktoriseringsdata, medan den senare lagrar auktoriseringsdata i en databas. När vi konfigurerar applikationskomponenten authManager, behöver vi specificera vilken komponentklass som skall användas samt vilka initiala propertyvärden som skall gälla för komponenten. Till exempel,

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

Därefter kan authManager kommas åt via Yii::app()->authManager.

8. Definiera auktoriseringshierarki

Att definiera en auktoriseringshierarki involverar tre steg: definiera auktoriseringsartiklar, upprätta samband mellan auktoriseringsartiklar samt tilldela applikationsanvändare roller. Applikationskomponenten authManager tillgängliggör en hel uppsättning API:er för detta ändamål.

För att definiera en auktoriseringsartikel, anropa en av följande metoder, beroende på typ av artikel:

När vi väl har en uppsättning auktoriseringsartiklar, kan följande metoder anropas för att etablera samband mellan auktoriseringsartiklar:

Och slutligen, anropar vi följande metoder för att tilldela individuella användare rollartiklar:

Nedan visas i ett exempel hur man bygger en auktoriseringshierarki med hjälp av de tillgängliga API:erna:

$auth=Yii::app()->authManager;
 
$auth->createOperation('createPost','create a post');
$auth->createOperation('readPost','read a post');
$auth->createOperation('updatePost','update a post');
$auth->createOperation('deletePost','delete a post');
 
$bizRule='return Yii::app()->user->id==$params["post"]->authID;';
$task=$auth->createTask('updateOwnPost','update a post by author himself',$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');

När vi väl har etablerat denna hierarki, kommer komponenten authManager (t. ex. CPhpAuthManager, CDbAuthManager) att ladda auktoriseringsartiklarna automatiskt när de skapas. Därför behöver vi bara exekvera ovanstående kod en gång och INTE vid varje request.

Info: Även om ovanstående exempel framstår som omfattande och långrandigt, återfinns det här som demonstration. Utvecklare behöver vanligtvis utveckla någon form av administrativt användargränssnitt som slutanvändare sedan kan använda för att, på ett mer intuitivt sätt, åstadkomma en auktoriseringshierarki.

9. Använda affärsregler

När vi definierar en auktoriseringshierarki kan vi associera en roll, en uppgift eller en operation med en så kallad affärsregel. Vi kan även associera en affärsregel när vi tilldelar en roll till en användare. En affärsregel är ett stycke PHP-kod som exekveras vid åtkomstkontroll. Returvärdet från denna kod används för att avgöra huruvida rollen eller tilldelningen avser aktuell användare. I ovanstående exempel associerades en affärsregel till uppgiften updateOwnPost. I affärsregeln undersöker vi helt enkelt huruvida aktuell användares ID är identiskt med den specificerade postningens författar-ID. Information om postningen, i arrayen $params, levereras av utvecklare när åtkomstkontroll utförs.

Åtkomstkontroll

För att genomföra åtkomstkontroll, behöver man först veta namnet på auktoriseringsartikeln. Till exempel, för att kontrollera om den aktuella användaren kan skapa en postning, skulle vi kontrollera om denne har rättigheten representerad av operationen createPost. Sedan anropas CWebUser::checkAccess för att genomföra åtkomstkontrollen:

if(Yii::app()->user->checkAccess('createPost'))
{
    // create post
}

Om auktoriseringsregeln är associerad med en affärsregel som erfordrar ytterligare parametrar, kan vi även lämna med dem. Till exempel, för att undersöka huruvida en användare tillåts uppdatera en postning, lämnar vi med postningsdata i argumentet $params:

$params=array('post'=>$post);
if(Yii::app()->user->checkAccess('updateOwnPost',$params))
{
    // update post
}

Använda standardroller

Många webbapplikationer behöver ett antal mycket specialiserade roller som tilldelas varje eller åtminstone de flesta systemanvändarna. Vi kanske vill tilldela alla autentiserade användare vissa rättigheter. Det kan skapa en hel del underhållsproblem om vi väljer att uttryckligt specificera och lagra dessa rolltilldelningar. Vi kan dra nytta av standardroller för att lösa detta problem.

En standardroll är en roll som underförstått tilldelas varje användare, inklusive både autentiserade och gäster. Vi behöver inte uttryckligen tilldela denna till en användare. När CWebUser::checkAccess körs kommer standardroller att kontrolleras först, som om de hade tilldelats användaren.

Standardroller måste deklareras i propertyn CAuthManager::defaultRoles. Exempelvis följande konfiguration deklarerar två roller som standardroller, nämligen authenticated och guest.

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

Eftersom en standardroll tilldelas alla användare, behöver den i regel associeras med en affärsregel som avgör om rollen verkligen skall tillämpas på användaren. Exempel: följande kod definierar två roller, authenticated och guest, vilka i praktiken tillämpas på autentiserade användare respektive gästanvändare.

$bizRule='return !Yii::app()->user->isGuest;';
$auth->createRole('authenticated', 'authenticated user', $bizRule);
 
$bizRule='return Yii::app()->user->isGuest;';
$auth->createRole('guest', 'guest user', $bizRule);
URL-hantering
Go to Top
Teman och skin

Found a typo or you think this page needs improvement?
Edit it on github !