My Developpement Blog

Un plugin

class ND_Controller_Plugin_Maintenance extends Zend_Controller_Plugin_Abstract
{
    public function routeShutdown(Zend_Controller_Request_Abstract $request)
    {
        $request->setActionName('index');
        $request->setModuleName('default');
        $request->setControllerName('maintenance');
    } 
}

un controlleur

<?php
 
class MaintenanceController extends ND_Controller_Action {
 
	public function indexAction(){}
 
}

une vue

<h1><?php echo $this->translate('site.unavailable.title');?></h1>
 
<?php echo $this->translate('site.unavailable.content');?>

une ligne dans le application.ini à décommenter en cas de maintenance

; resources.frontController.plugins.maintenance  = "ND_Controller_Plugin_Maintenance"

Ne reste plus qu’a :

• permettre de gérer la mise en/sortie de maintenance via le système de gestion de l’application
• permettre de by-passer la maintenance selon des règles établies (IP/Authentification htaccess)

Merci à E.Schrade pour l’idée qui reste à appronfondir

Le Module User

Ce module doit permettre la création/modification/suppression de comptes utilisateurs ainsi que leur identification. Personnellement, je pense que ce module ne doit gérer que peu de données : - Login (doit être unique) - Mot de passe (enregistré sous forme de Hash) - Date de création - Date d’activation - Email (doit être unique)

Pourquoi ces choix

Email + Login

J’ai décidé de ne pas prendre l’email en tant qu’identifiant du compte, car cela permet à l’utilisateur de choisir son propre identifiant qui peut être plus court que son email.

Mot de passe hashé

Pourquoi choisir de hasher le mot de passe.

Pour 2 raisons :

• le système n’a pas besoin de connaître le mot de passe de l’utilisateur, il doit simplement savoir si le mot de passe est le valide. Cela évite une faille de sécurité en cas d’intrusion dans la base. Le mot n’étant pas “en clair”, celui-ci n’a que peu d’intérêt.
• pour sécuriser les utilisateurs, beaucoup de gens gardent le même mot de passe, quelque soit l’application qu’ils utilisent.

Comment sera hashé le mot de passe.

Le hashage sera obligatoire mais l’administrateur de l’application aura la possibilité de choisir la manière dont il veut gérer cela.

Le grain de sel sera paramétrable

• choix du champs permettant de faire le générer ( Login / Date de création / email )
• choix de la méthode de hash ( md5 / sha1 / autre ) du champ
• choix dans la taille du grain de sel

Le hash se fera ensuite

• position du grain de sel (avant ou après le mot de passe)
• choix de la méthode de hash ( md5 / sha1 / autre )

Ce système empêche qu’un même mot de passe est le même hash.

Pourquoi avoir une date de création et une date de validation

Ce choix se justifie par le simple fait de purge de la base, un compte n’ayant pas été validé X jours après sa création est probablement un compte mort, donc un espace perdu.

Comment gérer les autres données

A ce système d’identification peut se greffer 2 autres tables permettant de gérer un nombre infini de données utilisateurs supplémentaires. Cela permet une malléabilité a l’administrateur d’une instance du CMS dans le choix des données utilisateurs qu’il souhaite. Le système n’ayant besoin à la base que de pouvoir identifier l’utilisateur

la table User_Field

Cette table permet à l’administrateur de choisir les informations de l’utilisateur qu’il souhaite La table contiendrait 3 voire 4 champs hors identifiant.

• name, nom pour l’administrateur
• i18n_name, variable que remplacera le système d’internationalisation
• required, permet de rendre obligatoire un champ
• validator, devrait permettre de valider ou non l’information saisie (Peut être externaliser cela dans un autre table afin de pré créer des règles de validation)

la table User_Data

Cette table permet d’associer un utilisateur, une donnée et sa valeur.

Voilà, je pense que tout est dit, si vous avez des remarques à faire, n’hésitez pas