Monthly Archives

3 Articles

Zend_Auth et Doctrine

Aujourd’hui, je reviens sur l’authentification. Mais attention, au lieu d’utiliser Zend_DB, je vais utiliser Doctrine et ce, grâce à un adaptateur développé à cet effet.

Pour commencer, Téléchargez la classe correspondante via ce lien. Ensuite, placez la dans votre projet afin d’avoir le chemin suivant : /library/App/Auth/Adapter/Doctrine.php.

Ensuite, en reprenant le tutoriel de Doctrine et celui de l’authentification, nous ne devrions pas avoir de mal pour se connecter avec cette classe.

Pour faire court, voici le script final (j’ai laissé les anciennes lignes en commentaires pour que vous puissiez faire la différence. Entre avant et après :

/application/modules/admin/controller/IndexController.php:

public function indexAction() {
    $this->view->title="Authentification utilisateur";

    $form = new Admin_Forms_Identification();
    $this->view->form = $form;
    $this->view->message = null;

    if($this->_request->isPost())
    {
        //on récupère le login
        $username = $this->_request->getPost('login');
        //on récupère le password                       
        $password = $this->_request->getPost('password');                   

        if (empty($username)) 
        {
            $this->view->message = 'Veuillez saisir un identifiant';
        } 
        else
        {
            //on récupère la connexion à la base de donnée
            //$dbAdapter = Zend_Db_Table::getDefaultAdapter();
            //récupération de la connexion à la BDD via la table Utilisateurs et Doctrine
            $dbAdapter = Doctrine::getConnectionByTableName('App_Models_Utilisateurs');
            //récupération de l'adaptateur dbAdapter                
            //$authAdapter = new Zend_Auth_Adapter_DbTable($dbAdapter);
            //récupération de l'adaptateur Doctrine. Nous l'initialisons avec la connexion à la BDD
            $authAdapter = new App_Auth_Adapter_Doctrine($dbAdapter);
            //on indique le nom de la table     
            $authAdapter->setTableName('App_Models_Utilisateurs');  
            //on indique la colonne du login                
            $authAdapter->setIdentityColumn('login');
            //on indique la colonne du mot de passe                     
            $authAdapter->setCredentialColumn('passwd');
            //on dit qu les mots de passes sont hashés en MD5
            $authAdapter->setCredentialTreatment('MD5(?)');                 

            //ajout des données du formulaire pour l'authentification
            $authAdapter->setIdentity($username);
            $authAdapter->setCredential($password);

            //lancement de l'authentification
            $auth = Zend_Auth::getInstance()->setStorage(new Zend_Auth_Storage_Session('admin')); 
            $result = $auth->authenticate($authAdapter); 

            Zend_Debug::dump($result);
            if ($result->isValid()) 
            {   
                //succès: on stoque dans un objet sessions toutes les infos de la ligne
                //de la table sauf le mot de passe pour des raisons de sécurité.
                $data = $authAdapter->getResultRowObject(null, 'user_password'); 
                $auth->getStorage()->write($data); 

                //on redirige vers notre page admin
                $this->_redirect('/admin/accueil');
            } 
            else 
            {
                //failure: clear database row from session
                $this->view->message = "Echec de l'identification";
            }       
        }
    }
}

Comme vous pouvez le voir, il n’y a pas beaucoup de changement par rapport à avant. En ce qui concerne l’utilisation de la session générée, elle est de la même structure et la déconnexion marche toujours de la même façon.

Voilà, maintenant, vous pouvez supprimer du site-test toutes les allusions à Zend_Db car maintenant, Doctrine domine partout.

Source: ZF Community Framework.

Optimiser Zend Partie 2 : mémoire

Optimiser Zend Partie 2 : mémoire

Aujourd’hui nous allons voir la suite de l’optimisation Zend. Je sais, ça fait un moment que je devais le faire mais là j’ai le temps.

Pour ce tutoriel je suis sur un unbuntu 10.04 LTS avec PHP5.3.2 et avec le cache APC activé. Les résultats que vous verrez povienne de tests sur mon site perso en temps réel en local afin que vous vous fassiez une idée sur la consommation d’un site vers la fin de son développement de la taille du mien.

Nous allons donc voir aujourd’hui la consommation mémoire de chacune de vos pages ou plutôt de vos actions, via un fichier de log généré par Zend. Ce log est généré par une fonction intégrée au bootstrap de votre projet. Je vais vous enseigner comment le mettre en place.

Nous verrons à la fin la charge mémoire du site avec les require_once laissés dans la library Zend (voir poste précédant) puis en les enlevant pour voir s’il y a une réelle différence.

La taille d’allocation mémoire calcule juste la mémoire utilisée par PHP dans le chargement des classes, données et l’exécution de vos scripts. Elle n’a rien à voir avec les images qui composent votre site.

Pour commencer, nous avons besoin du plugin Zend effectuant toute la partie traitement:

class App_Controller_Plugin_MemoryPeakUsageLog extends Zend_Controller_Plugin_Abstract
{
    protected $_log = null;

    public function __construct(Zend_Log $log)
    {
        $this->_log = $log;
    }

    public function dispatchLoopShutdown()
    {
        //récupère l'usage de mémoire utilisé réellement par PHP
        $peakUsage = memory_get_peak_usage(true);
        //on récupère l'url de la page en cours
        $url = $this->getRequest()->getRequestUri();
        //on stoque tout sa dans notre fichier de log avec le statut info
        $this->_log->info($peakUsage . ' bytes ' . $url);
    }
}

Et pour finir voici la fonction à ajouter dans notre bootstrap afin d’exécuter ce plugin automatiquement pour chaque page:

protected function _initEnableMemoryUsageLogging()
{
    //initialisation d'un fichier de log
    //il doit exister pour être utilisé.
    $writer = new Zend_Log_Writer_Stream(
    APPLICATION_PATH . '/logs/memory_usage');
    //création d'un log rattaché à notre fichier précédemment iinitialisé
    $log = new Zend_Log($writer);
    //on appelle un plugin s'occupant de tout ce traitement
    $plugin = new App_Controller_Plugin_MemoryPeakUsageLog($log);

    /**
     * Si vous mettez votre plugins avant tous les autres, ils seront
     * pris en compte dans le calcul de mémoire.
     */
    $frontController = $this->getResource('frontController');
    //on enregistre le plugin
    $frontController->registerPlugin($plugin);
}

Normalement, en allant sur la page d’index de votre page, le fichier memory_usage devrait avoir la ligne suivante:

2010-05-24T16:07:23+02:00 INFO (6): 20971520 bytes /throrinstudio/</code> 

La valeur affichée en bytes équivaut à 20 Mo environ. Si vous refaites un chargement de cette page, la mémoire a diminuée, ceci grâce au cache APC de PHP:

2010-05-24T16:08:33+02:00 INFO (6): 6291456 bytes /throrinstudio/

La valeur ici équivaut à 6,2 Mo environ. Maintenant nous enlevons les require_once de la library Zend et nous effectuons un autre test (il y a encore le cache APC) :

2010-05-24T17:09:27+02:00 INFO (6): 6029312 bytes /throrinstudio/

Ceci équivaut à 6 Mo. La différence n’est pas énorme mais mon site utilise peu de classes Zend. Si vous prenez un gros site intégrant Zend_AMF, Zend_DB et d’autres aussi gourmands, vous aurez une plus grande différence qu’ici. Idem si vous n’utilisez pas le cache APC. En purgeant le cache, j’arrive à la valeur suivante lors du premier chargement:

2010-05-24T17:09:16+02:00 INFO (6): 19922944 bytes /throrinstudio/

Ici, ça nous fait 19 Mo. Si nous regardons ce résultat par rapport au premier, nous arrivons à une différence de 1 Mo d’utilisation mémoire.

En conclusion, cette partie n’est pas vraiment une optimisation. Elle sert surtout à voir l’utilisation mémoire de votre site. Vous pouvez constater la différence d’utilisation mémoire avec et sans le cache APC. Cette différence est tout de même énorme (14 Mo dans l’exemple).

.htaccess et Active Directory 2008

.htaccess et Active Directory 2008

La dernière fois, je vous ai montré comment réaliser une connexion avec Active Directory par le biais d’un .htaccess. Ces tests étaient en fait effectués sur un serveur Windows 2000 et, ce week-end, j’ai effectué une migration d’Active Directory vers la version 2008.

Après cette migration, il se trouve que la connexion .htaccess ne fonctionne plus. J’avais l’erreur suivante dans les logs Apache2 :

auth_ldap authenticate: user bbe authentication failed; URI /testldap [ldap_search_ext_s() for user failed][Operations error]

Il faut juste modifier certaines lignes de notre fichier pour que le tout fonctionne. Voici donc une correction de mon précédent article :

AuthLDAPURL ldap://192.168.0.103:389/CN=Users,DC=virtual,DC=fr?sAMAccountName?sub?(objectClass=user)
AuthLDAPBindDN "CN=Nom complet utilisateur,CN=Users,DC=virtual,DC=fr"
AuthLDAPBindPassword password</code> Et vocii notre .htaccess global : <code lang="apache">AuthName "Warning : Restricted Area !!"
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL ldap://192.168.0.103:389/CN=Users,DC=virtual,DC=fr?sAMAccountName?sub?(objectClass=user)
AuthLDAPBindDN "CN=Nom complet utilisateur,CN=Users,DC=virtual,DC=fr"
AuthLDAPBindPassword password
require valid-user

Edit : Si vous voulez authentifier un groupe Active Directory voici les lignes à rajouter (merci à Azigui pour l’astuce) :

AuthLDAPGroupAttributeIsDN on
require ldap-group CN=Nom du groupe,DC=Virtual,DC=fr

Voilà, j’espère que maintenant vous n’aurez plus aucun problème à effectuer une authentification LDAP.