Jeudi 03 Juillet 2008 à 05h26::Serveur webIIS 7 et ASP 3

Il y a peu j'héritais d'un nouvel ordinateur équipé de Windows Vista, et par là même du serveur IIS 7. Nouvelle machine, nouveau paramétrage, tout a changé avec IIS 7 et même si l'interface est déroutante à la première approche, on finit par retrouver ses marques et la configuration du serveur, bien plus modulaire qu'auparavant, permet de peaufiner ses réglages aux petits oignons. D'ailleurs, l'installation de PHP devient vraiment un jeu d'enfant.

Reste qu'il a fallu réinstaller - pour une mise à jour au demeurant dérisoire - un ancien site daté de 2001 mais toujours en ligne. Ce site étant développé avec l'obsolète technologie ASP et un moteur de base de données Access (personne ne rigole, à l'époque, c'était 'achement répandu!), il a fallu procéder à la mise en place de ce module dans IIS.

Pour la base de données, aucun souci : installation d'Access 2003, la compatibilité descendante est assurée.

En revanche, ce vieil ASP n'est pas inclus par défaut lors d'une installation standard de IIS 7, et paramétrer cette fonctionnalité est loin d'être intuitive. Voici donc pêle mêle les étapes que j'ai dû suivre pour réactiver ce module :

Service Pack 1 de Windows Vista obligatoire

M'étant mis à jour avec le SP1 avant d'installer le module ASP, je ne peux attester de la véracité de cette information. D'après mes lectures, il corrige un problème de fonctionnement avec Access. Donc si vous obtenez ce message d'erreur :

"Microsoft JET Database Engine error '80004005'
Unspecified error"

Commencez par installer le Service Pack 1 de Vista.

Activer le module ASP pour IIS 7

Comme expliqué précédemment, le module ASP classique n'est pas actif lors d'une installation standard de IIS. Il vous faut personnaliser l'installation en allant dans les "Fonctionnalités Windows". Rechercher la coche correspondant au libellé "ASP" et procédez à l'installation :

Activer l'affichage des erreurs détaillées

Par défaut, si votre code ne fonctionne pas, vous obtenez un message d'erreur classique et peu bavard :

"An error occurred on the server when processing the URL. Please contact the system administrator."

Pour retrouver les messages d'erreur détaillés, soit vous tapez la ligne de commande suivante :

%windir%\system32\inetsrv\appcmd set config -section:asp -scriptErrorSentToBrowser:true

Soit vous passez par l'interface graphique de IIS et vous changez la valeur "Envoyer les erreurs au navigateur" de "false" à "true" :

Autoriser les chemins relatifs

Enfin, le dernier paramétrage que j'ai du mettre en place concerne le message d'erreur suivant :

"Active Server Page (ASP) erreur 'ASP 0131'
Chemin parent non autorisé
Le fichier Include '../monfichier.asp' ne peut pas contenir '..' pour indiquer le répertoire parent"

Encore une fois, soit on tape la ligne de commande suivante :

%windir%\system32\inetsrv\appcmd set config -section:asp -enableParentPaths:true

Soit on va dans l'interface et on modifie la ligne "Activer les chemins d'accès relatifs au parent" :

Toutes les informations répercutées dans ce billet proviennent de l'excellent article Tips for classic asp developers on iis7.

Samedi 28 Juin 2008 à 06h31::PHP | Serveur webAuthentification windows intégrée

Un collègue m'a demandé s'il y avait moyen d'obtenir le nom d'utilisateur du domaine lorsqu'un internaute se connecte à une application web utilisant PHP comme moteur de script.

Ma première réponse fut négative, PHP travaillant côté serveur, il ne pouvait détenir cette information, et côté client, JavaScript ne peut pas accéder à ce genre d'informations pour des raisons de sécurité évidentes.

Puis, en forçant un peu ma réflexion, je me suis souvenu qu'au niveau de IIS existe dans les options d'authentification la notion de "connexion Windows intégrée". Il faut prendre soin toutefois de désactiver l'authentification anonyme, cette dernière prenant le pas sur la connexion intégrée.

Bingo! Lorsque cette option est enclenchée, le nom de l'utilisateur apparaît dans les variables serveur et devient donc accessible via la variable globale $_SERVER["AUTH_USER"]. Cela permet d'éviter, dans le cadre d'un intranet, l'étape d'identification "classique" par login/mot de passe, en utilisant de préférence l'identité utilisateur issue de l'Active Directory.

Cette option est spécifique à IIS, et fonctionne avec Internet Explorer 2 et supérieur. En cas d'échec, il faut veiller à ce que l'option "Activer l'authentification Windows intégrée" de IE soit cochée (menu "outils" => "options" => "avancés", nœud "sécurité" de l'arborescence).

Firefox quant à lui demande le login / mot de passe de connexion au domaine en invite de connexion. Pour outrepasser cette invite et accéder directement à l'intranet, il faut configurer Firefox en tapant le mot clé "about:config" dans la barre d'adresse et en renseignant les options suivantes :

• network.automatic-ntlm-auth.trusted-uris
• network.negotiate-auth.delegation-uris
• network.negotiate-auth.trusted-uris

Les explications sur ces options sont disponibles sur le site mozilla.org.

Quant à Apache, il semblerait que cette méthode d'authentification soit également disponible en téléchargeant un module complémentaire : NTLM auth module (pas testé...).

Samedi 21 Juin 2008 à 07h27::PHPSauvegarde d'objets avec héritage en session

Il m'est fréquent au cours d'un projet PHP de sauvegarder l'état d'un objet dans une variable de session via la fonction "serialize()".

Cette fonctionnalité, déjà utilisée abondamment, est devenue encore plus pertinente et intéressante avec les développements AJAX. Outre les avantages habituels d'une programmation orientée objet, le fait de sauvegarder un objet en session évite lors des appels multiples au serveur web via JavaScript de relancer toute une suite de traitements afin de retrouver les propriétés des objets, ceux-ci ayant déjà été effectués au chargement de la page principale.

En revanche, pour la première fois assez bizarrement, je me suis retrouvé à la sauvegarde d'une classe "fille", avec héritage donc. A mon étonnement, la récupération d'un objet via la fonction "unserialize()" ne restaure pas les propriétés dûes à l'héritage de la classe mère. En contrepartie, les valeurs par défaut sont chargées.

Heureusement, même si je considère que PHP devrait nativement gérer ce fonctionnement, il existe une méthode simple pour sauvegarder les propriétés de la classe mère en utilisant la méthode magique "__sleep()". Au sein de cette méthode sont précisées les propriétés à sauvegarder lors de l'appel à la fonction "serialize()", en retournant un tableau de chaînes où chaque libellé correspond au nom d'une propriété de la classe.

Ainsi, il suffit d'appeler la méthode "__sleep()" de la classe mère lors du passage dans la méthode "__sleep()" de la classe fille. Ce qui peut se traduire par le code suivant :

class mere {
    
    protected $propriete = '';

    public function __construct() {
        $this->propriete = 'turlututu';
    }
    
    public function __sleep() {
        return array('propriete');
    }
}

class fille extends mere {

    private $autre_propriete = 'chapeau pointu';

    // {....}
    
    public function sleep() {
        
        return array_merge(
             array('autre_propriete'),
             parent::__sleep()
        );
        
    }

}

Testé avec succès en PHP 5.2.1 & 5.2.6.
Ah, et puis j'en profite pour dire que Firefox 3, c'est de la bombe...

Mercredi 04 Juin 2008 à 08h38::PHP | Serveur webIIS 7 : IIS Worker Process a cessé de fonctionner

Pour pallier à ce message d'avertissement, modifiez le pool d'application associé à PHP et mettez en place la même valeur aux options "Délais d'inactivité" / "Recyclage => Intervalle de temps régulier" (par défaut 1740 minutes) :

Samedi 12 Avril 2008 à 10h46::PHP | SQLmssql_connect() : unable to connect to server

En installation clientèle je fus confronté à un problème particulièrement difficile à détecter.
Sur un serveur windows 2003, PHP était incapable de communiquer avec le serveur de base de données SQL Server 2005.

Pour autant des tests avaient été effectuées avant de partir en déplacement mais sur une machine où toute la panoplie logicielle était installée en local sur une même machine.

Après avoir vérifié longuement tout le paramétrage (règles de flux, installation des librairies de connexion clients sql server sur le serveur web etc...), il s'avère que le problème provient d'une dll fournie avec le package PHP (version 5.2.5 me concernant) : ntwdblib.dll, la fameuse API de connexion de Microsoft « DB-Library » déjà source de nombreuses limitations lorsqu'utilisée avec PHP.

Pour rappel, voici une citation en provenance de Microsoft sur cette librairie :

« Although the SQL Server 2005 Database Engine still supports connections from existing applications using the DB-Library and Embedded SQL APIs, it does not include the files or documentation needed to do programming work on applications that use these APIs. A future version of the SQL Server Database Engine will drop support for connections from DB-Library or Embedded SQL applications. Do not use DB-Library or Embedded SQL to develop new applications. Remove any dependencies on either DB-Library or Embedded SQL when modifying existing applications. Instead of these APIs, use the SQLClient namespace or an API such as OLE DB or ODBC. SQL Server 2005 does not include the DB-Library DLL required to run these applications. To run DB-Library or Embedded SQL applications you must have available the DB-Library DLL from SQL Server version 6.5, SQL Server 7.0, or SQL Server 2000. »

Pour résumer, cette librairie est obsolète et foireuse, et Microsoft travaille sur une nouvelle librairie de connexion plus performante. Mais à quand sa disponibilité et son intégration dans PHP?

Bref, pour en revenir au problème, il faut mettre à jour la dll avec la version 2000.80.194.0, disponible depuis janvier 2007. Depuis le temps, je ne comprends pas qu'elle ne soit pas intégrée directement à PHP. A moins que des problèmes compatibilité subsiste avec les versions précédentes...

La dll peut être téléchargée sur le site dll files : http://www.dlldll.com/ntwdblib.dll_download.html