Common ruoli e livelli di accesso CMS

Question

Attualmente sto scrivendo un CMS e ricordo che qualcuno (sarebbe stato qui) criticare il CMS esistente per non avere un sistema di autorizzazioni utente abbastanza robusto. Ho un metodo di pianificato, ma sento che è caduto nella solita trappola di essere un po 'troppo a grana fine che rende la comprensione e l'attuazione di un orrore per gli utenti finali.

Credo che avere una vasta gamma di ruoli utente predefiniti con autorizzazioni sarebbe la risposta a questo, quindi suppongo che la mia domanda è questa:

Quali sono i ruoli predefiniti che si desidera vedere in un CMS e che tipo di permessi sarebbe associato con questi?

Grazie in anticipo!

Answer 1

Questa è la "best practice" Ho finito con, nella maggior parte dei progetti e sono molto felice con:

1. Ruoli

Quando si tratta di ruoli, vi consiglio una grande flessibilità, cioè la capacità di creare e definire gli account utente ei gruppi liberamente (ruoli come "collaboratore", "manager", ecc non sono hard-coded, ma messi in un file di configurazione che può essere modificato per ogni applicazione) . La configurazione ruolo è inaccessibile all'utente, ma il motore stesso deve essere esente da ruoli hard-coded.

2. Diritti

Diritti è dove le cose devono essere facile da capire e implementare .

Ho fatto ottime esperienze di lavoro con, e controllo contro, i diritti a grana molto fine sulla / livello di API codice :

• vedere
• Visualizza
• modifica
• cambio di nome
• rinomina
• Elimina
• mossa
• diritti di cambiamento
• ecc.

ma l'utente non vede mai quelli . Per loro, sono raggruppati in un numero molto piccolo di "gruppi di destra":

• di sola lettura
• Modifica
• Amministrazione = Sposta, cambia ....

L'utente non vede mai il "movimento" a destra, ma solo il gruppo di diritti "Amministra".

In questo modo, conservano tutta la potenza dei diritti a grana fine nel codice per il futuro - si può, per esempio, comodamente ospitare per una regola come "stagisti devono essere in grado di modificare le pagine , ma non in grado di cambiare i loro titoli, né di cancellarli", aggiungendo una risorsa preziosa per il CMS. Per l'utente finale, questa funzionalità rimane invisibile, e il sistema dei diritti facile da usare.

Answer 2

I fatto questa domanda un po 'di tempo fa e ha ottenuto la seguente risposta.

admin           //Manage everything
manager         //Manage most aspects of the site
editor          //Scheduling and managing content
author          //Write important content
contributors    //Authors with limited rights
moderator       //Moderate user content
member          //Special user access
subscriber      //Paying Average Joe
user            //Average Joe

Answer 3

Hai studiato esistente soluzioni come RBAC ? Mentre un tale sistema sarebbe molto probabilmente essere eccessivo completo per il particolare dado si sta cercando di rompere sarebbe almeno contribuire a rafforzare la fiducia che sei sulla strada giusta.

A parte questo, i ruoli generali che ci si aspetterebbe sarebbe lungo le linee di:

Administator - il controllo totale del sistema, in grado di visualizzare i registri (come si dovrebbe essere accede tutte le modifiche ), ecc plus ...

Editore - Può mettere in diretta contenuti plus ...

Autore - Può creare contenuti

Tuttavia, come questi ruoli vengono applicati in tutto il sistema è dove le cose si fanno difficili, come un utente specifico dovrebbe presumibilmente avere diritti diversi a diversi contenuti aree / moduli.

Answer 4

Per la maggior parte delle applicazioni, quindi penso che sarà vero per CMS e, miei clienti di solito preferiscono un approccio orientato ai diritti. Ecco come va:

1. elencare le azioni principali. Nei tuoi CMS che sarebbe: Creare e modificare i contenuti; Eliminare il contenuto; Classificare / categorizzare i contenuti; Convalidare il contenuto; Pubblicare contenuti; Gestire gli utenti; Ecc.
2. È possibile definire quali azioni sono consentite o negate per ogni utente

Per rendere le cose un po 'meglio, è possibile creare diversi ruoli (Editor; amministratore) di rendere la creazione di utenti tipici più facile (da pre-compilando il modulo quando si sceglie un ruolo)

.

Answer 5

Ho un CMS personalizzato costruito su Zend Framework che utilizza ACL di Zend per estende alcuni ruoli fondamentali (in modo da poter negare le risorse appositamente per gli utenti aggiuntivi o consentire ad altri di accedere alle risorse che normalmente non potevano). I miei ruoli fondamentali vanno da utenti CMS tutta la strada fino al sito web del "membri" come segue (mi basta usare una tabella agli utenti di archiviare tutta la mia autenticazione).

Developer

Modifica qualsiasi contenuto, modificare i layout, le impostazioni di configurazione. Utilizzare strumenti speciali che possono chiamare gli script di shell e posti di lavoro vigenti cron.

Ammin

Modifica qualsiasi contenuto, modificare i layout, le impostazioni.

Autore

Modifica contenuto.

gli

Può visualizzare la schermata di login, password dimenticata e bug report.

Ora, Zend ha una bella implementazione di ACL in modo da poter facilmente estende la classe ACL di base e aggiungere nuovi ruoli che si estendono dai ruoli di base. Quindi potrei fare un "Admin" che ha accesso a uno degli strumenti per sviluppatori (ad esempio spurgo o della cache di gestione) o bloccare un autore solo in grado di gestire i blog (e non, ad esempio news).

Answer 6

Non vorrei necessariamente respingere il sistema di controllo a grana fine che hai ora. Se si dispone di uno che è concentrarsi sul adattabile nascondersi la complessità fornendo un'interfaccia semplificata (ad esempio l'uso del modello di facciata o il modello di adattatore). I vantaggi sono che fornire agli utenti con la versione semplificata (permessi semplici come 'admin' puo 'eliminare' un 'post') pur mantenendo le caratteristiche di grana fine si dovrebbe bisogno di loro in seguito (ad esempio, più complicata la gestione il permesso è quello di permettere di eliminare posts quando il post è il proprio posto nella categoria X). Poi si può fornire un'alternativa alla versione semplificata per quel bisogno in alcuni luoghi.

Answer 7

Ammin : Quello con tutti i diritti

Autore : Colui che ha tutti i diritti di un contenuto specifico (come un autore del blog che possiede il blog), ha anche le autorizzazioni per aggiungere / invitare gli utenti a collaborare / visualizzare il contenuto

Collaboratore : L'unico che può modificare / aggiungere contenuti a cui l'autore ha dato i diritti, non può eliminare il contenuto o invitare / aggiungere altri collaboratori

Visualizzatore : L'unico che può visualizzare il contenuto se l'autore ha invitato a visualizzare

Editor : L'unico che può approvare / modificare tutti i tipi di contenuti

Avere un controllo a grana fine non è una cattiva idea se si prevede che gli utenti avanzati / sviluppatori di utilizzare il CMS. Ma per i manager CMS alle prime armi, i ruoli di base rendono il sistema molto più usabile.

Answer 8

amministratore - possono creare utenti + tutti al di sotto

Editor - può modificare i messaggi altrui + tutti al di sotto

Autore - può scrivere i messaggi, modificare i propri post

Answer 9

Creatore -. Responsabile della creazione e la modifica dei contenuti

Editor - responsabile per accordare il messaggio contenuto e lo stile di consegna, compresa la traduzione e la localizzazione.

Editore - responsabile del rilascio della contenuti per utilizzare.

Amministratore - responsabile per la gestione degli accessi autorizzazioni per cartelle e file, di solito compiuto assegnando diritti di accesso a gruppi di utenti o ruoli.

Consumer, spettatore o guest - la persona che legge o altrimenti prende nel contenuto dopo la pubblicazione o condivisa.