Tag Archives

6 Articles
Utilisation de Zend REST : Partie 2

Utilisation de Zend REST : Partie 2

Comme promis, voici la partie 2 du tutoriel sur Zend REST. Dans celui-ci, nous allons aborder les choses suivantes :

  • Création et Utilisation d’une APIKEY
  • Utilisation des différentes méthodes http et test des retours JSON avec CURL.
  • Mise en place de codes retours http pour dire s’il y a eu une erreur ou non

Sachez que ce tutoriel est le dernier concernant Zend REST. Le prochain touchera à l’accès sur notre plateforme REST via Android.

I- Création et utilisation d’une APIKEY :

1 – Introduction :

L’APIKEY sert aux utilisateurs à s’authentifier sur votre application simplement, sans avoir quelque chose à taper. Vous pouvez avoir une APIKEY globale (ce que l’on va voir ici), une par utilisateurs, une par plateforme ou un mélange de tout ceci à la fois. A vous de voir ce qui vous convient le mieux. Pour notre exemple, nous allons choisir le plus simple, une APIKEY gobale. Si la requête n’est pas envoyée avec cette APIKEY, elle renverra une erreur. L’APIKEY de notre example sera la suivante :

6a0071dbe561c89581c56d1ecf3a4f54

Pour ceux qui aimeraient savoir ce que c’est, cette APIKEY n’est qu’un simple MD5 de throrinstudio. 

2 – Mise en place :

Maintenant, il faut peut-être dire à Zend que nous voulons utiliser cette APIKEY et, si elle est mauvaise, refuser la requête. Nous allons donc créer un plugin pour notre Controller. Si vous ne savez pas ce que c’est, voici un petit rappel de la documentation :

L’architecture MVC de Zend Framework propose l’injection de plugins de code, qui vont intervenir à différents niveaux dans le processus complet. Le contrôleur frontal enregistre des plugins, et utilise un gestionnaire de plugins (« plugin broker »), qui va se charger de faire intervenir chaque plugin, à chacun des instants clés à votre disposition.

Donc, nous allons créer le plugin RestAuth suivant :

class App_Controller_Plugin_RestAuth extends Zend_Controller_Plugin_Abstract{

    public function preDispatch(Zend_Controller_Request_Abstract $request)
    {
        $apiKey = $request->getHeader('Api-Key');

        //on récupère notre fichier de configuration
        //car notre apikey est stoquée dedans
        $config = Zend_Registry::get('config'); 


        //Si notre apikey est mauvaise alors qu'on essaie d'accéder à notre module rest et qu'on est pas sur la page d'erreur, 
        //on renvoie vers la page d'erreur
        if($apiKey != $config['tutorest']['apikey'] && $request->getModuleName() == "rest" && $request->getControllerName() != "error") {
            //Ici, on met le code 403 ACCES_DENIED à notre réponse HTTP
            $this   ->getResponse()
                    ->setHttpResponseCode(403);
            //Et on redirige vers le controller d'erreur
            $request->setModuleName('rest')
                    ->setControllerName('error')
                    ->setActionName('api')
                    ->setDispatched(true);
        }

    }
}

Comme on peut le voir, on redirige en cas d’erreur sur un controller d’erreur créé pour l’occasion. Voici son code :

class Rest_ErrorController extends Zend_Controller_Action{

    public function init()
    {
        $bootstrap = $this->getInvokeArg('bootstrap');
        $options = $bootstrap->getOption('resources');

        $contextSwitch = $this->_helper->getHelper('contextSwitch');
        $contextSwitch  ->addActionContext('api', array('json'))
                        ->initContext('json');
    }

    public function apiAction(){
        $this->view->error = "APIKEY is wrong";
    }
}

Et maintenant, nous allons dire à Zend de charger notre plugin pour faire le test. Nous allons l’initialiser dans le Bootstrap de notre module Rest :

class Rest_Bootstrap extends Zend_Application_Module_Bootstrap
{
    protected function _initAutoload()
    {
            $moduleLoader = new Zend_Application_Module_Autoloader(array(
            'namespace' => 'Rest',
            'basePath' => APPLICATION_PATH . '/modules/rest'));
            return $moduleLoader;
    }

    protected function _initPlugins(){
        $bootstrap = $this->getApplication();
        $bootstrap->bootstrap('frontcontroller');
        $front = $bootstrap->getResource('frontcontroller');

        $front->registerPlugin(new App_Controller_Plugin_RestAuth());
    }
}

Maintenant, si vous essayez d’accéder au site via http://votresite/rest/ vous devriez avoir le JSON suivant :

{"error":"APIKEY is wrong"}
Attention, il se peut qu’à la place vous ayez le message suivant :  Fatal error: Uncaught exception ‘Zend_Exception’ with message ‘No entry is registered for key ‘config »… Si vous avez ce message, rien de grave, c’est que vous n’avez pas initialisé la variable de registre config à partir du Bootstrap principal. Si c’est votre cas, voici la fonction à rajouter :

protected function _initConfig()
{
Zend_Registry::set(‘config’, $this->getOptions());
}

Maintenant que nous avons mis en place l’apikey, nous allons voir comment la renseigner à notre requête.

3 – Utilisation :

Pour cette partie, nous allons effectuer nos requêtes via curl en ligne de commande linux. Ici j’utilise putty connecté sur mon serveur de test. Avant de pouvoir utiliser CURL, vous devez l’avoir d’installé sur votre machine. Si ce n’est pas le cas, faites le :

sudo apt-get install curl

Ensuite pour interroger le serveur comme le fait votre navigateur, vous aurez juste à taper la commande suivante. Attention, elle vous retournera la même erreur que par le navigateur.

curl http://localhost/tutosite/rest/tuto -v

Si vous avez bien regardé le plugin de vérification de l’apiKey, vous pouvez voir que l’on récupère cette clé directement dans le header HTTP de la façon suivante :

$apiKey = $request->getHeader('Api-Key');

Nous allons donc dire à CURL de rajouter une nouvelle en-tête à la requête HTTP du nom ‘Api-Key’ et contenant notre clé :

curl http://localhost/tutosite/rest/tuto -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

En retour vous devriez avoir le bon JSON. Voilà, maintenant vous savez comment renseigner votre api-key directement dans les headers HTTP. Maintenant nous allons passer aux différents types de requête.

II- Méthodes HTTP et REST :

1 – index et GET :

C’est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet. la méthode getAction() sera appelée lorsque l’on cherche à récupérer une ressource en particulier. Si nous ne demandons rien de particulier, c’est la méthode indexAction() qui est appelée à la place. Par exemple pour récupérer une liste, on va dans index, pour récupérer un livre en particulier, on va dans get. 

La commande curl précédente nous permettait d’aller dans notre méthode index. Pour accéder dans la méthode get, il suffit juste d’effectuer la commande suivante en renseignant dans le lien l’id de l’élément à chercher :

curl http://localhost/tutosite/rest/tuto/1 -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

En réponse vous devriez avoir le JSON correspondant à celui de getAction.

2 – POST :

Cette méthode doit être utilisée pour soumettre des données en vue d’un traitement à une ressource (typiquement depuis un formulaire HTML). L’URI fournie est l’URI d’une ressource à laquelle s’appliqueront les données envoyées.

Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP par les navigateurs, cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée à la fois pour la création et la mise à jour de ressources.

Voici la commande permettant de tester le POST :

curl -d "article=myarticle"   http://localhost/tutosite/rest/tuto/ -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

3 – PUT :

Cette méthode permet de remplacer ou d’ajouter une ressource sur le serveur. L’URI fourni est celui de la ressource en question. PUT et POST pourraient être tous les deux utilisés pour effectuer la même chose. Normalement j’utilise POST pour la création et PUT pour la modification. Après à vous de voir ce que vous préférez. Voici la commande permettant de tester le PUT:

curl -d "article=myarticle" -X PUT  http://localhost/tutosite/rest/tuto/ -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

4 – DELETE :

Cette méthode permet de supprimer une ressource du serveur. Normalement, après exécution de cette requête il ne devrait pas y avoir de réponse HTTP mis à par le status HTTP. Ici nous allons avoir un retour car nous n’avons pas établis les codes retours :

curl -X DELETE  http://localhost/tutosite/rest/tuto -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54

III- Codes retours :

Afin de savoir si nos requêtes se sont bien passées ou pas, nous regarderont le code retour HTTP avant de traiter le JSON de retour. Comme cela, nous saurons s’il s’agit d’un JSON de ressources à traiter, de confirmation, d’erreur, … Pour faire ceci, nous rajouterons à chacune de nos fonction la commande suivante :

$this->getResponse()->setHttpResponseCode($code);

Nous nous baserons sur les codes retour HTTP. Ce sera plus simple pour les traiter et en même temps ça servira de piqûre de rappel pour certains 😉 :

  • 200 : Requête traitée avec succès (utilisée pour index et GET
  • 201 : Requête traitée avec succès avec création d’un document (utilisée pour PUT et POST)
  • 204 : Requête traitée avec succès mais pas d’information à renvoyer (utilisée par DELETE)
  • 400 : La syntaxe de la requête est erronée (peut être utilisée si vous passez les mauvais paramètres de recherche et/ou d’ajout)
  • 403 : L’authentification est refusée. (utilisée quand APIKEY est invalide)
  • 404 : Ressource non trouvée (peut être utilisée dans GET et PUT/POST quand la ressource à récupérer/modifier n’existe pas)
  • 500 : Erreur interne du serveur (utilisée pour toute erreur PHP ou tests invalides autre que ceux gérés au dessus)
Après à vous de décider. Je n’ai pas mis toute la liste mais seulement l’énumération et les Use Cases des principaux codes de retour.

Le code de retour 204 ne retournera aucun contenu même si vous en renseignez un. Donc pour vérifier que l’action DELETE s’est effectuée avec succès, testez juste le code de retour. Si c’est 204, tout s’est bien passé.

Conclusion Partie 2.

Dans cette partie vous aurez vu comment toucher au header HTTP, comment modifier le code de retour et comment vérifier tout ceci sous Zend. Vous aurez aussi appris à vous servur de curl en ligne de commande (peut être un tutoriel sur curl et Zend dans un prochain tutoriel ?). Avec ceci vous avez toutes les bases pour créer votre propre service REST. La prochaine fois nous verrons comment consommer ce service grâce à une application Android. Sur ce, je vous souhaite une bonne fin de semaine.

Utiliser le debugger XDebug avec NetBean

Utiliser le debugger XDebug avec NetBean

by Throrïn 0 Comments

Après avoir vu comment configurer les différentes versions de Zend, développer en PHP, nous allons maintenant voir comment debugger son code simplement avec Netbean et l’extension PHP XDebug.

XDebug qu’est-ce exactement? XDebug est une extension PHP gérant toute la partie debug. Dès qu’il est installé et activé, si vous faites une erreur PHP, XDebug vous affiche l’erreur avec la pile d’erreur à côté afin de vous aider à la corriger :

Julien Pauli a rédigé un très bon article de présentation et d’utilisation de XDebug que je vous invite à lire. XDebug va surtout nous servir ici à effectuer du debuggage comme sous Java avec des breakpoints, savoir quelle sera la valeur des variables au moment du breakpoint et savoir surtout si votre programme tourne rond.

Avant de commencer, assurez vous que l’extension xdebug est bien présente sur votre serveur (lamp pour linux, wamp ou easyphp pour windows et mamp pour mac) via la commande php -m ou via le phpinfo. Si XDebug n’est pas installé, vous avez juste à l’installer via la commande suivante pour linux Ubuntu :

apt-get install php5-xdebug

Normalement, via php -m vous devriez obtenir ceci :

Si vous ne voyez pas XDebug dans la partie [Zend Modules], vous devez configurer l’extension comme ceci directement dans son fichier /etc/php5/conf.d/xdebug.ini :

zend_extension=/usr/lib/php5/20090626/xdebug.so

Ensuite relancez apache et le tour est joué. Maintenant, nous allons nous intéresser à la configuration de XDebug pour le faire fonctionner avec Netbean. Tout d’abord, pour que tout fonctionne, nous devons retoucher au fichier de configuration de XDebug comme ceci : /etc/php5/conf.d/xdebug.ini

zend_extension=/usr/lib/php5/20090626/xdebug.so

;on active le debug à distance
xdebug.remote_enable=on
;on utilise le protocole dbgp
xdebug.remote_handler="dbgp"
;le port à appeler pour debugger avec xdebug
xdebug.remote_port=9000
;IP du serveur XDebug, ici on pet l'ip d'eth0
xdebug.remote_host=192.168.128.128
;clé utilisée pour identifier notre ide
xdebug.idekey="netbeans-xdebug"
;permet la connexion à distance
xdebug.remote_connect_back=1

A la ligne 10, l’ip utilisée est l’ip du serveur où nous requetons. Si le serveur est en local par rapport à l’ide et au navigateur, nous aurions mis 127.0.0.1. Ici, vu que le serveur n’est pas sur la même machine que l’ide, nous mettons son ip sur le réseau. A la ligne 12, l’idekey est la clé rentrée dans votre ide, par défaut dans netbean, elle vaud netbeans-xdebug.

C’est pour ça que j’ai mis cette idekey. Maintenant que Xdebug est configuré comme il faut et votre serveur apache relancé, nous allons maintenant nous intéresser à Netbean. Pour debugger, j’utilise projet tout bête. Voici les sources : index.php

<html> 
    <body>
        <?php
            for ($index = 0; $index < 45; $index++) {
                echo $index;
            }
        ?>
    </body>
</html>

Rendez-vous dans netbean, faites clic droit sur votre projet => propriété. Ensuite rendez-vous dans la section Run Configuration et changez la ligne Project Url par l’adresse que vous devez rentrer dans votre navigateur pour accéder à votre projet.

 

Aller sur la page que vous voulez de votre projet puis rajoutez un point d’arrêt en cliquant une fois sur le numéro de la ligne souhaitée :

Vous êtes normalement prêt à debugger votre application mais avant ça, regardons de plus prêt la barre de debuggage de Netbean :

  • Bouton 1 : Lance le projet normalement
  • Bouton 2 : Lance le projet en mode Debug
  • Bouton 3 : Lance le projet en mode profilage
  • Bouton 4 : Arrête le mode Debug
  • Bouton 5 : Continuer jusqu’au prochain breakpoint
  • Bouton 6 : Exécute une ligne de source. Si la ligne de source contient un appel, il exécute toute la routine sans rentrer dans les instructions individuelles.
  • Bouton 7 : Exécute une ligne de source. Si la ligne de source contient un appel, s’arrête juste avant l’exécution de la première instruction de la routine appelée.
  • Bouton 8 : Sort de la fonction courante
  • Bouton 9 : Se déplace jusqu’au curseur

Maintenant il ne reste plus qu’à enregistrer les variables à surveiller lors du debug. Pour se faire, vous devez surligner la variable que vous voulez puis faire la manipulation CTRL + MAJ + F7. Normalement, vous devriez avoir la fenêtre suivante :

Pour voir vos variables, vous devez ouvrir la fenêtre « Variables » via le menu Fenêtres => Débogage => Variables ou via le raccourcis ALT + MAJ + 1. Et vous devriez avoir ceci en bas de l’ide :

Bien, il ne vous reste plus qu’à appuyer sur le bouton ] et de regarder ce qu’il se passe.

Normalement, Netbean lance le navigateur vers notre page web en mettant en argument ?XDEBUG\_SESSION\_START=netbeans-xdebug. Il envoie au serveur web que nous commençons une session de debug avec l’idekey netbeans-xdebug. Du côté de l’ide, on peut voir que le Curseur s’est positionné à l’entrée de notre balise PHP. (c’est la ligne verte).

En cliquant sur continuer , notre curseur s’arrête sur notre breakpoint et nous observons que notre variable $index change d’état.

Elle passe au type int avec comm valeur 0. Si on reclique sur continuer, on continue dans notre boucle et $index s’incrémente de 1. Voilà, avec cet exemple tout simple nous venons de voir comment debugger une application PHP.

Si vous avez un problème avec ce tutoriel, ou des questions, n’hésitez pas pas.

.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.

Installation de PHP 5.2 dotdeb sur Ubuntu

Installation de PHP 5.2 dotdeb sur Ubuntu

by Throrïn 0 Comments

Aujourd’hui je vais vous faire résoudre un problème récurent que j’ai eu sur mes serveurs. L’installation de PHP 5.2.13 sur Ubuntu en utilisant les paquets dotdeb.

Pourquoi passer par ces paquets ? Et bien c’est plus simple que de compiler soit même PHP et ça évite d’oublier des dépendances. Le problème des paquets dotdeb c’est qu’ils sont prévus pour Debian or, Ubuntu utilise des Library avec quelquefois des noms différents. Je vais donc vous expliquer pas à pas l’installation de cette version.

Cette procédure ne marche plus à partir d’Ubuntu 10.04 LTS. D’un car les dépendances ne sont plus disponibles, de deux car une version plus récente de PHP est disponible.

Tout d’abord, il vous faut ajouter les sources APT pour installer tout un serveur LAMP @dotdeb dans le fichier /etc/apt/sources.list:

deb http://packages.dotdeb.org stable all 
deb-src http://packages.dotdeb.org stable all

Ensuite, il vous faudra installer apache :

sudo aptitude install apache2 apache2-mpm-prefork apache2-prefork-dev apache2-utils apache2.2-common

Ensuite, si nécessaire, installez le serveur MySQL qui va bien:

sudo aptitude install mysql-client mysql-client-5.1 mysql-common mysql-server mysql-server-5.1 mysql-server-core-5.1

Pour finir nous allons installer toutes les Library requises pour l’installation de PHP.

sudo aptitude install libtidy-dev curl libcurl4-openssl-dev libcurl3 libcurl3-gnutls zlib1g zlib1g-dev libxslt1-dev libzip-dev libzip1 libxml2 libsnmp-base libsnmp15 libxml2-dev libsnmp-dev libjpeg62 libjpeg62-dev libpng12-0 libpng12-dev zlib1g zlib1g-dev libfreetype6 libfreetype6-dev libbz2-dev libxpm4-dev libmcrypt-dev libmcrypt4

Voilà. Malgré tout, il nous faut installer 3 Library introuvables par aptitude mais nécessaires à l’installation des paquets dotdeb. Nous récupérons les fichiers nécessaires avec l’utilitaire wget.

32bits:

wget http://us.archive.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb53_1.6.dfsg.4~beta1-5ubuntu2_i386.deb
wget http://us.archive.ubuntu.com/ubuntu/pool/main/i/icu/libicu38_3.8-6ubuntu0.2_i386.deb
wget http://mirrors.kernel.org/ubuntu/pool/main/libt/libtool/libltdl3_1.5.26-1ubuntu1_i386.deb

64bits:

wget http://us.archive.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb53_1.6.dfsg.4~beta1-5ubuntu2_amd64.deb
wget us.archive.ubuntu.com/ubuntu/pool/main/i/icu/libicu38_3.8-6ubuntu0.2_amd64.deb
wget http://mirrors.kernel.org/ubuntu/pool/main/libt/libtool/libltdl3_1.5.26-1ubuntu1_amd64.deb

Et nous installons les différents fichiers :

32bits:

sudo dpkg -i libkrb53_1.6.dfsg.4~beta1-5ubuntu2_i386.deb
sudo dpkg -i libicu38_3.8-6ubuntu0.2_i386.deb
sudo dpkg -i libltdl3_1.5.26-1ubuntu1_i386.deb

64bits:

sudo dpkg -i libkrb53_1.6.dfsg.4~beta1-5ubuntu2_amd64.deb
sudo dpkg -i libicu38_3.8-6ubuntu0.2_amd64.deb
sudo dpkg -i libltdl3_1.5.26-1ubuntu1_amd64.deb

Et voilà, il n’y a plus qu’à installer PHP :

sudo apt-get update
sudo apt-get install php5

Rajoutez les extensions utiles :

sudo apt-get install php5-apc php5-curl php5-gd php5-mcrypt php5-mhash php-pear php5-mysql

Voilà, maintenant vous avez un serveur LAMP fonctionnel avec PHP 5.2.13.

.htaccess et Active Directory

.htaccess et Active Directory

Aujourd’hui je vais vous parler de quelque chose d’assez spécial : L’authentification par apache de personnes à partir d’un annuaire Active Directory.

Pourquoi une telle chose ? Et bien il s’avère que ce n’est pas aussi simple que sa à mettre en œuvre mais quand on l’a fait une fois, on peut le refaire plusieurs fois facilement en copiant les règles dans un fichier « .htaccess ».

Vu que j’ai eu un peu de mal, je vais vous fournir les différentes étapes et le .htaccess final. Tout d’abord vous devez avoir un serveur Windows (2000, 2003 ou 2008) avec le rôle Active Directory. Moi j’ai effectué tout ceci sur un Windows Server 2000.

Ensuite, vous devez connaître votre nom de domine et la structure de l’arbre de votre annuaire. Pour vous aider, voici une application java que j’ai trouvée sur le net, permettant de réaliser ceci. Juste un conseil, laissez juste apparaître dans la base DN les DC=,DC=com.

Sachez que pour pouvoir parcourir votre annuaire, un compte Windows doit être utilisé, pour des raisons de sécurité, je vous conseil de créer un compte lambda avec un mot de passe bidon, non modifiable et verrouillé. Essayez de minimiser les droits de ce compte si un hacker vous le vole.

Pour cet exemple, sachez que je suis dans le domaine virtual.fr donc pour me connecté à mon serveur DNS ayant pour IP 192.168.0.12 je dois renseigner le DN suivant :

DC=virtual,DC=fr

Après avoir testé avec l’application, nous pouvons enfin nous attarder au fichier .htaccess. Vous devez tout d’abord activer les extensions apache2 authzn_ldap et ldap. Si votre .htaccess ne marche pas, activez le module rewrite.

Ensuite voici le fichier .htaccess

AuthName "Warning : Restricted Area !!"
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL "ldap://serveur.virtual.fr:389/DC=virtual,DC=fr?sAMAccountName?sub?(objectClass=*)" NONE
AuthLDAPBindDN "ldap@virtual.fr"
AuthLDAPBindPassword motpasse
require valid-user </code>

Donc je vais expliquer chaque ligne :

AuthName "Warning : Restricted Area !!"
# définit le message qui s’affichera sur notre fenêtre de connexion
AuthType Basic
# nous définissons une authentification dite basique
AuthBasicProvider ldap
# nous demandons de passer par les annuaires LDAP
AuthzLDAPAuthoritative off
# permet de dire que nous n’utilisons pas de certificat particulier 
# lors de la requête dans Active Directory
AuthLDAPURL "ldap://serveur.virtual.fr:389/DC=virtual,DC=fr?sAMAccountName?sub?(objectClass=*)" NONE
# url utilisée pour aller effectuée notre requête. Nous demandons d’aller vérifier le nom de compte
# à partir de n’importe quelle classe d’objet de notre annuaire mais ayant pour contrainte d’appartenir
# au domaine virtual.fr
# Le NONE veut dire qu'on utilise aucun protocole de sécurité
AuthLDAPBindDN ldap@virtual.fr
# définit le login du compte de test 
AuthLDAPBindPassword motpasse
# et là son mot de passe
require valid-user
# pour finir nous acceptons d’afficher le site si seulement l’utilisateur entré est valide.

Voilà. Si vous ne voulez pas vous embêter avec les sessions utilisateurs ou si l’espace est réservé aux personnes enregistrées dans votre annuaire, cette méthode s’avère assez simple à mettre en place. Vous pouvez aussi ajouter différentes contraintes comme le groupe, le poste de travail à utiliser, …