Setup permissions on ZenTracker is very simple and quick to do.
It's like an htaccess : you can choose your ACL (Access Control List) without editing the source code.
I. The "security.yml" file
ZenTracker is working around modules which handle a specific part of the tracker. You can secure the whole application at top level (in /apps/frontend/config/) and/or in each module (/apps/frontend/forums/config/). It's working around the
cascade concept.
The security is configured by a simple "security.yml" file.
The cache must be erased each time you edit a file like it. Remember that ZenTracker reads only once your config files ;)
The first part of the file is the name :
- "
index" : the main action of the controller (when website.com/module is called)
- "
all" : every action of the controller
-
... : name of an action of the current controller
The second part is
indented by 4 spaces (
DON'T USE TAB !) and you can use 2 parameters :
- "
is_secure" : if true, only authenticated users can call the action
- "
credentials" : which groups can reach this action
II. Credentials
There are 5 levels delivered by default in ZenTracker :
- "ban" and "val" : users can't auth
- "mbr" : normal
- "mod" : can edit/delete everything on the frontend
- "adm" : can access to the backend
When you're setting is_secure to true, banned and pending validation users aren't able to reach the secured part. User must passed the auth process successfully.
When you're setting credentials to "[[adm, mod]]", only admins or moderators can reach the secured part. Authenticated members can't access to it.
III. Example
Code:
all:
is_secure: false
add:
is_secure: true
credentials: [[adm, mod]]
vote:
is_secure: true
Meaning : the whole module is reachable for every visitor (all is_secure false). But the "add" action requires an admin or a mod. And only authenticated users (members, admins and mods) can submit a vote.
IV. Before you go !
- Don't secure the main module and some actions in the member module for a dummy reason : people aren't able to login when you're secure the whole tracker.
- When using the cache system, authenticated users can see the action links for mods and admins in some cases. Don't stress it's normal : the entiere view (except the left panel side) is cached. They cannot reach the target of the link because the security filter is running before caching and execution's one.
================================================== ================================================== ======================
Configurer les permissions sur ZenTracker est vraiment très simple et rapide à faire.
C'est comme un htaccess : vous pouvez choisir vos ACL (Access Control List) sans toucher au code source.
I. Le fichier "security.yml"
ZenTracker repose sur des modules qui gère une partie spécifique du tracker. Vous pouvez sécuriser toute l'application (in /apps/frontend/config/) et/ou chaque module séparémment (/apps/frontend/forums/config/). ZT utilise le concept de
cascade.
La sécurité est configurée par de simples fichiers "security.yml".
Le cache doit être purgé à chaque édition d'un fichier comme celui là. Rappelez-vous que ZenTracker ne lit vos fichiers de configuration qu'une seule fois ;)
La première partie définit le nom de l'action :
- "
index" : l'action principale du controleur (quand website.com/module est appelé)
- "
all" : toutes les actions du controleur
-
... : nom d'une action du controleur
La seconde est
indentée par 4 espaces (
N'UTILISEZ PAS LES TABULATIONS) et vous pouvez utiliser 2 paramètres :
- "
is_secure" : si "true", seuls les utilisateurs connectés peuvent joindre la page
- "
credentials" : quels groups peuvent joindre l'action
II. Accès
Il y a 5 niveaux de permissions livrés par défaut avec ZenTracker :
- "ban" and "val" : la connexion est impossible
- "mbr" : normal
- "mod" : peuvent éditer/supprimer sur toute la partie "frontend"
- "adm" : peuvent accéder au backend
Quand vous mettez is_secure sur true, les bannis et les membres en instance de validation ne peuvent joindre la partie sécurisée. Les gens doivent passer le processus de connexion avec succès, sinon c'est mort.
Quand vous configuez les credentials sur "[[adm, mod]]", seuls les admins et les modos le peuvent. Les membres, mêmes connectés, ne peuvent joindre cette partie sécurisée.
III. Exemple
Code:
all:
is_secure: false
add:
is_secure: true
credentials: [[adm, mod]]
vote:
is_secure: true
Sens: l'ensemble du module est accessible à tous (all is_secure false). Mais l'action "add" est seulement accessible aux admins et modos. Et seuls les membres connectés (dont les admins et modos) peuvent voter.
IV. Avant de partir !
- Ne sécurisez pas le module principal ni certaines parties du module "membres" pour une raison toute conne : les visiteurs ne pourront même plus se connecter, même s'ils ont un compte.
- Quand vous utilisez le cache, les membres peuvent voir les liens de modération. Ne stressez pas c'est normal : toute la vue (sauf le volet gauche) est mis en cache. Ils ne pourront de toutes façons pas joindre la page de destination, car le filtre de sécurité est toujours exécuté avant l'exécution de l'action en question.