Acl completo in php

[Uno]

Vediamo se mi date una mano ad inquadrare come posso fare al meglio una cosa.

Vorrei implementare un sistema in cui ci sono:

1. utenti e gruppi
2. risorse (per esempio una pagina, ma anche una parte di essa per esempio un form o un pulsante)
3. azioni (per esempio la tal risorsa la posso leggere, la posso cancellare, la posso modificare etc)

Non mi dite di usare un framework o una classe già pronta tipo phpgcl o tackle (mi piacciono entrambe ma non mi va di usare adodb o modificarle) .
Ho un vuoto da stamattina (vabbeh che sto facendo altre cose e ci ho pensato solo in doccia ) e non riesco a trovare il sistema più logico per fare questa cosa.

L'unica che mi viene in mente al volo è creare le tre tabelle: user, risorse, azioni (4 con gruppi) e poi una tabella che collega le tre (4) a seconda dei casi.
Ma poi? Ogni volta costruisco un array tridimensionale (anzi quadrimensionale) per vedere se tizio del gruppo x in quel determinato punto può fare quella determinata azione su quella risorsa (quel punto appunto)?
Funzionerebbe, ma mi pare troppo complicato e dispendioso in termini di risorse.

Altrimenti meno dispendioso è sulla pagina stessa (che sarà uguale per x pagine, es un blog, un forum etc) stabilire delle risorse/azioni fisse per quel tipo di modulo e avere già dei campi in db sulla stessa tabella della pagina.

Il primo mi piacerebbe di più così è più semplice scrivere nuovi moduli o forse no tutto sommato....

Help.... intanto mi faccio un caffè

[Uno]

Meno male che mi ha salvato la doccia di questa mattina....
Se aspettavo voi, prrrrrr

[Kuro]

Meno male che mi ha salvato la doccia di questa mattina....
Se aspettavo voi, prrrrrr

a chi lo dici... la doccia e il wc aiutano sempre

ci sono svariati metodi per fare un acl, due sono quelli che hai postato (volendo nel primo bastano 3 tabelle) dipende da quanto flessibile vuoi che sia.
Ho usato per molto tempo il primo metodo con array multidimensionali, ora adopero un altro metodo basato sugli operatori bitwise, ma è adatto solo se utilizzi i pochi gruppi e non è molto flessibile (nel senso che tiene conto solo dei gruppi e non dei singoli utenti)

[andrea.paiola]

Nel mio framework ho trovato comodo usare una struttura tipo

Tabella: User
id name email password date type eccetera


Tabella: Privileges
id type type_user type_contents

Tabella: Contents
id author name content type sonof created modified eccetera...

così ogni utente appartiene ad un determinato tipo che quindi ha determinati permessi per determinati tipi di contenuti...

l'implementazione con PHP è anche piuttosto semplice... quando un utente fa il login se vuoi puoi memorizzare in sessione i suoi privilegi... ti copio-incollo un paio di funzioni della mia classe

    /** 
     * Get the privileges of the user 
     * @param $db PDOStatement 
     * @return $privileges array Array containing the privileges  
     * of the user 
     */ 
    function getPrivileges($db) 
    { 
        $privileges = array();         
        foreach($db->fetchAll(PDO::FETCH_ASSOC) as $row)  
        { 
            $privileges[]=array($row['type_contents']=>$row['type']);             
        }         
        return $privileges; 
    } 
    /** 
     * Check if the type of user can execute an action on a type 
     * of content 
     * @param $arr Usually an array generated by FW_User::getPrivileges 
     * @param $type_contents string The type of contents 
     * @param $type string The type of user 
     * @return $has boolean Default FALSE, but when the user has  
     * the privilege to do the action on a type of contents become TRUE 
     */ 
    function hasPrivilege(array $arr, $type_contents, $type) 
    {         
        $has = FALSE; 
        foreach($arr as $row) 
        { 
            if( isset($row["$type_contents"]) || isset($row['all']) ) 
            { 
                if( $row["$type_contents"]==$type || $row["$type_contents"]==='all' ) 
                { 
                    $has = TRUE; 
                } 
            }         
             
        } 
        return $has; 
    } 

io la trovo molto comoda

[guest]

Hey, metti una licenza, altrimenti io te la prendo, la brevetto e poi ti denuncio per plagio.

[andrea.paiola]

non penso di aver rivoluzionato la programmazione o il Web con l'ACL

non è che tutti i problemi han soluzioni complicate

[Uno]

Nel mio framework ho trovato comodo usare una struttura tipo

Tabella: User
id name email password date type eccetera


Tabella: Privileges
id type type_user type_contents

Tabella: Contents
id author name content type sonof created modified eccetera...

così ogni utente appartiene ad un determinato tipo che quindi ha determinati permessi per determinati tipi di contenuti...

l'implementazione con PHP è anche piuttosto semplice... quando un utente fa il login se vuoi puoi memorizzare in sessione i suoi privilegi... ti copio-incollo un paio di funzioni della mia classe

    /** 
     * Get the privileges of the user 
     * @param $db PDOStatement 
     * @return $privileges array Array containing the privileges  
     * of the user 
     */ 
    function getPrivileges($db) 
    { 
        $privileges = array();         
        foreach($db->fetchAll(PDO::FETCH_ASSOC) as $row)  
        { 
            $privileges[]=array($row['type_contents']=>$row['type']);             
        }         
        return $privileges; 
    } 
    /** 
     * Check if the type of user can execute an action on a type 
     * of content 
     * @param $arr Usually an array generated by FW_User::getPrivileges 
     * @param $type_contents string The type of contents 
     * @param $type string The type of user 
     * @return $has boolean Default FALSE, but when the user has  
     * the privilege to do the action on a type of contents become TRUE 
     */ 
    function hasPrivilege(array $arr, $type_contents, $type) 
    {         
        $has = FALSE; 
        foreach($arr as $row) 
        { 
            if( isset($row["$type_contents"]) || isset($row['all']) ) 
            { 
                if( $row["$type_contents"]==$type || $row["$type_contents"]==='all' ) 
                { 
                    $has = TRUE; 
                } 
            }         
             
        } 
        return $has; 
    } 

io la trovo molto comoda

Sto implementando una cosa simile anche se un pò diversa, grazie per il feedback

[andrea.paiola]

beh dai dicci cosa stai implementando

[rtacconi]

Io, per una intranet ho usato RBAC. E` una sistema tipo le ACL ma piu` orientato alle risorse ed a quello che i ruoli possono fare sulle risorse.

Ho una tabella con i ruoli, una che collega gli utenti ai ruoli, una chiamata ACL che collega un po` tutto. Nella tabella ACL ho un capo con una relazione polimorfica, cioe` che puo` mappare piu` risorse. Per risorse intendo pagine, file ed altri oggetti. Nella ACL ci ho messo il ruolo, le risorse e il tipo di permesso, view, modify e publish (i permessi stanno nella loro tabella). La cosa piu' importante riguarda come collegare la ACL alle risorse:

tipo_risorsa - articolo, file etc.
risorsa_id - chiave primaria della risorsa

Nella risorsa, per esempio articolo, potete recuperare le ACL tipo_risorsa articolo con id 33. Verificate se l'utente fa parte di uno dei ruoli contenuti nelle ACL trovate e vedete questo ruolo se puo` leggere, scrivere, pubblicare, autorizzare...

E` molto potente ma puo` essere molto complessa da gestire, quindi e` molto importante fare una interfaccia semplice ed intuitiva.

[Uno]

Io, per una intranet ho usato RBAC. E` una sistema tipo le ACL ma piu` orientato alle risorse ed a quello che i ruoli possono fare sulle risorse.

Ho una tabella con i ruoli, una che collega gli utenti ai ruoli, una chiamata ACL che collega un po` tutto. Nella tabella ACL ho un capo con una relazione polimorfica, cioe` che puo` mappare piu` risorse. Per risorse intendo pagine, file ed altri oggetti. Nella ACL ci ho messo il ruolo, le risorse e il tipo di permesso, view, modify e publish (i permessi stanno nella loro tabella). La cosa piu' importante riguarda come collegare la ACL alle risorse:

tipo_risorsa - articolo, file etc.
risorsa_id - chiave primaria della risorsa

Nella risorsa, per esempio articolo, potete recuperare le ACL tipo_risorsa articolo con id 33. Verificate se l'utente fa parte di uno dei ruoli contenuti nelle ACL trovate e vedete questo ruolo se puo` leggere, scrivere, pubblicare, autorizzare...

E` molto potente ma puo` essere molto complessa da gestire, quindi e` molto importante fare una interfaccia semplice ed intuitiva.

Si ho presente. E' molto potente, alla fine puoi gestire anche porzioni di pagina o singole immagini (per esempio) etc, il problema è che se non lo "replichi" diventa pesante su un sito grande.
Per replica intendo che dal mio punto di vista serve una sorta di cache (che di fatto è una replica) che accentra, per esempio in array, tutte le acl sugli oggetti di una pagina (per esempio) in modo da non dover rifare tutte le query ogni volta.

Io sto ancora valutando se gestire pagina per pagina o la categoria. Alla fine è forse inutile (e spreco di risorse) scendere a livello pagina se non in zone di "varie" intendo pagine che hanno un loro carattere autonomo e non parte di qualcosa, es, un thread di un forum etc...

[rtacconi]

Si ho presente. E' molto potente, alla fine puoi gestire anche porzioni di pagina o singole immagini (per esempio) etc, il problema è che se non lo "replichi" diventa pesante su un sito grande.
Per replica intendo che dal mio punto di vista serve una sorta di cache (che di fatto è una replica) che accentra, per esempio in array, tutte le acl sugli oggetti di una pagina (per esempio) in modo da non dover rifare tutte le query ogni volta.

Io sto ancora valutando se gestire pagina per pagina o la categoria. Alla fine è forse inutile (e spreco di risorse) scendere a livello pagina se non in zone di "varie" intendo pagine che hanno un loro carattere autonomo e non parte di qualcosa, es, un thread di un forum etc...

Di solito si sviluppano le applicazioni e poi individuiamo effitivamente dove sono i colli di bottiglia, invece di scegliere un design 'limitato' e poco flessibile. Comunque tutto e` relativo. Io uso quel sistema su un server Solaris multicore, che dovrebbe essere veloce ma che va piu` lento del mio PC con windows XP e P4. Il PC e` piu` veloce perche` uso Zend server che e` ottimizzato ed usa una cache di default, mentre il server Solaris a il PHP compilato e non ottimizzato.

Il collo di bottiglia della mia applicazione sta nel ORM, quando crea un oggetto per ogni record ma soprattutto un oggetto per ogni colonna di ogni record! Non usate Qcodo o Qcubed :-( Mentre la RBAC non da problemi. Posso dire questo perche` ho usato xdebug per verificare i tempi di eseguzione di ogni funzione.

Comunque se hai bisogno di qualcosa semplice basta usare una tabella con i gruppi, dove ci metti admin, editor, user...

Usare sistemi di caching come memcached o APC aiuta molto in ogni caso ed avere un ORM che puo` integrarlo in modo trasparente e` ancora piu` comodo.

[andrea.paiola]

sì forse conviene per categoria perchè comunque possono esistere categorie composte da una sola pagina quindi il problema delle singole pagine alla fine è risolto ;-)

[Uno]

sì forse conviene per categoria perchè comunque possono esistere categorie composte da una sola pagina quindi il problema delle singole pagine alla fine è risolto ;-)

Anche questo è vero, se ho una categoria "avviso" (esempio) e dentro solo la pagina index è come se avessi la pagina "avviso" anche sull'url rewrite.

[Uno]

Di solito si sviluppano le applicazioni e poi individuiamo effitivamente dove sono i colli di bottiglia, invece di scegliere un design 'limitato' e poco flessibile.

Io sono abituato a fare entrambe le cose, mi piace studiare prima la situazione migliore che riesco a concepire fin dall'uml (che spesso è solo mentale ).
Poi quando testo do un controllo ma di solito è più per sfizio che altro

Comunque tutto e` relativo. Io uso quel sistema su un server Solaris multicore, che dovrebbe essere veloce ma che va piu` lento del mio PC con windows XP e P4. Il PC e` piu` veloce perche` uso Zend server che e` ottimizzato ed usa una cache di default, mentre il server Solaris a il PHP compilato e non ottimizzato.

Anche questa è una cosa che è lontana dal mio modo di lavorare. Per me l'applicazione deve essere la migliore possibile a prescindere che giri sul commodore o su big blue.
Invece la cosa può essere relativa all'uso, questo si. Se devo sviluppare una piccola interfaccia per il mio desktop, interfaccia che occupa 200kb di ram quando la uso e la uso 2 volte al giorno, di certo non sto a guardare se invece che 200kb potrebbe lavorare con 180...
Ma se la stessa la devo mettere su un server dove più spazio c'è più roba metto (o più persone possono usarla), la cosa già cambia

Il collo di bottiglia della mia applicazione sta nel ORM, quando crea un oggetto per ogni record ma soprattutto un oggetto per ogni colonna di ogni record! Non usate Qcodo o Qcubed :-(

Non ci pensavo per nulla , ma comunque grazie per l'avvertimento.

Mentre la RBAC non da problemi. Posso dire questo perche` ho usato xdebug per verificare i tempi di eseguzione di ogni funzione.

Ma l'hai implementata con l'ORM?

Comunque se hai bisogno di qualcosa semplice basta usare una tabella con i gruppi, dove ci metti admin, editor, user...

No i gruppi li voglio e anche la possibilità di aggiungere azioni. L'unica cosa che sto valutando in più, tutto sommato, è la gestione delle risorse, non mi servono.
Userò le pagine, o meglio le categorie come risorsa ed ogni risorsa ha varie azioni (es posso leggere, posso scrivere, posso cancellare etc... ) che possono anche variare da categoria a categoria

[guest]

Riesumo.
Che voi sappiate, phpgacl quanti livelli di children gestisce?
Solo 1?

Perchè nella query 'get_group_children' c'è un bel where id = $group_id ed anche un parent_id = $group_id

e con una query del genere può beccare solo il parent stesso (id=) oppure il primo livello di figli, dove il parentid corrisponde al parent stesso.

un eventuale secondo livello non lo becca, perchè in tal caso il parent sarebbe impostato all'id di uno dei figli.

mi pare un po limitata come cosa...