130 likes | 224 Views
Authentikáció , authorizáció. 7. előadás. Dióhéjban…. Zend_Auth komponens Authentikációs típusok Az authentikáció menete Zend_Acl_Resource Zend_Acl_Role Jogosultságkezelés ZF-ben. Mire jó a Zend _Auth?. Az authentikáció nem authorizáció. Különbség? Beléptetés Sok támogatott adapter
E N D
Authentikáció, authorizáció 7. előadás
Dióhéjban… • Zend_Auth komponens • Authentikációs típusok • Az authentikáció menete • Zend_Acl_Resource • Zend_Acl_Role • Jogosultságkezelés ZF-ben
Mire jó a Zend_Auth? • 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();
Auth adapterek • 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
Az authentikáció menete • 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, e-mail cím) • setCredentialColumn: Jelszó oszlopa
Háttérműködés • Sessionkezelés – HTTP protokoll munkamenet kezelésére • Kódunkban bárhol lekérdezhetjük az authentikációs adatokat aZend_Auth::getInstance()->getIdentity()segítségével
Zend_Acl_Resource • 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
Zend_Acl_Role • 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.
Mi lesz az eredmény? Nincs hozzáférés deklarálva a someUser és a someResource közt Jobbról balra haladva vizsgáljuk a tömböt Az adminnak megint nincs definiálva hozzáférés A membernek van hozzáférése, méghozzá meg van adva neki „Rövidzár kiértékelés” az első esetben, amikor már tudunk konkréthozzáférésről, nem folytatódik a lánc Kiírjuk, hogy „allowed”
Jogosultságkezelés megoldások • 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
DEMO • Beléptetés az előző alkalmazásunkba Eredmény: Egyszerűsített Social Networking alkalmazás megírása