Bravo List

Bravo List (http://www.bvlist.com/index.php)
-   ZenTracker (http://www.bvlist.com/forumdisplay.php?f=81)
-   -   [Documentation]== Security Guide ==[EN & FR] (http://www.bvlist.com/showthread.php?t=7156)

Optix 2nd November 2011 22:34

[Documentation]== Security Guide ==[EN & FR]
 
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.


All times are GMT +2. The time now is 23:18.

Powered by vBulletin® Version 3.8.11 Beta 3
Copyright ©2000 - 2024, vBulletin Solutions Inc.