PEAR - III (Autentizace)

31. 5. 2005 | Pavel Szalbot | Programování | 8034×

Další díl seriálu je zaměřen na balíčky poskytující nástroje pro autentizaci uživatelů.

Autentizace

Webové aplikace uživatelům zpravidla nabízejí nejrůznější služby dostupné přes přihlašovací jméno a heslo. Vzniká tak potřeba správy databáze uživatelů, která může být velmi často složitá (účty mohou být uloženy v různých databázových systémech, pravděpodobně budou různě privilegované, obsahují dodatečná data jako doba vypršení, poslední přihlášení apod.) a potřeba vytvořit autentizační systém. Stejně jako vývoj ostatních kritických komponent aplikace si systém ověřování a autorizace vyžádá spoustu času a testování (zvláště kvůli bezpečnosti) a nabízí se tak otázka, jestli by nebylo vhodné poohlédnout se po vyzkoušeném a fungujícím řešení. V PEARu naleznete několik balíčků, které autentizační systém implementují a umí toho možná více, než byste čekali. Tentokrát však buďte při používání cizího kódu ostražití více než obvykle - zabezpečení aplikace a procesům s ním spojeným byste měli dokonale rozumět a cizí kód bezhlavě nepřejímejte.

Co nabízí PEAR?

Auth

Auth je základní balíček tříd poskytující autorizační a ověřovací mechanismy pro vaše skripty. Přes svoji relativní jednoduchost vám dovolí následující:

• volbu úložiště uživatelských účtů (nadefinovaná "abstraktní" třída pro práci s úložistěm a z ní odvozené třídy pro práci s databázovými servery (přes PEAR::DB), soubory s uživatelskými účty (flat files), LDAP serverem, SOAP protokolem apod.)
• správu uživatelských účtů (vytvoření, smazání, změna hesla uživatele)
• kontrolu vypršení a nečinnosti (idle-time) relace/uživatele
• možnost používat několik relací v rámci jediné domény (v sessions známých z PHP se jako proměnné vytvářejí asociativní pole ve zdrojových kódech označené jako "session")
• volitelné vyšší zabezpečení díky sledování IP adresy klienta a jeho HTTP klienta (pozn.: tyto vlastnosti byste měli kontrolovat jen pokud víte, co znamenají - např. IP adresa se může dynamicky měnit a uživatel tak může přijít o relaci).
• ukládat v relaci vlastní data
• často jednoduše migrovat ze starého systému ověřování uživatelů

Při práci s ním dost možná pocítíte např. absenci podpory pro různě privilegované účty, nicméně svojí jednoduchostí vám vše vynahradí tam, kde nejsou potřeba. Mohla by vám také vadit nemožnost využít HTTP autentizaci, ale tu umožní stejnojmenná třída z balíčku Auth_HTTP, která Auth používá jako svoji předlohu.

Příklad typického použití třídy Auth:

<?php
require_once('Auth.php');
require_once('PEAR.php');

/**
 * Zobrazí přihlašovací formulář.
 */
function displayLoginForm() {
    print("<form action=\"\" method=\"post\">\n");
    print("<fieldset>\n");
    print("<legend>Přihlašovací formulář</legend>\n");
    print("<label>Jméno:</label><input type=\"text\" name=\"user\" />\n");
    print("<label>Heslo:</label><input type=\"passwd\" name=\"passwd\" />\n");
    print("<input type=\"submit\" name=\"submit\" value=\"Přihlásit\" />\n");
    print("</fieldset>\n");
    print("</form>\n");
}

$authOptions = array(
        'sessionName' => 'testDomain', 
	'allowLogin' => true,
	'postUsername' => 'user',
	'postPassword' => 'passwd',
	'advancedSecurity' => false,
	'dsn' => 'pgsql://uzivatel:heslo@zoidberg/pear',
        'table' => 'admin_users',
        'usernamecol' => 'login',
        'passwordcol' => 'pass');

$auth = new Auth('DB', $authOptions, 'displayLoginForm');
$auth->start();
if(!$auth->getAuth()) {
	// nepřihlášen ...
} 

?>

Tento jednoduchý příklad demonstruje obvyklou práci s třídou Auth. Definujeme funkci, která se postará o zobrazení přihlašovacího formuláře, následně nastavíme volby pro autentizaci a vytvoříme instanci třídy. Autentizační proces spustíme funkcí start(), která v případě, že uživatel není přihlášen a ze stránky je přihlášení povoleno, zobrazí přihlašovací dialog. Následné volání getAuth() vrací logickou hodnotu signalizující úspěšnost přihlášení. Všimněte si nastavení tabulky ($authOptions['table']), sloupce se jménem uživatele (usernamecol) a heslem (passwordcol). Díky této možnosti můžete svůj starý systém, který pravděpodobně funguje podobně, nahradit třídami balíčku Auth.

Nezoufejte ani v případě, že používáte jiné metody šifrování hesla - třídu pro práci s úložištěm dat můžete vždy 'zdědit' a přizpůsobit vlastním potřebám. Než se pustíte do práce s balíčkem Auth, podívejte se do dokumentace pro uživatele, která vám umožní s třídou okamžitě začít pracovat. Vhod přijdou i znalosti balíčku DB, který je v PEARu hojně používán.

Jako doplněk k Auth byl vytvořen již zmíněný Auth_HTTP, který umožňuje poskytuje HTTP autentizaci dle RFC 2617.

LiveUser

LiveUser se na první pohled podobá balíčku Auth - umožňuje všechny akce s ním proveditelné. Proto mi původně nebylo zcela jasné, proč komunita kolem PEARu začlenění tohoto systému do frameworku povolila (přece jen existuje Auth), postupem času (a hlavně během odhalování jeho možností) se ukázalo, jak se věci mají. LiveUser totiž mj. obsahuje i rozšířené možnosti administrace uživatelů, o něž byl určitě zájem, a jelikož je najdete v balíčku LiveUser_Admin, který je určen k spolupráci s LiveUser...

Máte tedy v ruce nástroje, kterými uživatelům přidělujete privilegia, sdružujete je do skupin (hierarchická struktura), které můžete volitelně opatřit výchozími privilegií a co by to bylo za systém, který by neuměl z libovolného prává vyvodit jiné (např. WRITE může implikovat READ). Každé právo lze také opatřit atributem, kterému typu uživatele smí být přiřazeno, a tak vzniká rozlišení na uživatele admina a uživatele řadového. Možností administrace práv je ještě o něco více a najdete je v dokumentaci. LiveUser_Admin definuje základní rozhraní pro práci s právy, které rozšiřují tři kategorie tříd lišící se právě v nabízených možnostech. Jmenovitě se jedná o kategorie:

• Simple - libovolné právo lze přiřadit libovolnému uživateli.
• Medium - přidává k Simple skupiny (možnost přiřadit skupině práva a uživatele).
• Complex - všechny dokumentované vlastnosti.

Autoři vyzdvihují jednoduchost migrace mezi těmito kategoriemi díky jednotnému veřejnému rozhraní. Je nutno podotknout, že plnou funkcionalitu nabízí LiveUser_Admin jen pro práva uložená v RDBMS přístupném prostřednictvím PEAR::DB nebo PEAR::MDB. Kategorie Simple je dostupná pro XML soubory.

LiveUser a LiveUser_Admin tvoří dvojici, která by měla stačit i pro náročnější systémy. V rámci dokumentace projektu je dostupný i užitečný tutoriál, který vám oproti čtení zdrojových kódů ušetří trochu času. Dokumentace na webu ovšem není zdaleka úplná a plné využití schopností balíčku vyžaduje náhled do zdrojových kódů.

       

Komentáře

[Michal Kubeček]

Klasická chyba: (skoro) celý článek je o autentizaci, ale autor ji důsledně nazývá autorizací.

[Robert Krátký]

Je to vlastně moje chyba, že to tak vyšlo. Autor mě na svůj přehmat upozornil, ale já na to ve spěchu zapomněl. Omlouvám se.

[Pavel 'lingeek' Szalbot]

Autentizace (slovo, které jsem ve slovníku češtiny nenašel, ale mám jen 'malé' vydání) = ověřování identity uživatele nebo procesu - ve článku nazývám ověřováním, systémem ověřování

Autorizace (pro změnu v češtině existuje) - ověření, zda má uživatel příslušná práva přístupová práva

Viz základy 'autentizace', autorizace.

[jkt]

a nabízí se tak otázka jestli by nebylo vhodné poohlédnout se

nema bejt pred "jestli" carka?

[g!]

A nema veta zacinat velkym pismenem? :)

[Jan Kundrát (jkt)]

`diff -u článek komentar` :-P

[Filip]

Tak nějak bych od diskuze čekal pár slov k danému tématu, vlastní zkušenosti apod. a nikoliv debatu o tom, jak se článek jmenuje nebo má jmenovat, kde chybí čárka a jiný nesmysly...