Bravo List
Register
Go Back   > Bravo List > Source Code > Archived Trackers > ZenTracker
Reply
  #1  
Old 2nd November 2011, 22:34
Optix's Avatar
Optix Optix is offline
Senior Member
 
Join Date: Sep 2011
France
Posts: 145
Lightbulb [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.
Reply With Quote
The Following 3 Users Say Thank You to Optix For This Useful Post:
Fynnon (5th March 2018), Phogo (22nd September 2012), romano1 (12th January 2013)
Reply

Tags
documentation , en , fr , guide , security

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



All times are GMT +2. The time now is 20:53. vBulletin skin by ForumMonkeys. Powered by vBulletin® Version 3.8.11 Beta 3
Copyright ©2000 - 2024, vBulletin Solutions Inc.