7. előadás

 Zend_Auth komponens  Authentikációs típusok  Az authentikáció menete  Zend_Acl_Resource  Zend_Acl_Role  Jogosultságkezelés ZF-ben

 Az authentikáció nem authorizáció. Különbség?  Beléptetés  Sok támogatott adapter  Credential szükséges (személyi igazolvány, account)  Singleton minta  Csak statikusan férhetünk hozzá a példányhoz  Zend_Auth::getInstance();

 LDAP  RDBMS  OpenID  File-alapú azonosítás  Adatbázis tábla alapján történő azonosítás  Szükség van egy táblára ahol letároljuk a felhasználói neveket, jelszavakat  Jelszavak tárolása valamilyen kriptográfiai eljárással

 Zend_Auth_Adapter_DbTable  Szükséges hozzá adatbázis kapcsolat  setTableName: ebből a táblából lesz lekérdezve az azonosításhoz szükséges account  setIdentityColumn: Az azonosító oszlop neve (felhasználói név, cím)  setCredentialColumn: Jelszó oszlopa

 Sessionkezelés – HTTP protokoll munkamenet kezelésére  Kódunkban bárhol lekérdezhetjük az authentikációs adatokat a Zend_Auth::getInstance()->getIdentity() segítségével

 A Zend_Acl csomag 2 fontos osztály tartalmaz: Zend_Acl_Resource, Zend_Acl_Role  A resource típusú objektumok azok az „erőforrások”, amikhez jogosultságot igénylünk  Esetünkben pl. az egyes feltöltött dokumentumok, a controllerek, action-ök, modellek akár…  Ha elég logikusan építettük fel controllereinket és azokban az action-öket, akkor nagyon részletesen konfigurálható jogosultságkezelést tudunk implementálni

 A Zend_Acl_Role típusú objektumok azok, amelyeknek hozzáférést adhatunk, vagy épp megtilthatjuk a hozzáférést a resource-okhoz  Pld. role-ok lehetnek a felhasználók, felhasználói csoportok, stb…  A role-ok egymástól örökölhetik a jogosultságokat, tehát beszélhetünk szülő role-ról és gyermek role- ról.

1.Nincs hozzáférés deklarálva a someUser és a someResource közt 2.Jobbról balra haladva vizsgáljuk a tömböt 3.Az adminnak megint nincs definiálva hozzáférés 4.A membernek van hozzáférése, méghozzá meg van adva neki 5.„Rövidzár kiértékelés” az első esetben, amikor már tudunk konkrét hozzáférésről, nem folytatódik a lánc 6.Kiírjuk, hogy „allowed”

 Közvetlenül a bootstrapben  Közvetlenül az authentikáció helyén  Config állományban  Modellként, saját ACL interface segítségével  Adatbázistáblában tárolva  Hozzáférési szintek szerinti csoportosítás  Az ACL objektumot csak az aktuális role-ra kell felépíteni, és lehetőleg csak egyszer, authentikációkor

 Beléptetés az előző alkalmazásunkba Eredmény: Egyszerűsített Social Networking alkalmazás megírása