2010-06-12 10 views
5

Attualmente mi sto solo usando qualcosa di simile nella tabella DB:Qual è il modo efficiente per creare un sistema di autorizzazione?

access: home,register,login 

E poi in ogni pagina:

if(!Functions::has_rights('content')) 
{ 
    Functions::noAccess(); 
} 

c'è modo più efficace per farlo con php & MySQL? Potrei voler accedere anche a più parti di una pagina, ad esempio, l'utente può leggere una pagina, ma non commenta e non voglio creare un sistema separato per ogni modulo.

risposta

3

Credo che quello che stai cercando è Access Control List in cui si modella il vostro problema in due cose: oggetti e ruoli.

Non voglio imporre, ma utilizzando un framework è efficiente Credo, Zend Framework prevede che, date un'occhiata here

È anche possibile cercare alternative per "PHP ACL", in this SO question.

+0

Zend_Acl è l'unico ZF che uso in uno dei miei siti ed è meraviglioso.A meno che tu non voglia passare attraverso la teoria dell'ACLness per saperne di più (cosa che spesso mi piace fare) consiglio vivamente di lasciarlo lì. – Hans

3

Ne ho costruito uno utilizzando un sistema di autorizzazione "* tipo NIX".

Ho diversi tipi di permessi per una pagina (leggi, modifica, cancella, commenta, vota) e assegno un po 'a ciascuno di questi.

Così, per esempio devo

define ('USER_CANREAD', 1); 
define ('USER_CANMODIFY', 2); 
define ('USER_CANDELETE', 4); 
define ('USER_CANINSERT', 8); 
define ('USER_CANCOMMENT', 16); 
define ('USER_CANVOTE', 32); 

Poi, se l'utente può leggere, commentare e votare il permesso sarà 1 + 16 + 32 = 49

Per controllare i permessi Faccio solo un bit per bit E con quei valori.

Per esempio user->permissions & USER_CANDELETE per verificare se l'utente può cancellare la pagina (ovviamente ho una funzione canDelete per questo)

1

Se si utilizza un qualche tipo di instradamento avrà senso per rendere il vostro ACL (Access Control List) dipende dal routing che hai definito.

Di solito vengo eseguito con una tabella delle autorizzazioni e una tabella permissions_users in una relazione HABTM. In questo modo quando il routing è abbinato, è possibile cercare un permesso. Se l'utente non ha il permesso gli viene negato l'accesso. Questo può essere migliorato controllando i diversi tipi di metodi GET, POST, PUT e DELETE.

Questo perché mi piace l'opportunità di modificare le autorizzazioni e le impostazioni dall'interfaccia web e consentire a persone che non lo fanno di fare lo stesso (cioè persone di marketing).

Ecco il layout:

+-----------------------+ 
| permissions   | 
+-----------------------+ 
| id | pattern | method | 
+-----------------------+ 
| 1 |   | GET | # => Will hit the root of your application 
| 2 | users  | GET | # => Will hit users/, usually listing the users 
| 3 | users  | PUT | # => Will hit anyone trying to insert a new user into the system. 
| 4 | users/:id | GET | # => Will hit anyone who tries to view a specific user 
| 5 | users/:id | POST | # => Will hit anyone trying to update a user 
+-----------------------+ 

+-------------------------+ 
| permissions_users  | 
+-------------------------+ 
| user_id | permission_id | 
+-------------------------+ 
| 1  | 1    | # => Will allow to view the root of the application 
| 1  | 2    | # => Will allow to view the users list 
+-------------------------+ 

Quindi utente 1 non ha alcun diritto che potrebbero alterare i record. E poiché il routing definisce dove vanno i diversi metodi di richiesta, non puoi semplicemente POST agli/utenti per visualizzare l'elenco.

Problemi correlati